{"type":"rich","version":"1.0","author_name":"npub16cadfx8ew8z4qmsmsd9kndvntt4uad7vsdmkjer4jd8wjq4swxrqp2gy5d","author_url":"https://nostr.ae/npub16cadfx8ew8z4qmsmsd9kndvntt4uad7vsdmkjer4jd8wjq4swxrqp2gy5d","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-07-24\n📝 Original message:Hi Michael,\n\nfrom what I have noticed, bitcoin blockchain download/verfication all\nhappens in 1 thread.  (so multicores doesnt really help)\n\nThat said, I have never tried on an ssd.\n\nWhat I do have is 6 SATA 6gbs configed as RAID0 Drives.\n32gb of ram. ubuntu 64 (yeah I know), this runs upto 16 VM's\n(I have 4 of these)\n\nHowever I have not tried to download the blockchain on the master os,\njust in virtulisation.  However, the dedicated machines that I have been\nusing for benchmarking the VM's against is a q6600 8gb ram sata2 hdd -\nWin 7 (seems faster than slackware...) to me it has always felt like\nnetwork bandwidth was the issue.  I might instrument the bitcoin-qt exe\nto only pick low ping nodes (has someone already done this?)\n\nI guess it is time to start some benchmarking (like the gpu comparison page)\n\nhte verification for the 5 past 5 days was negliglable. I am off on a\nflight to australia tomorrrow, so I will set some breakpoints and do\nsome timings in a debugger.\n\nThis will all happen on an e-450 (wonderful machine!)\n\nThanks very much for your response. it would seem that I am 'doing it\nwrong' :/\n\ncheers mate,\n\nsteve\n\n(this message isnt signed because I have forgotten my password.)\n\nOn 24/07/2012 09:25, Michael Grønager wrote:\n\u003e Hi Steve,\n\u003e \n\u003e 45-90 minutes - note that its numbers from March/April, so a bit\n\u003e longer today, but far, far away from the 12 hours.\n\u003e \n\u003e I am using libcoin and the bitcoind build based on this. Libcoin is\n\u003e based on the Satoshi client, but refactured to use an async\n\u003e concurrency model. I also did a minor tweeks to the db parameters. It\n\u003e has earlier been tested up against Satoshi bitcoin where on some\n\u003e OS'es it performs similarly (at least on some linuxes) and on some\n\u003e faster (e.g. mac).\n\u003e \n\u003e What is your CPU load during a block download ? (both initially/up to\n\u003e the point where verification sets in and after). The initial download\n\u003e is typically disk I/O bound, the verification stage CPU bound, though\n\u003e I lean to believe that even there it is disk I/O bound (at least on\n\u003e my system ~50% CPU load). What should be better in libcoin is the\n\u003e concurrency model. The Satoshi client uses a pure reentrant mutexes\n\u003e model, that is not generally believed to motivate the best coding\n\u003e practice nor performance, you might end up without the concurrency\n\u003e you initially strived for *). As mentioned earlier libcoin uses a\n\u003e pure async concurrency model (and so does libbitcoin btw).\n\u003e \n\u003e I would like to stress again that these numbers will depend largely\n\u003e on the system running the test - I would call my laptop a bit over\n\u003e the average today (MB Pro, 2.66Ghz i7 dual core, 8GBRAM, 512GB SSD).\n\u003e But again 12 hours - I only reach such numbers on some of my VPS'es\n\u003e (linode 1024) that are known for notoriously slow disk I/O. (here I\n\u003e have a few % CPU load during the verification indicating indeed that\n\u003e the disk i/o is the culprit).\n\u003e \n\u003e Cheers,\n\u003e \n\u003e Michael\n\u003e \n\u003e \n\u003e *) I like this Dave Butenhof quote: \"The biggest of all the big\n\u003e problems with recursive mutexes is that they encourage you to\n\u003e completely lose track of your locking scheme and scope. This is\n\u003e deadly. Evil. It's the \"thread eater\". You hold locks for the\n\u003e absolutely shortest possible time. Period. Always. If you're calling\n\u003e something with a lock held simply because you don't know it's held,\n\u003e or because you don't know whether the callee needs the mutex, then\n\u003e you're holding it too long. You're aiming a shotgun at your\n\u003e application and pulling the trigger. You presumably started using\n\u003e threads to get concurrency; but you've just PREVENTED concurrency.\"\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e On 23/07/2012, at 17:54, steve wrote:\n\u003e \n\u003e Hi Michael,\n\u003e \n\u003e On 23/07/2012 10:00, Michael Grønager wrote:\n\u003e\u003e\u003e\u003e I get a full blockchain from scratch in 45 minutes on my\n\u003e\u003e\u003e\u003e laptop, /M\n\u003e\u003e\u003e\u003e \n\u003e Hang on a sec, in 45 minutes you can download the entire chain from \n\u003e the genesis block?\n\u003e \n\u003e I have been doing extensive testing in this area and would love to \n\u003e know what is special about your setup (I have never had the entire \n\u003e chain in under 12 hours, infact it is normally closerto 24.) I have\n\u003e an extensive setup of test machines, everything from e4300 to\n\u003e phenom2x6 to i5's.\n\u003e \n\u003e as an example on an amd e-450 with 4gb ram, and approx 3gb/s\n\u003e internet connection it took 2 hours to sync the last 5 days.\n\u003e \n\u003e Maybe i am missing something important...\n\u003e \n\u003e Any additional information that you could provide to help me with \n\u003e testing would be really appreciated.\n\u003e \n\u003e cheers,\n\u003e \n\u003e steve\n\u003e \n\u003e\u003e \n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\n\u003e\u003e \nLive Security Virtual Conference\n\u003e\u003e Exclusive live event will cover all the ways today's security and \n\u003e\u003e threat landscape has changed and how IT managers can respond.\n\u003e\u003e Discussions will include endpoint security, mobile security and the\n\u003e\u003e latest in malware threats.\n\u003e\u003e http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ \n\u003e\u003e _______________________________________________ Bitcoin-development\n\u003e\u003e mailing list Bitcoin-development at lists.sourceforge.net \n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e"}