{"type":"rich","version":"1.0","author_name":"npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6h","author_url":"https://nostr.ae/npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6h","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-07-24\n📝 Original message:Hi Steve,\n\n45-90 minutes - note that its numbers from March/April, so a bit longer today, but far, far away from the 12 hours. \n\nI 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). \n\nWhat 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). \n\nI 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).\n\nCheers,\n\nMichael\n\n\n*) 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.\"\n\n\n\n\nOn 23/07/2012, at 17:54, steve wrote:\n\n\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e Hash: SHA1\n\u003e \n\u003e Hi Michael,\n\u003e \n\u003e On 23/07/2012 10:00, Michael Grønager wrote:\n\u003e\u003e I get a full blockchain from scratch in 45 minutes on my laptop,\n\u003e\u003e /M\n\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 an\n\u003e extensive setup of test machines, everything from e4300 to phenom2x6\n\u003e to i5's.\n\u003e \n\u003e as an example on an amd e-450 with 4gb ram, and approx 3gb/s internet\n\u003e 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 -----BEGIN PGP SIGNATURE-----\n\u003e Version: GnuPG v2.0.17 (MingW32)\n\u003e Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\n\u003e \n\u003e iQEcBAEBAgAGBQJQDXO4AAoJEFvEB9dQFvtQxdcH/ieqQkyDCg8mKeOa6CqsWaS6\n\u003e fhoeny3Ke2b/CsvhYmsThCvntN9volIqR2CTn5tkHiVwG9OmlxyHZcNpN0ZTHhK5\n\u003e lsfLap/Y0QpiysXpV4Bu7Z4Hwp9jnhOP74TshT305r2pX6EGXPQ0CrlHqlIry/X/\n\u003e vNcunUclliou+KjL7EHcY50GH5wDpqJAjlNyF97Lj9YiPrAC9vahGwWdxkbCYtG+\n\u003e KUuWGBKMMdHuMAgcQh7nI9q0WT3k/gzRQtuC2kf+v0wvQhaGlTVkku4uanhpuw4p\n\u003e 99blRF3/SfWimGuQgsm6wT3Y7dk+z8MFHLb6XGPxmgV9+gF+TWNczfU3GRzfcXw=\n\u003e =CQkI\n\u003e -----END PGP SIGNATURE-----\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"}