đź“… Original date posted:2012-07-25
đź“ť Original message:Hi Steve,
I see dramatic differences in performance on virtual machines vs running directly on the iron. I am not an expert in virtual machines, but it seems to me that they are weak when it comes to disk i/o. And berkeley DB, as used by bitcoin is a sucker for disk i/o. In top I easily hit >1/#processors in top wa, meaning that the cpu doing the blockchain download is just waiting for the disk all the time.
I would like to do a test keeping database log files in memory. It should not matter for durability of the wallet, as it flushes at each write anyway. As for the blockindex, it will remain consistent, but might be lagging some blocks behind at startup, which shouldn't really matter (except that the same block could end up appearing twice in the block00X files, inelegant, but not really a problem).
Otherwise the system you describe (raid0 over 6 disks) should perform like crazy wrt disk i/o, at least on par with SSD. It is your virtualization I am worried about.
Have a safe trip to down under!
/M
On 24/07/2012, at 21:56, steve wrote:
> Hi Michael,
>
> from what I have noticed, bitcoin blockchain download/verfication all
> happens in 1 thread. (so multicores doesnt really help)
>
> That said, I have never tried on an ssd.
>
> What I do have is 6 SATA 6gbs configed as RAID0 Drives.
> 32gb of ram. ubuntu 64 (yeah I know), this runs upto 16 VM's
> (I have 4 of these)
>
> However I have not tried to download the blockchain on the master os,
> just in virtulisation. However, the dedicated machines that I have been
> using for benchmarking the VM's against is a q6600 8gb ram sata2 hdd -
> Win 7 (seems faster than slackware...) to me it has always felt like
> network bandwidth was the issue. I might instrument the bitcoin-qt exe
> to only pick low ping nodes (has someone already done this?)
>
> I guess it is time to start some benchmarking (like the gpu comparison page)
>
> hte verification for the 5 past 5 days was negliglable. I am off on a
> flight to australia tomorrrow, so I will set some breakpoints and do
> some timings in a debugger.
>
> This will all happen on an e-450 (wonderful machine!)
>
> Thanks very much for your response. it would seem that I am 'doing it
> wrong' :/
>
> cheers mate,
>
> steve
>
> (this message isnt signed because I have forgotten my password.)
>
> On 24/07/2012 09:25, Michael Grønager wrote:
>> Hi Steve,
>>
>> 45-90 minutes - note that its numbers from March/April, so a bit
>> longer today, but far, far away from the 12 hours.
>>
>> I am using libcoin and the bitcoind build based on this. Libcoin is
>> based on the Satoshi client, but refactured to use an async
>> concurrency model. I also did a minor tweeks to the db parameters. It
>> has earlier been tested up against Satoshi bitcoin where on some
>> OS'es it performs similarly (at least on some linuxes) and on some
>> faster (e.g. mac).
>>
>> What is your CPU load during a block download ? (both initially/up to
>> the point where verification sets in and after). The initial download
>> is typically disk I/O bound, the verification stage CPU bound, though
>> I lean to believe that even there it is disk I/O bound (at least on
>> my system ~50% CPU load). What should be better in libcoin is the
>> concurrency model. The Satoshi client uses a pure reentrant mutexes
>> model, that is not generally believed to motivate the best coding
>> practice nor performance, you might end up without the concurrency
>> you initially strived for *). As mentioned earlier libcoin uses a
>> pure async concurrency model (and so does libbitcoin btw).
>>
>> I would like to stress again that these numbers will depend largely
>> on the system running the test - I would call my laptop a bit over
>> the average today (MB Pro, 2.66Ghz i7 dual core, 8GBRAM, 512GB SSD).
>> But again 12 hours - I only reach such numbers on some of my VPS'es
>> (linode 1024) that are known for notoriously slow disk I/O. (here I
>> have a few % CPU load during the verification indicating indeed that
>> the disk i/o is the culprit).
>>
>> Cheers,
>>
>> Michael
>>
>>
>> *) I like this Dave Butenhof quote: "The biggest of all the big
>> problems with recursive mutexes is that they encourage you to
>> completely lose track of your locking scheme and scope. This is
>> deadly. Evil. It's the "thread eater". You hold locks for the
>> absolutely shortest possible time. Period. Always. If you're calling
>> something with a lock held simply because you don't know it's held,
>> or because you don't know whether the callee needs the mutex, then
>> you're holding it too long. You're aiming a shotgun at your
>> application and pulling the trigger. You presumably started using
>> threads to get concurrency; but you've just PREVENTED concurrency."
>>
>>
>>
>>
>> On 23/07/2012, at 17:54, steve wrote:
>>
>> Hi Michael,
>>
>> On 23/07/2012 10:00, Michael Grønager wrote:
>>>>> I get a full blockchain from scratch in 45 minutes on my
>>>>> laptop, /M
>>>>>
>> Hang on a sec, in 45 minutes you can download the entire chain from
>> the genesis block?
>>
>> I have been doing extensive testing in this area and would love to
>> know what is special about your setup (I have never had the entire
>> chain in under 12 hours, infact it is normally closerto 24.) I have
>> an extensive setup of test machines, everything from e4300 to
>> phenom2x6 to i5's.
>>
>> as an example on an amd e-450 with 4gb ram, and approx 3gb/s
>> internet connection it took 2 hours to sync the last 5 days.
>>
>> Maybe i am missing something important...
>>
>> Any additional information that you could provide to help me with
>> testing would be really appreciated.
>>
>> cheers,
>>
>> steve
>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>>
> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions will include endpoint security, mobile security and the
>>> latest in malware threats.
>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________ Bitcoin-development
>>> mailing list Bitcoin-development at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>>
>>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Michael Grønager [ARCHIVE] /
npub15f…xlq6h
2023-06-07 10:25:00
in reply to nevent1q…l59x
Author Public Key
npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6hPublished at
2023-06-07 10:25:00Event JSON
{
"id": "00c10ad908731f7429e04a63412d1d25bae5b560b4f79c84260238b5988b678a",
"pubkey": "a277336e95d2d0a831fff67fc80d8082322689a88ede9f877fa246a02629a43f",
"created_at": 1686133500,
"kind": 1,
"tags": [
[
"e",
"63aed588f060c9675f9ddd34399756623e96cc693cda2679b108affeaacc7675",
"",
"root"
],
[
"e",
"6d98fea2773c5a4033310659e27d08bbecbdf98ef10a45c9b767909a42fe1916",
"",
"reply"
],
[
"p",
"d63ad498f971c5506e1b834b69b5935aebceb7cc8377696475934ee902b07186"
]
],
"content": "📅 Original date posted:2012-07-25\n📝 Original message:Hi Steve,\n\nI see dramatic differences in performance on virtual machines vs running directly on the iron. I am not an expert in virtual machines, but it seems to me that they are weak when it comes to disk i/o. And berkeley DB, as used by bitcoin is a sucker for disk i/o. In top I easily hit \u003e1/#processors in top wa, meaning that the cpu doing the blockchain download is just waiting for the disk all the time.\n\nI would like to do a test keeping database log files in memory. It should not matter for durability of the wallet, as it flushes at each write anyway. As for the blockindex, it will remain consistent, but might be lagging some blocks behind at startup, which shouldn't really matter (except that the same block could end up appearing twice in the block00X files, inelegant, but not really a problem).\n\nOtherwise the system you describe (raid0 over 6 disks) should perform like crazy wrt disk i/o, at least on par with SSD. It is your virtualization I am worried about.\n\nHave a safe trip to down under!\n\n/M\n\nOn 24/07/2012, at 21:56, steve wrote:\n\n\u003e Hi Michael,\n\u003e \n\u003e from what I have noticed, bitcoin blockchain download/verfication all\n\u003e happens in 1 thread. (so multicores doesnt really help)\n\u003e \n\u003e That said, I have never tried on an ssd.\n\u003e \n\u003e What I do have is 6 SATA 6gbs configed as RAID0 Drives.\n\u003e 32gb of ram. ubuntu 64 (yeah I know), this runs upto 16 VM's\n\u003e (I have 4 of these)\n\u003e \n\u003e However I have not tried to download the blockchain on the master os,\n\u003e just in virtulisation. However, the dedicated machines that I have been\n\u003e using for benchmarking the VM's against is a q6600 8gb ram sata2 hdd -\n\u003e Win 7 (seems faster than slackware...) to me it has always felt like\n\u003e network bandwidth was the issue. I might instrument the bitcoin-qt exe\n\u003e to only pick low ping nodes (has someone already done this?)\n\u003e \n\u003e I guess it is time to start some benchmarking (like the gpu comparison page)\n\u003e \n\u003e hte verification for the 5 past 5 days was negliglable. I am off on a\n\u003e flight to australia tomorrrow, so I will set some breakpoints and do\n\u003e some timings in a debugger.\n\u003e \n\u003e This will all happen on an e-450 (wonderful machine!)\n\u003e \n\u003e Thanks very much for your response. it would seem that I am 'doing it\n\u003e wrong' :/\n\u003e \n\u003e cheers mate,\n\u003e \n\u003e steve\n\u003e \n\u003e (this message isnt signed because I have forgotten my password.)\n\u003e \n\u003e On 24/07/2012 09:25, Michael Grønager wrote:\n\u003e\u003e Hi Steve,\n\u003e\u003e \n\u003e\u003e 45-90 minutes - note that its numbers from March/April, so a bit\n\u003e\u003e longer today, but far, far away from the 12 hours.\n\u003e\u003e \n\u003e\u003e I am using libcoin and the bitcoind build based on this. Libcoin is\n\u003e\u003e based on the Satoshi client, but refactured to use an async\n\u003e\u003e concurrency model. I also did a minor tweeks to the db parameters. It\n\u003e\u003e has earlier been tested up against Satoshi bitcoin where on some\n\u003e\u003e OS'es it performs similarly (at least on some linuxes) and on some\n\u003e\u003e faster (e.g. mac).\n\u003e\u003e \n\u003e\u003e What is your CPU load during a block download ? (both initially/up to\n\u003e\u003e the point where verification sets in and after). The initial download\n\u003e\u003e is typically disk I/O bound, the verification stage CPU bound, though\n\u003e\u003e I lean to believe that even there it is disk I/O bound (at least on\n\u003e\u003e my system ~50% CPU load). What should be better in libcoin is the\n\u003e\u003e concurrency model. The Satoshi client uses a pure reentrant mutexes\n\u003e\u003e model, that is not generally believed to motivate the best coding\n\u003e\u003e practice nor performance, you might end up without the concurrency\n\u003e\u003e you initially strived for *). As mentioned earlier libcoin uses a\n\u003e\u003e pure async concurrency model (and so does libbitcoin btw).\n\u003e\u003e \n\u003e\u003e I would like to stress again that these numbers will depend largely\n\u003e\u003e on the system running the test - I would call my laptop a bit over\n\u003e\u003e the average today (MB Pro, 2.66Ghz i7 dual core, 8GBRAM, 512GB SSD).\n\u003e\u003e But again 12 hours - I only reach such numbers on some of my VPS'es\n\u003e\u003e (linode 1024) that are known for notoriously slow disk I/O. (here I\n\u003e\u003e have a few % CPU load during the verification indicating indeed that\n\u003e\u003e the disk i/o is the culprit).\n\u003e\u003e \n\u003e\u003e Cheers,\n\u003e\u003e \n\u003e\u003e Michael\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e *) I like this Dave Butenhof quote: \"The biggest of all the big\n\u003e\u003e problems with recursive mutexes is that they encourage you to\n\u003e\u003e completely lose track of your locking scheme and scope. This is\n\u003e\u003e deadly. Evil. It's the \"thread eater\". You hold locks for the\n\u003e\u003e absolutely shortest possible time. Period. Always. If you're calling\n\u003e\u003e something with a lock held simply because you don't know it's held,\n\u003e\u003e or because you don't know whether the callee needs the mutex, then\n\u003e\u003e you're holding it too long. You're aiming a shotgun at your\n\u003e\u003e application and pulling the trigger. You presumably started using\n\u003e\u003e threads to get concurrency; but you've just PREVENTED concurrency.\"\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e On 23/07/2012, at 17:54, steve wrote:\n\u003e\u003e \n\u003e\u003e Hi Michael,\n\u003e\u003e \n\u003e\u003e On 23/07/2012 10:00, Michael Grønager wrote:\n\u003e\u003e\u003e\u003e\u003e I get a full blockchain from scratch in 45 minutes on my\n\u003e\u003e\u003e\u003e\u003e laptop, /M\n\u003e\u003e\u003e\u003e\u003e \n\u003e\u003e Hang on a sec, in 45 minutes you can download the entire chain from \n\u003e\u003e the genesis block?\n\u003e\u003e \n\u003e\u003e I have been doing extensive testing in this area and would love to \n\u003e\u003e know what is special about your setup (I have never had the entire \n\u003e\u003e chain in under 12 hours, infact it is normally closerto 24.) I have\n\u003e\u003e an extensive setup of test machines, everything from e4300 to\n\u003e\u003e phenom2x6 to i5's.\n\u003e\u003e \n\u003e\u003e as an example on an amd e-450 with 4gb ram, and approx 3gb/s\n\u003e\u003e internet connection it took 2 hours to sync the last 5 days.\n\u003e\u003e \n\u003e\u003e Maybe i am missing something important...\n\u003e\u003e \n\u003e\u003e Any additional information that you could provide to help me with \n\u003e\u003e testing would be really appreciated.\n\u003e\u003e \n\u003e\u003e cheers,\n\u003e\u003e \n\u003e\u003e steve\n\u003e\u003e \n\u003e\u003e\u003e \n\u003e\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\u003e \n\u003e\u003e\u003e \n\u003e Live Security Virtual Conference\n\u003e\u003e\u003e Exclusive live event will cover all the ways today's security and \n\u003e\u003e\u003e threat landscape has changed and how IT managers can respond.\n\u003e\u003e\u003e Discussions will include endpoint security, mobile security and the\n\u003e\u003e\u003e latest in malware threats.\n\u003e\u003e\u003e http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ \n\u003e\u003e\u003e _______________________________________________ Bitcoin-development\n\u003e\u003e\u003e mailing list Bitcoin-development at lists.sourceforge.net \n\u003e\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e \n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Live Security Virtual Conference\n\u003e Exclusive live event will cover all the ways today's security and \n\u003e threat landscape has changed and how IT managers can respond. Discussions \n\u003e will include endpoint security, mobile security and the latest in malware \n\u003e threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "7f3111729d1726809b4b708c49805813e484af3d537143926781682856875cd9ad8b9182f19941f6614f40cd0b12a266f33f9928760a0b7b7fbd06da2f0bd96a"
}