On Friday, July 27, 2012 5:59:20 AM grarpamp wrote:
I now have an 1.8 ghz p3 celeron (128k cache) which should be
substantially slower than your machine, running vintage 2.6.20 linux.
Unfortunately I forgot to turn on timestamp logging so I don't know
how long it took to sync the chain,
On Fri, Jul 27, 2012 at 1:59 AM, grarpamp grarp...@gmail.com wrote:
I now have an 1.8 ghz p3 celeron (128k cache) which should be
substantially slower than your machine, running vintage 2.6.20 linux.
Unfortunately I forgot to turn on timestamp logging so I don't know
how long it took to sync
I propose a pragmatic solution: Try running the Multibit client. i am
not sure if the linux/java based installer would work,so maybe you have
to build it from source.
I tried it out is really fast compared to bitcoin-qt. after install it
took me 15 seconds to get updated and running. Importing
And now to the list...
On Jul 27, 2012 6:21 AM, grarpamp grarp...@gmail.com wrote:
Update: this class of machine just became useless for bitcoin.
When blk0002.dat was created to store more blocks, all forward
progress processing blocks turned into losing ground by 20 or so
a day. Guessing
You are however using a filesystem (ZFS)
I'm aware of the memory and i386 issues, and going shopping.
The bdb backend Bitcoin uses
does many I/O operations, and writes them synchronously to disk, killing
whatever caching your filesystem provides.
Sync... yes, depending on the rate/sec and
I'd love to know precisely what Bitcoin is doing thats making your
machine so unhappy... but your configuration is uncommon for bitcoin
nodes in many distinct ways so it's not clear where to start.
That's why I posted the details of the machine so interested people
could duplicate it if they
Update: this class of machine just became useless for bitcoin.
When blk0002.dat was created to store more blocks, all forward
progress processing blocks turned into losing ground by 20 or so
a day. Guessing both datfiles were being accessed at once resulting
in disk based overload. I've not seen
On Fri, Jul 27, 2012 at 12:20 AM, grarpamp grarp...@gmail.com wrote:
Update: this class of machine just became useless for bitcoin.
When blk0002.dat was created to store more blocks, all forward
progress processing blocks turned into losing ground by 20 or so
a day. Guessing both datfiles were
I now have an 1.8 ghz p3 celeron (128k cache) which should be
substantially slower than your machine, running vintage 2.6.20 linux.
Unfortunately I forgot to turn on timestamp logging so I don't know
how long it took to sync the chain, but it was less than two days as
that was the span
On 25/07/2012 10:45, Michael Grønager wrote:
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,
They can be, it depends on how they are set up. For reference, these
VM's used to test network
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
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
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
Hello,
Even though I'm not a dev, I can't agree more, and would like to know if
they are expected steps being taken, some fixes coming, or whatever?
Thank you all for your hard work.
Raphael
On 07/23/2012 12:37 AM, grarpamp wrote:
Given a testbed: Pentium 4 1.8GHz single core, 2GB ram,
On Sun, Jul 22, 2012 at 6:37 PM, grarpamp grarp...@gmail.com wrote:
It already takes a month to build a new blockchain, let alone keep up
with new incoming blocks.
Please fix your software stack. Something is wrong with your system
and I doubt it has much to do with bitcoin. A full sync here
-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
You're seriously suggesting that I'm using a system
which is 720x (one month vs one hour) faster than your
P4 1.8GHz?
Don't know what you're using since you've not stated it.
I find this doubtful, especially since bitcoin's sync is effectively
single threaded.
Extra cores help with disk,
17 matches
Mail list logo
