我在一块慢速的 7 年老硬盘上测过，带宽和 CPU 显然不是瓶颈。初始下载用了 1 小时 20 分钟。
I tested it on a slow 7 year old drive, where bandwidth and CPU were clearly not the bottleneck. Initial download took 1 hour 20 minutes.
如果远超这个时间——当然 24 小时肯定算远超——那一定是从很慢的节点下载，或者你的连接比每秒约 15KB（120kbps）慢得多，或者有别的地方出了问题。出现那种情况时，最好能知道瓶颈看起来在哪里。
If it's taking a lot longer than that, certainly 24 hours, then it must be downloading from a very slow node, or your connection is much slower than around 15KB per sec (120kbps), or something else is wrong. It would be nice to know what appears to be the bottleneck when that happens.
约莫每 10 分钟最新区块送达时，它都有机会切换到更快的节点。最新区块广播时，它会向其他节点请求接下来的 500 个区块，并从发送最快的一个继续下载。至少，它本该这样工作。
Every 10 minutes or so when the latest block is sent, it should have the chance to change to a faster node. When the latest block is broadcast, it requests the next 500 blocks from other nodes, and continues the download from the one that sends it fastest. At least, that's how it should work.
其他参与者原话jgarzik原帖 ↗
也许只需要更多的读缓存。它必须随机地读遍 blk0001.dat 和 blkindex.dat 来建索引。它不能假设文件比内存小，虽然目前仍是这样。缓存会相当有效，因为所依赖的数据大多是近期的。
It may only need more read caching. It has to read randomly all over blk0001.dat and blkindex.dat to index. It can't assume the file is smaller than memory, although it currently still is. Caching would be effective, since most dependencies are recent.
应该有人用不同的 Berkeley DB 设置做实验，看看有没有能让下载显著加快的配置。如果真发现了什么，我们再落实细节。
Someone should experiment with different Berkeley DB settings and see if there's something that makes the download substantially faster. If something substantial is discovered, then we can work out the particulars.
其他参与者原话jgarzik（续）原帖 ↗添加 BDB 记录只是向日志文件追加，直到你执行一次检查点操作。检查点随后更新主数据库文件。
Adding BDB records is simply appending to a log file, until you issue a checkpoint. The checkpoint then updates the main database file.
我们每 500 个区块执行一次检查点操作。
We checkpoint every 500 blocks.
当前版本尚未建立逐条校对状态记录。来源核验、历史审校与当前译文校对是不同事项。
译文内容版本：d11257d78302。用于比对文本，不代表校对等级或更新时间。
请填写对应原文、现译文、建议译法和理由。复制后通过你联系本站作者的渠道提交；此处不会自动发送。
