> 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
> 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 an
And now to the list...
On Jul 27, 2012 6:21 AM, "grarpamp" 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
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 a
On Fri, Jul 27, 2012 at 1:59 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, b
> shopping.
Good thing I can still spend, even with an incomplete blockchain :)
> but why do you also need to encrypt 2+ GB of public record?
1) I'm not seeing an option to split the wallet, debug log and other
privates pathwise from the blockchain.
2) Because encrypt everything is reasonable st
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 ch
> 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 be
On Fri, Jul 27, 2012 at 12:20 AM, grarpamp 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 being accessed
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 an
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,
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/
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
> 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 Secu
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 t
On Sun, Jul 22, 2012 at 11:37 PM, grarpamp wrote:
> Given a testbed: Pentium 4 1.8GHz single core, 2GB ram, FreeBSD 8,
> disk is geli aes-128 + zfs sha-256, bitcoin 0.6.3, Tor proxy,
> An estimate is made that by the end of the year bitcoin will
> completely overrun the capabilities of this reason
> 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 dis
-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 tes
> Please fix your software stack. Something is wrong
> with your system
Nothing wrong, it's all default install. I documented the platform
for anyone who wants to confirm it.
> A full sync here takes something like an hour.
And what, similarly, is your platform?
It takes 5 seconds... on my Cray.
I would guess that you are running the blockchain download through the
tor-proxy - that would give you the times you mention. Further, encrypting your
disk (aes stuff) will not help you much either, and encrypting a the storage of
a public blockchain seems to me a bit odd ?
I get a full blockch
On Sun, Jul 22, 2012 at 6:37 PM, grarpamp 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 takes
something lik
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, FreeBS
Given a testbed: Pentium 4 1.8GHz single core, 2GB ram, FreeBSD 8,
disk is geli aes-128 + zfs sha-256, bitcoin 0.6.3, Tor proxy,
An estimate is made that by the end of the year bitcoin will
completely overrun the capabilities of this reasonable class of
machines.
It already takes a month to build a
23 matches
Mail list logo
