Re: [Bitcoin-development] Scalability issues
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-develop
Re: [Bitcoin-development] Scalability issues
> The Satoshi client uses a pure reentrant mutexes model As you presumably already know, the reference client doesn't attempt to parallelise most operations at all. Chain download is entirely single threaded. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reconsidering block version number use
I think it would be great to have more nonce space with less merkle calculation; keeping track of all possible versions of a block already takes real RAM, real computation. Being able to change one bit in the header and send out a new block for checking would ease our pool server work by a real amount, somewhat on the work generation side, but also on the checking old work side; we'll have a lot fewer unique transaction / coinbase sets to hold on to for checking when we get back a solution. Peter On Tue, Jul 24, 2012 at 4:58 PM, Mike Hearn wrote: > > That'd be 7 bytes of nonce in the block header, which is > > 72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes > > > > So: the changes for version 2 blocks would be "has height in the > > coinbase, and has a 1-byte version number with a 3-byte extranonce." > > I don't understand why more nonce bits are necessary. Is it really > impossible for a multi-core CPU to keep up with the merkle root > re-calculation and keep an ASIC miner fed, or is this working around a > performance bottleneck somewhere else? > > > -- > 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@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- -- [image: CoinLab Logo]PETER VESSENES CEO *pe...@coinlab.com * / 206.486.6856 / SKYPE: vessenes 811 FIRST AVENUE / SUITE 480 / SEATTLE, WA 98104 -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Scalability issues
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: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > 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 > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.17 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJQDXO4AAoJEFvEB9dQFvtQxdcH/ieqQkyDCg8mKeOa6CqsWaS6 > fhoeny3Ke2b/CsvhYmsThCvntN9volIqR2CTn5tkHiVwG9OmlxyHZcNpN0ZTHhK5 > lsfLap/Y0QpiysXpV4Bu7Z4Hwp9jnhOP74TshT305r2pX6EGXPQ0CrlHqlIry/X/ > vNcunUclliou+KjL7EHcY50GH5wDpqJAjlNyF97Lj9YiPrAC9vahGwWdxkbCYtG+ > KUuWGBKMMdHuMAgcQh7nI9q0WT3k/gzRQtuC2kf+v0wvQhaGlTVkku4uanhpuw4p > 99blRF3/SfWimGuQgsm6wT3Y7dk+z8MFHLb6XGPxmgV9+gF+TWNczfU3GRzfcXw= > =CQkI > -END PGP SIGNATURE- > > -- > 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@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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reconsidering block version number use
My point is that stuffing nonces into whatever spaces we can find to eke out a bit more scalability in pools seems like a very short term fix with potentially very long term consequences. Although it may sound harsh, if your pool is struggling to keep up with calculating merkle roots (which is cheap!) then it's time to either upgrade your pool or for some of those users to migrate to p2pool and handle creation of work themselves. Trying to squash more nonce bits out of fields that were never meant for that seems like a bad precedent with no real motivation beyond making running centralized pools a bit cheaper. What I'm interested in is, can a powerful server-class machine really not keep up with work generation for things like the BitForce SC devices? How many devices would you need to exhaust the ability to generate work for them? You'll need powerful machines just to run a node at all sooner or later. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
> Really lightweight clients (like Bitcoincard), clients with shared > private keys (electrum-style), or brainwallets - will ask the following > question quite often to "supernodes": Given my public keys/addresses, > what is the list of unspent outputs. i think it would make sense to > include such a command, instead or in addition to the filterload/filterinit. Ultra-lightweight clients like Electrum or smart cards have a fundamentally different security model to SPV clients, which mean they cannot connect directly to the P2P network no matter what commands or db indexes are added. This seems to be a common point of confusion. Andreas brought up something similar in a chat yesterday. To connect to the P2P network, you MUST understand how to walk the block chain and handle re-orgs. This is not optional. The reason is that you are connected to random arbitrary nodes who can and maybe will lie to you. The block chain is a self-proving data structure, a node cannot lie about it or make you believe garbage unless they can outrun the rest of the miners combined. If all you're doing is asking a remote node to tell you about what coins are available, that node can simply say "guess what, you're a millionaire!" and you have no way to discover it's wrong. This can be dangerous in the case where you think you've received a payment but actually did not, eg, because your internet connection got tampered with in some way. SPV clients have the same issue for zero-confirmed transactions, but once you see confirmations at high speeds you can be pretty sure the network accepted the transaction. For clients that don't understand the block chain confirmations don't have any meaning. That's why Electrum requires a trusted server and connects to it via SSL. > And perhaps more severe: as far as i understand classic bloom filters, > the server has no method of indexing his data for the expected requests. It doesn't matter. CPU wise Bloom filtering of blocks is very cheap and can be trivially parallelised in the unlikely event it's necessary. The expensive part of serving a Bloom filtered chain to an SPV client is simply moving the disk head into the right position and waiting for the platter to rotate. Blocks are stored sequentially and modern hard disks transfer data once positioned at gigabit speeds so requesting 1 or 2000 blocks is not significantly different. -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Reconsidering block version number use
> That'd be 7 bytes of nonce in the block header, which is > 72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes > > So: the changes for version 2 blocks would be "has height in the > coinbase, and has a 1-byte version number with a 3-byte extranonce." I don't understand why more nonce bits are necessary. Is it really impossible for a multi-core CPU to keep up with the merkle root re-calculation and keep an ASIC miner fed, or is this working around a performance bottleneck somewhere else? -- 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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
