「Satoshi Client Block Exchange」を編集中
この編集を取り消せます。
下記の差分を確認して、本当に取り消していいか検証してください。よろしければ変更を保存して取り消しを完了してください。
最新版 | 編集中の文章 | ||
39行目: | 39行目: | ||
ローカル受信バッファがいっぱいになる可能性があります。 ローカルノードが受信バッファがいっぱいであることに気付くと、そのノード接続は切断されます。[18] fDisconnectフラグをセットすると、バッファが空になったら[19]、ソケットは閉じます。 | ローカル受信バッファがいっぱいになる可能性があります。 ローカルノードが受信バッファがいっぱいであることに気付くと、そのノード接続は切断されます。[18] fDisconnectフラグをセットすると、バッファが空になったら[19]、ソケットは閉じます。 | ||
− | == | + | == Performance == |
− | + | As of September 1, 2011, on a server class computer circa 2005 running | |
− | + | Ubuntu with a Comcast cable internet connection takes over 10 hours | |
+ | to download and process the block chain. While it is debatable what | ||
+ | the bottleneck is early in the download process, it is clear from | ||
+ | the processing of recent blocks that the network is not the bottleneck | ||
+ | for all but the slowest internet connections. | ||
− | + | Blocks are taking over a second, on average, to process once downloaded.[20] | |
+ | However, the average size of a block is only around 24 kilobytes | ||
+ | in August 2011. It certainly does not take 1 second to download 24K. | ||
+ | Also, testing reveals very large queues of blocks being processed per | ||
+ | message loop, which is not what you would expect if the thread was | ||
+ | pulling them out of the queue as they arrive on the sockets. | ||
− | + | There are a number of "false signals" that lead one to believe the problem | |
+ | is with network performance. The first false signal is that, as of | ||
+ | August 2011, nearly all of the first 60 or 70% of blocks downloaded are | ||
+ | very small. Recent average block sizes are around one hundred times bigger! | ||
+ | So, almost all of a sudden, the block rate goes from very fast to very slow. | ||
+ | It looks like something went wrong. In reality, if you measure the rate | ||
+ | of block processing by kilobyte, the rate remains relatively constant. | ||
− | + | Another false signal is related to the fact that message queues are | |
+ | processed to completion, one at a time per node. This can result in big | ||
+ | backups of messages from other nodes. So, a long period of increasing | ||
+ | blocks may freeze for long periods as other nodes are serviced. Consider | ||
+ | that block downloads typically come from just one remote node (at | ||
+ | least until a miner or other relaying or downloading node advertises | ||
+ | a late block and disrupts the process) and so all the work might | ||
+ | be on one node. Things go fast processing the blocks from a node, | ||
+ | and then that looks like it stops as "addr" messages are processed from | ||
+ | other nodes and other work is done. But it looks like something is wrong. | ||
− | + | Also, the orphaning effects described above can lead to excessive block | |
+ | processing with nothing to show for it until the orphan chain is connected. | ||
+ | Also, you do ocassionally run into a node that is slow to respond, perhaps | ||
+ | because they are also processing blocks or because they have a slow machine | ||
+ | or connection. | ||
+ | |||
+ | All of the above contributes to heavy "jitter" in the block download process, | ||
+ | and that is a more frustrating user experience than a constant download rate. | ||
− | |||
==脚注== | ==脚注== |