P2P limits from ISP

[vite]

With my ISP downloading a 1 gig file takes roughly 45 min, but downloading the bitcoin block takes about 9 hours. I always use QT cause of its suppose to be the most secure and it was the one I originally downloaded and worked, so I have stuck with it.

One day out of boredom, I installed the QT client on a second PC within the same LAN, I thought, since its P2P and its inside the same LAN, then it will transfere the data faster cause its inside the same lan, but it still took about 9 hours to download.

I reinstalled the QT client to transfer the wallet to a new PC, and started around 11 pm est, its 10 am EST today and it still has not finished, but getting there lol.

Just wondering how I can test if my ISP has p2p limits

[1713480616]

1713480616

[1713480616]

1713480616

[1713480616]

1713480616

[1713480616]

1713480616

[caveden]

It's not the download itself that takes time. It's processing and indexing the downloaded raw data.

IMHO it's IO time the great bottleneck concerning blockchain update. At least my laptop disk makes a lot of noise.

[vite]

99.61% @ 3:07 EST

[DILLIGAF]

With my ISP downloading a 1 gig file takes roughly 45 min, but downloading the bitcoin block takes about 9 hours. I always use QT cause of its suppose to be the most secure and it was the one I originally downloaded and worked, so I have stuck with it.

One day out of boredom, I installed the QT client on a second PC within the same LAN, I thought, since its P2P and its inside the same LAN, then it will transfere the data faster cause its inside the same lan, but it still took about 9 hours to download.

I reinstalled the QT client to transfer the wallet to a new PC, and started around 11 pm est, its 10 am EST today and it still has not finished, but getting there lol.

Just wondering how I can test if my ISP has p2p limits

Believe you could have used the addnode option when starting the daemon/QT client to get it to connect to your already existing install for the download or better yet you could have just copied over the files in your bitcoin directory over the LAN before starting either of them to have it all already done no download needed then. If you left out the wallet.dat during copy then you would have the two different address one for each machine if you copied then both would use the same address.

[Stephen Gornick]

Believe you could have used the addnode option when starting the daemon/QT client to get it to connect to your already existing install for the download

Well, addnode will add it to the list but to force it to only connect to a specific node use -connect=

   -connect=<ip>      Connect only to the specified node

- http://en.bitcoin.it/wiki/Running_Bitcoin

[Gabi]

It's not a downloading limit

You have no p2p limit, stay calm

It takes age to get the blockchain cause it verify each block. Check the hard drive usage, it will be using the hard disk like hell while getting the blockchain. The limit is the hard disk speed, not the internet connection. With a SSD it would be much more faster. If you setup a RAM disk it would be muuuuch faster

[rjk]

It's not a downloading limit

You have no p2p limit, stay calm

It takes age to get the blockchain cause it verify each block. Check the hard drive usage, it will be using the hard disk like hell while getting the blockchain. The limit is the hard disk speed, not the internet connection. With a SSD it would be much more faster. If you setup a RAM disk it would be muuuuch faster

Thing is, many of these things were mitigated - quite a lot - with 0.6.2 version. It really shouldn't be taking so long.

[caveden]

Thing is, many of these things were mitigated - quite a lot - with 0.6.2 version. It really shouldn't be taking so long.

Not for me...
When I start my 0.6.2 client after a single day off, the time to synchronize is considerable. The disk works frenetically.

I suspect indexation time is the issue here... does anyone know how the blockchain index is structured? If it is just a sorted disk array for example, inserting anything would be linear on the amount of data already there.
Plus, I believe it would help to do bulk inserts, asynchronously, if that's not done already. This would allow the download+verification to continue while indexation is processing a previous bulk. I have the impression that the whole process is synchronous (download a block, verify it, insert in BD, download next block, verify it, insert and so on...). If that's the case, it could be optimized. Not saying it's easy, but it's possible.