• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Shouldn't our blockchain download at a faster rate than BTC's thanks to so many masternodes?

fernando

fernando

Powered by Dash
Foundation Member
I was convinced that one more reason to love our masternodes setup would be a faster syncing speed when setting up a new wallet. Our ratio of full nodes per wallet is amazing. We have more than 1100 masternodes plus a few other non masternode nodes, with just a few thousand users (my guess). Bitcoin on the other hand, has around 6400 nodes, but they have multiple times our number of users (maybe into the millions already?). However, I recently had to download the BTC blockchain and I had a better performance than with the DRK blockchain. It is true that nowadays most BTC users don't download the full blockchain, but I still believe that our ratio must be much higher. I'm absolutely sure that they have more than six times our number of full blockchain users.

This a completely unscientific experiement and I won't repeat it, the pain of downloading the BTC blockchain is too much (slightly better performance but 64 times the size!). Anyway, there goes my data in case someone can make some sense on why. Can it be related with the improvement in the protocol that reduced the bandwidth used by masternodes? is it just luck or different geographical distribution of connections?

Both downloads were done from the same computer and location last week. DRK blockchain was downloaded as soon as the BTC one finished. For the BTC one I used the last bootstrap.dat torrent file, so the part I measured was the one not included there.

25,5 GB (27.457.747.588 bytes) 11.52 end of the torrented part
25,5 GB (27.457.747.588 bytes) 11.55 still thinking :)
25,5 GB (27.458.796.164 bytes) 12.02
25,6 GB (27.494.447.748 bytes) 12.15
25,6 GB (27.589.738.441 bytes) 12.44
25,8 GB (27.741.966.318 bytes) 12.57
26,0 GB (27.948.584.765 bytes) 13.08
26,1 GB (28.100.483.469 bytes) 13.19
26,2 GB (28.177.291.661 bytes) 12.27
26,5 GB (28.497.130.209 bytes) 13.48
26,5 GB (28.535.927.521 bytes) 13.57
26,7 GB (28.686.990.254 bytes) 14.07
26,8 GB (28.800.890.431 bytes) 14.18
26,9 GB (28.895.524.415 bytes) 14.31
27,2 GB (29.273.783.941 bytes) 15.08
27,8 GB (29.955.772.819 bytes) 16.14 finished, can't know exact time because I was out

Between the third one and the penultimate checkpoints, I downloaded 1.814.987.777 bytes in 186 minutes. That's 9.757.998 (9.3 MB per minute).

Then I downloaded the Darkcoin blockchain to compare.

18,8 MB (19.758.223 bytes) 16.17 starting
79,0 MB (82.905.394 bytes) 16.22
193 MB (202.531.275 bytes) 16.29
289 MB (303.801.030 bytes) 16.40
346 MB (362.970.702 bytes) 16.50
407 MB (427.587.020 bytes) 17.03
443 MB (465.194.106 bytes) 17.08
445 MB (467.490.691 bytes) 17.10 finished right then, I was watching

I downloaded 447.732.468 bytes in 53 minutes. That's 8.447.782 (8.2 MB per minute).
 
fernando said:
For the BTC one I used the last bootstrap.dat torrent file, so the part I measured was the one not included there.
Click to expand...

You can't compare blockchain building with a bootstrap.dat and without it because you exclude the network bandwidth limitations of your computer.

A proper test would be:

  • write down the current block number for both
  • start unsynced wallets for both simultaneously ( to level out network-speed fluctuations) and wait until both are fully synced. Don't forget to empty the data folders for both before you start, a huge debug.log file also slows down everything.
  • When both have finished search for the block number from above in debug.log to get the timestamps.

Divide the number of blocks by time needed to get comparable results.
Blocks per second is what really matters for the end user.
 
crowning said:
You can't compare blockchain building with a bootstrap.dat and without it because you exclude the network bandwidth limitations of your computer.

A proper test would be:

  • write down the current block number for both
  • start unsynced wallets for both simultaneously ( to level out network-speed fluctuations) and wait until both are fully synced. Don't forget to empty the data folders for both before you start, a huge debug.log file also slows down everything.
  • When both have finished search for the block number from above in debug.log to get the timestamps.

Divide the number of blocks by time needed to get comparable results.
Blocks per second is what really matters for the end user.
Click to expand...

Agreed, the test setup is not valid, the results are not comparable. fernando if you download bootstrap.dat for bitcoin, you have to download bootstrap.dat for darkcoin as well to have a "fair" contest. But you are comparing apples and pears: bitcoin bootstrap.dat is downloaded via bittorrent, Darkcoin bootstrap.dat is provided via http download - both will max out your download bandwidth.

--> https://github.com/UdjinM6/darkcoin-bootstrap

The setup by crowning is valid, which means you'll have to wait WEEKs for bitcoin blockchain to download, vs. 50mins for Darkcoin. (personally i even had 30mins some times)

In the end blocks/sec is the measure that counts, or even further: tx/seconds as blocksize depends on # of tx.
 
crowning flare, thanks for the responses!!

I'm comparing just the end of the bitcoin blockchain because of the unfairness of using bootstrap.dat. I torrented bootstrap.dat and placed it so Bitcoin Core used it to import the blocks. While it was importing it, the wallet clearly says 'importing blocks'. I only started measuring BTC when it reached the end of the blocks included in bootstrap.dat (six weeks ago, which coincides what was said in the description) and it started downloading from peers... at least that's what the wallet said (and it froze for a while and the speed went down, so it makes sense). Unless the fact of having imported the previous blocks makes it faster to download the latest ones, I don't see why the comparison is not fair. Anyway, I'll give both wallets a few days and test what crowning suggests.

Regarding the speed ratio to use, I think MB/sec is better than blocks/sec because BTC has less blocks, so even with the same usage in both coins they should be bigger and take longer.
 
crowning flare I guess sync time of whole blockchain was not the point of fernando's test. What he tested is not the time for clients to sync from scratch but the speed to get new blocks from some point in the past assuming that the more nodes per client ratio network has network has the higher should be the speed. The main parts in his test is (9.3 MB per minute) for btc and (8.2 MB per minute) for drk and not the absolute time.

EDIT: ooops, he just answered himself :)
 
UdjinM6 said:
crowning flare I guess sync time of whole blockchain was not the point of fernando test. What he tested is not the time for clients to sync from scratch but the speed to get new blocks from some point in the past assuming that the more nodes per client ratio network has network has the higher should be the speed. The main parts in his test is (9.3 MB per minute) for btc and (8.2 MB per minute) for drk and not the absolute time.
Click to expand...
It may be that this was his focus, but the OP title states

"Shouldn't our blockchain download faster than BTC's"

which implies downloading from scratch (for me) ^^
 
Well, regarding of title :wink: might be not so bad idea to get masternode list and try to sync from them first. They have a lot of bandwith - 100Mb/s out is common limit for small VPS and I for example can upload at ~30-40 Kb/s speed only.
 
flare said:
It may be that this was his focus, but the OP title states

"Shouldn't our blockchain download faster than BTC's"

which implies downloading from scratch (for me) ^^
Click to expand...
You are right, I have changed the tittle to "download at a faster rate". I'll blame English not being my native language as the reason for a poor OP :wink:
 
UdjinM6 said:
crowning flare I guess sync time of whole blockchain was not the point of fernando's test. What he tested is not the time for clients to sync from scratch but the speed to get new blocks from some point in the past assuming that the more nodes per client ratio network has network has the higher should be the speed. The main parts in his test is (9.3 MB per minute) for btc and (8.2 MB per minute) for drk and not the absolute time.

EDIT: ooops, he just answered himself :)
Click to expand...
Exactly. I'll admit that I measured because I was absolutely sure that ours was gonna download way way faster per MB and wanted to brag about it :) Anyway, as I said, one repetition is not even an experiment, I just wanted to share what I saw because I was surprised and wanted to make sense of it.
 
Well, I played a bit with this and got interesting results.

What I did:
Code: 
rm -rf blocks/ chainstate/ debug.log peers.dat
date; darkcoind; sleep 20; while(true);do darkcoind getinfo | grep blocks; sleep 60; done;

I do this before every test. So it's a clean start, I know "start time", I have blocks printed out in stdout every minute so once sync is done I can count lines and get "end time" pretty accurate. And here are some results:

1. no "connect", not even "addnode" in darkcoin.conf
~54 minutes

2. issued "darkcoin masternode list", grabbed all IPs and pasted them in darkcoin.conf in form "connect=54.171.120.119" (yes, ~1200 lines)
block count visually was 2 times slower and when it reached ~50K blocks darkcoind crashed :eek:
Run second test on more time and get the same result...
Here is debug.log log output:
Code: 
2014-11-25 20:42:20 Unable to open file /home/username/.darkcoin/blocks/blk00000.dat
2014-11-25 20:42:20 ERROR: CBlock::WriteToDisk() : OpenBlockFile failed
2014-11-25 20:42:20 *** Failed to write block
2014-11-25 20:42:20 Error: Failed to write block
2014-11-25 20:42:20 ERROR: ProcessBlock() : AcceptBlock FAILED

Quite an unexpected result I must say :wink:

3. Cut list of nodes to ~600
again 2 times slower but at least it fully synced this time
~107 minutes

4. Cut list to ~300 nodes
and it was just like #3 and even a little bit slower (?)

I monitored connections all the time and there is something in bitcoin network code - it looks like it just wouldn't let you grab more and it manage peers a lot better on itself in that situation. This of course was a very "dumb&dirty" way and there must be some way to improve it but in general it looks like wallet manages peers quite good on itself.

EDIT: fixed 1. from "no 'addnode" in darkcoin.conf' to 'no "connect", not even "addnode" in darkcoin.conf' to avoid confusions
 
Last edited by a moderator:
UdjinM6 said:
Well, I played a bit with this and got interesting results.

What I did:
Code: 
rm -rf blocks/ chainstate/ debug.log peers.dat
date; darkcoind; sleep 20; while(true);do darkcoind getinfo | grep blocks; sleep 60; done;

I do this before every test. So it's a clean start, I know "start time", I have blocks printed out in stdout every minute so once sync is done I can count lines and get "end time" pretty accurate. And here are some results:

1. no "addnode" in darkcoin.conf
~54 minutes

2. issued "darkcoin masternode list", grabbed all IPs and pasted them in darkcoin.conf in form "connect=54.171.120.119" (yes, ~1200 lines)
block count visually was 2 times slower and when it reached ~50K blocks darkcoind crashed :eek:
Run second test on more time and get the same result...
Here is debug.log log output:
Code: 
2014-11-25 20:42:20 Unable to open file /home/username/.darkcoin/blocks/blk00000.dat
2014-11-25 20:42:20 ERROR: CBlock::WriteToDisk() : OpenBlockFile failed
2014-11-25 20:42:20 *** Failed to write block
2014-11-25 20:42:20 Error: Failed to write block
2014-11-25 20:42:20 ERROR: ProcessBlock() : AcceptBlock FAILED

Quite an unexpected result I must say :wink:

3. Cut list of nodes to ~600
again 2 times slower but at least it fully synced this time
~107 minutes

4. Cut list to ~300 nodes
and it was just like #3 and even a little bit slower (?)

I monitored connections all the time and there is something in bitcoin network code - it looks like it just wouldn't let you grab more and it manage peers a lot better on itself in that situation. This of course was a very "dumb&dirty" way and there must be some way to improve it but in general it looks like wallet manages peers quite good on itself.
Click to expand...
There is no added value in adding 100 addnode lines - outbound connections are hardcoded to 8, maxconnection setting is only affecting inbound connections.

Additionally the client is choosing a subset of peers to download blocks, not all.

So whatever you are trying to achieve with this large list: it will not work with vanilla client.
 
flare said:
There is no added value in adding 100 addnode lines - outbound connections are hardcoded to 8, maxconnection setting is only affecting inbound connections.

Additionally the client is choosing a subset of peers to download blocks, not all.

So whatever you are trying to achieve with this large list: it will not work with vanilla client.
Click to expand...
It was not "addnode", but "connect" so the point was - no matter how many connections wallet does all peers must be masternodes. I just tried to give wallet more masternode-peers to choose from.

EDIT: fixed previous post to make it sound cleaner, see "EDIT:" there
 
UdjinM6 said:
It was not "addnode", but "connect" so the point was - no matter how many connections wallet does all peers must be masternodes. I just tried to give wallet more masternode-peers to choose from.

EDIT: fixed previous post to make it sound cleaner, see "EDIT:" there
Click to expand...
Got it :) As far as i know the client will iterate from top of the connect entries, so the next 292 entries are basically ignored if a connection to the first 8 could be established ;)
 
flare said:
Got it :) As far as i know the client will iterate from top of the connect entries, so the next 292 entries are basically ignored if a connection to the first 8 could be established ;)
Click to expand...
Ahhhh... I was fooled by
https://github.com/darkcoin/darkcoin/blob/master/contrib/debian/examples/bitcoin.conf#L16-L19 :sad:
Code: 
# ... or use as many connect= settings as you like to connect ONLY
# to specific peers:
#connect=69.164.218.197
#connect=10.0.0.1:9333

and you're right, 8 connections only
https://github.com/darkcoin/darkcoin/blob/master/src/net.cpp#L1375-L1376
Code: 
            // use an nUnkBias between 10 (no outgoing connections) and 90 (8 outgoing connections)
            CAddress addr = addrman.Select(10 + min(nOutbound,8)*10);

EDIT: funny it's hardcoded while there is const
Code: 
static const int MAX_OUTBOUND_CONNECTIONS = 8;
and looks like there are few more places it used to limit connections
 
Last edited by a moderator:
Interestingly bitcoin has this

https://github.com/bitcoin/bitcoin/blob/9ff0bc9beb90cf96fb0a9698de22e2bc60fed2f2/src/main.h#L92-L96
Code: 
/** Size of the "block download window": how far ahead of our current height do we fetch?
*  Larger windows tolerate larger download speed differences between peer, but increase the potential
*  degree of disordering of blocks on disk (which make reindexing and in the future perhaps pruning
*  harder). We'll probably want to make this a per-peer adaptive value at some point. */
static const unsigned int BLOCK_DOWNLOAD_WINDOW = 1024;

https://github.com/bitcoin/bitcoin/...0a9698de22e2bc60fed2f2/src/main.cpp#L415-L419
Code: 
    // Never fetch further than the best block we know the peer has, or more than BLOCK_DOWNLOAD_WINDOW + 1 beyond the last
    // linked block we have in common with this peer. The +1 is so we can detect stalling, namely if we would be able to
    // download that next block if the window were 1 larger.
    int nWindowEnd = state->pindexLastCommonBlock->nHeight + BLOCK_DOWNLOAD_WINDOW;
    int nMaxHeight = std::min<int>(state->pindexBestKnownBlock->nHeight, nWindowEnd + 1);

Also there are few parts for discovering and dropping stalling peers that our source code is missing I believe, for example
https://github.com/bitcoin/bitcoin/...9698de22e2bc60fed2f2/src/main.cpp#L4593-L4601
Code: 
        // Detect whether we're stalling
        int64_t nNow = GetTimeMicros();
        if (!pto->fDisconnect && state.nStallingSince && state.nStallingSince < nNow - 1000000 * BLOCK_STALLING_TIMEOUT) {
            // Stalling only triggers when the block download window cannot move. During normal steady state,
            // the download window should be much larger than the to-be-downloaded set of blocks, so disconnection
            // should only happen during initial block download.
            LogPrintf("Peer=%d is stalling block download, disconnecting\n", pto->id);
            pto->fDisconnect = true;
        }
 
UdjinM6 said:
Interestingly bitcoin has this

https://github.com/bitcoin/bitcoin/blob/9ff0bc9beb90cf96fb0a9698de22e2bc60fed2f2/src/main.h#L92-L96
Code: 
/** Size of the "block download window": how far ahead of our current height do we fetch?
*  Larger windows tolerate larger download speed differences between peer, but increase the potential
*  degree of disordering of blocks on disk (which make reindexing and in the future perhaps pruning
*  harder). We'll probably want to make this a per-peer adaptive value at some point. */
static const unsigned int BLOCK_DOWNLOAD_WINDOW = 1024;

https://github.com/bitcoin/bitcoin/...0a9698de22e2bc60fed2f2/src/main.cpp#L415-L419
Code: 
    // Never fetch further than the best block we know the peer has, or more than BLOCK_DOWNLOAD_WINDOW + 1 beyond the last
    // linked block we have in common with this peer. The +1 is so we can detect stalling, namely if we would be able to
    // download that next block if the window were 1 larger.
    int nWindowEnd = state->pindexLastCommonBlock->nHeight + BLOCK_DOWNLOAD_WINDOW;
    int nMaxHeight = std::min<int>(state->pindexBestKnownBlock->nHeight, nWindowEnd + 1);

Also there are few parts for discovering and dropping stalling peers that our source code is missing I believe, for example
https://github.com/bitcoin/bitcoin/...9698de22e2bc60fed2f2/src/main.cpp#L4593-L4601
Code: 
        // Detect whether we're stalling
        int64_t nNow = GetTimeMicros();
        if (!pto->fDisconnect && state.nStallingSince && state.nStallingSince < nNow - 1000000 * BLOCK_STALLING_TIMEOUT) {
            // Stalling only triggers when the block download window cannot move. During normal steady state,
            // the download window should be much larger than the to-be-downloaded set of blocks, so disconnection
            // should only happen during initial block download.
            LogPrintf("Peer=%d is stalling block download, disconnecting\n", pto->id);
            pto->fDisconnect = true;
        }
Click to expand...
Yeah, i think these are optimisations in the 0.9.x codebase - darkcoin is based on bitcoin/litecoin 0.8.5

Any volounteers to port Darkcoin to 0.9.3 codebase?
 
vertoe said:
Would love to give it a try if you compile me a list of tasks. What needs to be done?

X11, DGW, Masternode payments ... ?
Click to expand...
Yeah, that should be more or less the minimal requirements to get a compatible client.
 
You must log in or register to reply here.
Back
Top