public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: steve <steve@mistfpga.net>
To: "Michael Grønager" <gronager@mac.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Scalability issues
Date: Tue, 24 Jul 2012 20:56:48 +0100	[thread overview]
Message-ID: <500EFE00.7060200@mistfpga.net> (raw)
In-Reply-To: <B872EE35-36F9-4F4E-8342-FFA141E433C7@mac.com>

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@lists.sourceforge.net 
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 
> 
> 
> 
> 




  parent reply	other threads:[~2012-07-24 19:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-22 22:37 [Bitcoin-development] Scalability issues grarpamp
2012-07-23  7:23 ` Raphael NICOLLE
2012-07-23  7:35 ` Gregory Maxwell
2012-07-23  9:00   ` Michael Grønager
2012-07-23 15:11     ` grarpamp
     [not found]       ` <CAAS2fgREzk_dU0ie+YvDdRwKcTk6tk_i=a2Bb74w9uF=EwYhGA@mail.gmail.com>
2012-07-23 22:33         ` grarpamp
2012-07-27  4:20           ` grarpamp
2012-07-27  4:59             ` Gregory Maxwell
2012-07-27  5:59               ` grarpamp
2012-07-27  6:03                 ` Luke-Jr
2012-07-27  6:28                   ` grarpamp
2012-07-27  6:56                 ` Gregory Maxwell
2012-07-27 19:37                   ` grarpamp
2012-07-27  8:53                 ` Andreas Petersson
     [not found]             ` <CAPg+sBjpqqxL_GxYc+8Ry7DcXMkouO9bYi5VqOyEjj_5s0x06Q@mail.gmail.com>
2012-07-27  9:59               ` Pieter Wuille
2012-07-27 19:26               ` grarpamp
2012-07-23 15:54     ` steve
2012-07-24  8:25       ` Michael Grønager
2012-07-24  9:18         ` Mike Hearn
2012-07-24 19:56         ` steve [this message]
2012-07-25  9:45           ` Michael Grønager
2012-07-25 14:24             ` steve
2012-07-23 22:50 ` Aidan Thornton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=500EFE00.7060200@mistfpga.net \
    --to=steve@mistfpga.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gronager@mac.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox