📅 Original date posted:2015-11-13
📝 Original message:Some further Block Compression tests results that compare performance
when network latency is added to the mix.
Running two nodes, windows 7, compressionlevel=6, syncing the first
200000 blocks from one node to another. Running on a highspeed wireless
LAN with no connections to the outside world.
Network latency was added by using Netbalancer to induce the 30ms and
60ms latencies.
>From the data not only are bandwidth savings seen but also a small
performance savings as well. However, the overall the value in
compressing blocks appears to be in terms of saving bandwidth.
I was also surprised to see that there was no real difference in
performance when no latency was present; apparently the time it takes to
compress is about equal to the performance savings in such a situation.
The following results compare the tests in terms of how long it takes to
sync the blockchain, compressed vs uncompressed and with varying latencies.
uncmp = uncompressed
cmp = compressed
num blocks sync'd uncmp (secs) cmp (secs) uncmp 30ms (secs) cmp 30ms
(secs) uncmp 60ms (secs) cmp 60ms (secs)
10000 264 269 265 257 274 275
20000 482 492 479 467 499 497
30000 703 717 693 676 724 724
40000 918 939 902 886 947 944
50000 1140 1157 1114 1094 1171 1167
60000 1362 1380 1329 1310 1400 1395
70000 1583 1597 1547 1526 1637 1627
80000 1810 1817 1767 1745 1872 1862
90000 2031 2036 1985 1958 2109 2098
100000 2257 2260 2223 2184 2385 2355
110000 2553 2486 2478 2422 2755 2696
120000 2800 2724 2849 2771 3345 3254
130000 3078 2994 3356 3257 4125 4006
140000 3442 3365 3979 3870 5032 4904
150000 3803 3729 4586 4464 5928 5797
160000 4148 4075 5168 5034 6801 6661
170000 4509 4479 5768 5619 7711 7557
180000 4947 4924 6389 6227 8653 8479
190000 5858 5855 7302 7107 9768 9566
200000 6980 6969 8469 8220 10944 10724
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151113/885c94a1/attachment-0001.html>;
Peter Tschipper [ARCHIVE] /
npub14s…653tk
2023-06-07 17:44:28
in reply to nevent1q…tzej
Author Public Key
npub14sxt5nq5l8hfvd7yfcmh8gwjqhtzcc72vz2lcwd2uw0xlllwdayqk653tkPublished at
2023-06-07 17:44:28Event JSON
{
"id": "01533a218fd3a470e70ce3fd08e3f39de9611d66e32df6e6db43688431757abb",
"pubkey": "ac0cba4c14f9ee9637c44e3773a1d205d62c63ca6095fc39aae39e6fffee6f48",
"created_at": 1686159868,
"kind": 1,
"tags": [
[
"e",
"c4cc7bb03f90f5af1b76d74ea12925aa27cdc16114cf27ac761e529caa6cce42",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-11-13\n📝 Original message:Some further Block Compression tests results that compare performance\nwhen network latency is added to the mix.\n\nRunning two nodes, windows 7, compressionlevel=6, syncing the first\n200000 blocks from one node to another. Running on a highspeed wireless\nLAN with no connections to the outside world.\nNetwork latency was added by using Netbalancer to induce the 30ms and\n60ms latencies.\n\n\u003eFrom the data not only are bandwidth savings seen but also a small\nperformance savings as well. However, the overall the value in\ncompressing blocks appears to be in terms of saving bandwidth. \n\nI was also surprised to see that there was no real difference in\nperformance when no latency was present; apparently the time it takes to\ncompress is about equal to the performance savings in such a situation.\n\n\nThe following results compare the tests in terms of how long it takes to\nsync the blockchain, compressed vs uncompressed and with varying latencies.\nuncmp = uncompressed\ncmp = compressed\n\nnum blocks sync'd \tuncmp (secs) \tcmp (secs) \tuncmp 30ms (secs) \tcmp 30ms\n(secs) \tuncmp 60ms (secs) \tcmp 60ms (secs)\n10000 \t264 \t269 \t265 \t257 \t274 \t275\n20000 \t482 \t492 \t479 \t467 \t499 \t497\n30000 \t703 \t717 \t693 \t676 \t724 \t724\n40000 \t918 \t939 \t902 \t886 \t947 \t944\n50000 \t1140 \t1157 \t1114 \t1094 \t1171 \t1167\n60000 \t1362 \t1380 \t1329 \t1310 \t1400 \t1395\n70000 \t1583 \t1597 \t1547 \t1526 \t1637 \t1627\n80000 \t1810 \t1817 \t1767 \t1745 \t1872 \t1862\n90000 \t2031 \t2036 \t1985 \t1958 \t2109 \t2098\n100000 \t2257 \t2260 \t2223 \t2184 \t2385 \t2355\n110000 \t2553 \t2486 \t2478 \t2422 \t2755 \t2696\n120000 \t2800 \t2724 \t2849 \t2771 \t3345 \t3254\n130000 \t3078 \t2994 \t3356 \t3257 \t4125 \t4006\n140000 \t3442 \t3365 \t3979 \t3870 \t5032 \t4904\n150000 \t3803 \t3729 \t4586 \t4464 \t5928 \t5797\n160000 \t4148 \t4075 \t5168 \t5034 \t6801 \t6661\n170000 \t4509 \t4479 \t5768 \t5619 \t7711 \t7557\n180000 \t4947 \t4924 \t6389 \t6227 \t8653 \t8479\n190000 \t5858 \t5855 \t7302 \t7107 \t9768 \t9566\n200000 \t6980 \t6969 \t8469 \t8220 \t10944 \t10724\n\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151113/885c94a1/attachment-0001.html\u003e",
"sig": "787a6f3ed513ec8dff8637eb77b0734aa3970a517bc548c36ccccaf5210169404dc1b011bdf09879ed8e3fd8244c273ea32d37d2a90ac68f3dd845ab7601446a"
}