📅 Original date posted:2015-11-28
📝 Original message:Hi All,
Here are some final results of testing with the reference implementation
for compressing blocks and transactions. This implementation also
concatenates blocks and transactions when possible so you'll see data
sizes in the 1-2MB ranges.
Results below show the time it takes to sync the first part of the
blockchain, comparing Zlib to the LZOx library. (LZOf was also tried
but wasn't found to be as good as LZOx). The following shows tests run
with and without latency. With latency on the network, all compression
libraries performed much better than without compression.
I don't think it's entirely obvious which is better, Zlib or LZO.
Although I prefer the higher compression of Zlib, overall I would have
to give the edge to LZO. With LZO we have the fastest most scalable
option when at the lowest compression setting which will be a boost in
performance for users that want peformance over compression, and then at
the high end LZO provides decent compression which approaches Zlib,
(although at a higher cost) but good for those that want to save more
bandwidth.
Uncompressed 60ms Zlib-1 (60ms) Zlib-6 (60ms) LZOx-1 (60ms) LZOx-999
(60ms)
219 299 296 294 291
432 568 565 558 548
652 835 836 819 811
866 1106 1107 1081 1071
1082 1372 1381 1341 1333
1309 1644 1654 1605 1600
1535 1917 1936 1873 1875
1762 2191 2210 2141 2141
1992 2463 2486 2411 2411
2257 2748 2780 2694 2697
2627 3034 3076 2970 2983
3226 3416 3397 3266 3302
4010 3983 3773 3625 3703
4914 4503 4292 4127 4287
5806 4928 4719 4529 4821
6674 5249 5164 4840 5314
7563 5603 5669 5289 6002
8477 6054 6268 5858 6638
9843 7085 7278 6868 7679
11338 8215 8433 8044 8795
These results from testing on a highspeed wireless LAN (very small latency)
Results in seconds
Num blocks sync'd Uncompressed Zlib-1 Zlib-6 LZOx-1 LZOx-999
10000 255 232 233 231 257
20000 464 414 420 407 453
30000 677 594 611 585 650
40000 887 782 795 760 849
50000 1099 961 977 933 1048
60000 1310 1145 1167 1110 1259
70000 1512 1330 1362 1291 1470
80000 1714 1519 1552 1469 1679
90000 1917 1707 1747 1650 1882
100000 2122 1905 1950 1843 2111
110000 2333 2107 2151 2038 2329
120000 2560 2333 2376 2256 2580
130000 2835 2656 2679 2558 2921
140000 3274 3259 3161 3051 3466
150000 3662 3793 3547 3440 3919
160000 4040 4172 3937 3767 4416
170000 4425 4625 4379 4215 4958
180000 4860 5149 4895 4781 5560
190000 5855 6160 5898 5805 6557
200000 7004 7234 7051 6983 7770
The following show the compression ratio acheived for various sizes of
data. Zlib is the clear
winner for compressibility, with LZOx-999 coming close but at a cost.
range Zlib-1 cmp%
Zlib-6 cmp% LZOx-1 cmp% LZOx-999 cmp%
0-250b 12.44 12.86 10.79 14.34
250-500b 19.33 12.97 10.34 11.11
600-700 16.72 n/a 12.91 17.25
700-800 6.37 7.65 4.83 8.07
900-1KB 6.54 6.95 5.64 7.9
1KB-10KB 25.08 25.65 21.21 22.65
10KB-100KB 19.77 21.57 14.37 19.02
100KB-200KB 21.49 23.56 15.37 21.55
200KB-300KB 23.66 24.18 16.91 22.76
300KB-400KB 23.4 23.7 16.5 21.38
400KB-500KB 24.6 24.85 17.56 22.43
500KB-600KB 25.51 26.55 18.51 23.4
600KB-700KB 27.25 28.41 19.91 25.46
700KB-800KB 27.58 29.18 20.26 27.17
800KB-900KB 27 29.11 20 27.4
900KB-1MB 28.19 29.38 21.15 26.43
1MB -2MB 27.41 29.46 21.33 27.73
The following shows the time in seconds to compress data of various
sizes. LZO1x is the
fastest and as file sizes increase, LZO1x time hardly increases at all.
It's interesing
to note as compression ratios increase LZOx-999 performs much worse than
Zlib. So LZO is faster
on the low end and slower (5 to 6 times slower) on the high end.
range Zlib-1 Zlib-6 LZOx-1 LZOx-999 cmp%
0-250b 0.001 0 0 0
250-500b 0 0 0 0.001
500-1KB 0 0 0 0.001
1KB-10KB 0.001 0.001 0 0.002
10KB-100KB 0.004 0.006 0.001 0.017
100KB-200KB 0.012 0.017 0.002 0.054
200KB-300KB 0.018 0.024 0.003 0.087
300KB-400KB 0.022 0.03 0.003 0.121
400KB-500KB 0.027 0.037 0.004 0.151
500KB-600KB 0.031 0.044 0.004 0.184
600KB-700KB 0.035 0.051 0.006 0.211
700KB-800KB 0.039 0.057 0.006 0.243
800KB-900KB 0.045 0.064 0.006 0.27
900KB-1MB 0.049 0.072 0.006 0.307
On 10/11/2015 8:46 AM, Jeff Garzik via bitcoin-dev wrote:
> Comments:
>
> 1) cblock seems a reasonable way to extend the protocol. Further
> wrapping should probably be done at the stream level.
>
> 2) zlib has crappy security track record.
>
> 3) A fallback path to non-compressed is required, should compression
> fail or crash.
>
> 4) Most blocks and transactions have runs of zeroes and/or highly
> common bit-patterns, which contributes to useful compression even at
> smaller sizes. Peter Ts's most recent numbers bear this out. zlib
> has a dictionary (32K?) which works well with repeated patterns such
> as those you see with concatenated runs of transactions.
>
> 5) LZO should provide much better compression, at a cost of CPU
> performance and using a less-reviewed, less-field-tested library.
>
>
>
>
>
> On Tue, Nov 10, 2015 at 11:30 AM, Tier Nolan via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>
>
> On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper
> <peter.tschipper at gmail.com <mailto:peter.tschipper at gmail.com>> wrote:
>
> There are better ways of sending new blocks, that's certainly
> true but for sending historical blocks and seding transactions
> I don't think so. This PR is really designed to save
> bandwidth and not intended to be a huge performance
> improvement in terms of time spent sending.
>
>
> If the main point is for historical data, then sticking to just
> blocks is the best plan.
>
> Since small blocks don't compress well, you could define a
> "cblocks" message that handles multiple blocks (just concatenate
> the block messages as payload before compression).
>
> The sending peer could combine blocks so that each cblock is
> compressing at least 10kB of block data (or whatever is optimal).
> It is probably worth specifying a maximum size for network buffer
> reasons (either 1MB or 1 block maximum).
>
> Similarly, transactions could be combined together and compressed
> "ctxs". The inv messages could be modified so that you can
> request groups of 10-20 transactions. That would depend on how
> much of an improvement compressed transactions would represent.
>
> More generally, you could define a message which is a compressed
> message holder. That is probably to complex to be worth the
> effort though.
>
>
>
>>
>> On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via
>> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>> On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>>
>>
>> I think 25% bandwidth savings is certainly
>> considerable, especially for people running full
>> nodes in countries like Australia where internet
>> bandwidth is lower and there are data caps.
>>
>>
>> This reinforces the idea that such trade-off decisions
>> should be be local and negotiated between peers, not a
>> required feature of the network P2P.
>>
>>
>> --
>> Johnathan Corgan
>> Corgan Labs - SDR Training and Development Services
>> http://corganlabs.com
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> <mailto:bitcoin-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151128/66db15c2/attachment-0001.html>;
Peter Tschipper [ARCHIVE] /
npub14s…653tk
2023-06-07 17:44:29
in reply to nevent1q…eyjh
Author Public Key
npub14sxt5nq5l8hfvd7yfcmh8gwjqhtzcc72vz2lcwd2uw0xlllwdayqk653tkPublished at
2023-06-07 17:44:29Event JSON
{
"id": "4fd28c589e3543dd0fe5cee665710199cf302e647252944903731d23d6e5933d",
"pubkey": "ac0cba4c14f9ee9637c44e3773a1d205d62c63ca6095fc39aae39e6fffee6f48",
"created_at": 1686159869,
"kind": 1,
"tags": [
[
"e",
"84369a26441b7d441d061528858b739bf733243d62d00f78dc0ea02a98ab0a00",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-11-28\n📝 Original message:Hi All,\n\nHere are some final results of testing with the reference implementation\nfor compressing blocks and transactions. This implementation also\nconcatenates blocks and transactions when possible so you'll see data\nsizes in the 1-2MB ranges.\n\nResults below show the time it takes to sync the first part of the\nblockchain, comparing Zlib to the LZOx library. (LZOf was also tried\nbut wasn't found to be as good as LZOx). The following shows tests run\nwith and without latency. With latency on the network, all compression\nlibraries performed much better than without compression.\n\nI don't think it's entirely obvious which is better, Zlib or LZO. \nAlthough I prefer the higher compression of Zlib, overall I would have\nto give the edge to LZO. With LZO we have the fastest most scalable\noption when at the lowest compression setting which will be a boost in\nperformance for users that want peformance over compression, and then at\nthe high end LZO provides decent compression which approaches Zlib,\n(although at a higher cost) but good for those that want to save more\nbandwidth.\n\nUncompressed 60ms \tZlib-1 (60ms) \tZlib-6 (60ms) \tLZOx-1 (60ms) \tLZOx-999\n(60ms)\n219 \t299 \t296 \t294 \t291\n432 \t568 \t565 \t558 \t548\n652 \t835 \t836 \t819 \t811\n866 \t1106 \t1107 \t1081 \t1071\n1082 \t1372 \t1381 \t1341 \t1333\n1309 \t1644 \t1654 \t1605 \t1600\n1535 \t1917 \t1936 \t1873 \t1875\n1762 \t2191 \t2210 \t2141 \t2141\n1992 \t2463 \t2486 \t2411 \t2411\n2257 \t2748 \t2780 \t2694 \t2697\n2627 \t3034 \t3076 \t2970 \t2983\n3226 \t3416 \t3397 \t3266 \t3302\n4010 \t3983 \t3773 \t3625 \t3703\n4914 \t4503 \t4292 \t4127 \t4287\n5806 \t4928 \t4719 \t4529 \t4821\n6674 \t5249 \t5164 \t4840 \t5314\n7563 \t5603 \t5669 \t5289 \t6002\n8477 \t6054 \t6268 \t5858 \t6638\n9843 \t7085 \t7278 \t6868 \t7679\n11338 \t8215 \t8433 \t8044 \t8795\n\n\n\nThese results from testing on a highspeed wireless LAN (very small latency)\n\nResults in seconds \t\n\t\n\t\n\t\n\t\nNum blocks sync'd \tUncompressed \tZlib-1 \tZlib-6 \tLZOx-1 \tLZOx-999\n10000 \t255 \t232 \t233 \t231 \t257\n20000 \t464 \t414 \t420 \t407 \t453\n30000 \t677 \t594 \t611 \t585 \t650\n40000 \t887 \t782 \t795 \t760 \t849\n50000 \t1099 \t961 \t977 \t933 \t1048\n60000 \t1310 \t1145 \t1167 \t1110 \t1259\n70000 \t1512 \t1330 \t1362 \t1291 \t1470\n80000 \t1714 \t1519 \t1552 \t1469 \t1679\n90000 \t1917 \t1707 \t1747 \t1650 \t1882\n100000 \t2122 \t1905 \t1950 \t1843 \t2111\n110000 \t2333 \t2107 \t2151 \t2038 \t2329\n120000 \t2560 \t2333 \t2376 \t2256 \t2580\n130000 \t2835 \t2656 \t2679 \t2558 \t2921\n140000 \t3274 \t3259 \t3161 \t3051 \t3466\n150000 \t3662 \t3793 \t3547 \t3440 \t3919\n160000 \t4040 \t4172 \t3937 \t3767 \t4416\n170000 \t4425 \t4625 \t4379 \t4215 \t4958\n180000 \t4860 \t5149 \t4895 \t4781 \t5560\n190000 \t5855 \t6160 \t5898 \t5805 \t6557\n200000 \t7004 \t7234 \t7051 \t6983 \t7770\n\n\n\nThe following show the compression ratio acheived for various sizes of\ndata. Zlib is the clear\nwinner for compressibility, with LZOx-999 coming close but at a cost.\n\nrange \tZlib-1 cmp%\n\tZlib-6 cmp% \tLZOx-1 cmp% \tLZOx-999 cmp%\n0-250b \t12.44 \t12.86 \t10.79 \t14.34\n250-500b \t19.33 \t12.97 \t10.34 \t11.11\n600-700 \t16.72 \tn/a \t12.91 \t17.25\n700-800 \t6.37 \t7.65 \t4.83 \t8.07\n900-1KB \t6.54 \t6.95 \t5.64 \t7.9\n1KB-10KB \t25.08 \t25.65 \t21.21 \t22.65\n10KB-100KB \t19.77 \t21.57 \t14.37 \t19.02\n100KB-200KB \t21.49 \t23.56 \t15.37 \t21.55\n200KB-300KB \t23.66 \t24.18 \t16.91 \t22.76\n300KB-400KB \t23.4 \t23.7 \t16.5 \t21.38\n400KB-500KB \t24.6 \t24.85 \t17.56 \t22.43\n500KB-600KB \t25.51 \t26.55 \t18.51 \t23.4\n600KB-700KB \t27.25 \t28.41 \t19.91 \t25.46\n700KB-800KB \t27.58 \t29.18 \t20.26 \t27.17\n800KB-900KB \t27 \t29.11 \t20 \t27.4\n900KB-1MB \t28.19 \t29.38 \t21.15 \t26.43\n1MB -2MB \t27.41 \t29.46 \t21.33 \t27.73\n\n\nThe following shows the time in seconds to compress data of various\nsizes. LZO1x is the\nfastest and as file sizes increase, LZO1x time hardly increases at all. \nIt's interesing\nto note as compression ratios increase LZOx-999 performs much worse than\nZlib. So LZO is faster\non the low end and slower (5 to 6 times slower) on the high end.\n\nrange \tZlib-1 \tZlib-6 \tLZOx-1 \tLZOx-999 cmp%\n0-250b \t0.001 \t0 \t0 \t0\n250-500b \t0 \t0 \t0 \t0.001\n500-1KB \t0 \t0 \t0 \t0.001\n1KB-10KB \t0.001 \t0.001 \t0 \t0.002\n10KB-100KB \t0.004 \t0.006 \t0.001 \t0.017\n100KB-200KB \t0.012 \t0.017 \t0.002 \t0.054\n200KB-300KB \t0.018 \t0.024 \t0.003 \t0.087\n300KB-400KB \t0.022 \t0.03 \t0.003 \t0.121\n400KB-500KB \t0.027 \t0.037 \t0.004 \t0.151\n500KB-600KB \t0.031 \t0.044 \t0.004 \t0.184\n600KB-700KB \t0.035 \t0.051 \t0.006 \t0.211\n700KB-800KB \t0.039 \t0.057 \t0.006 \t0.243\n800KB-900KB \t0.045 \t0.064 \t0.006 \t0.27\n900KB-1MB \t0.049 \t0.072 \t0.006 \t0.307\n\n\nOn 10/11/2015 8:46 AM, Jeff Garzik via bitcoin-dev wrote:\n\u003e Comments:\n\u003e\n\u003e 1) cblock seems a reasonable way to extend the protocol. Further\n\u003e wrapping should probably be done at the stream level.\n\u003e\n\u003e 2) zlib has crappy security track record.\n\u003e\n\u003e 3) A fallback path to non-compressed is required, should compression\n\u003e fail or crash.\n\u003e\n\u003e 4) Most blocks and transactions have runs of zeroes and/or highly\n\u003e common bit-patterns, which contributes to useful compression even at\n\u003e smaller sizes. Peter Ts's most recent numbers bear this out. zlib\n\u003e has a dictionary (32K?) which works well with repeated patterns such\n\u003e as those you see with concatenated runs of transactions.\n\u003e\n\u003e 5) LZO should provide much better compression, at a cost of CPU\n\u003e performance and using a less-reviewed, less-field-tested library.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e On Tue, Nov 10, 2015 at 11:30 AM, Tier Nolan via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\n\u003e\n\u003e\n\u003e On Tue, Nov 10, 2015 at 4:11 PM, Peter Tschipper\n\u003e \u003cpeter.tschipper at gmail.com \u003cmailto:peter.tschipper at gmail.com\u003e\u003e wrote:\n\u003e\n\u003e There are better ways of sending new blocks, that's certainly\n\u003e true but for sending historical blocks and seding transactions\n\u003e I don't think so. This PR is really designed to save\n\u003e bandwidth and not intended to be a huge performance\n\u003e improvement in terms of time spent sending.\n\u003e\n\u003e\n\u003e If the main point is for historical data, then sticking to just\n\u003e blocks is the best plan.\n\u003e\n\u003e Since small blocks don't compress well, you could define a\n\u003e \"cblocks\" message that handles multiple blocks (just concatenate\n\u003e the block messages as payload before compression). \n\u003e\n\u003e The sending peer could combine blocks so that each cblock is\n\u003e compressing at least 10kB of block data (or whatever is optimal). \n\u003e It is probably worth specifying a maximum size for network buffer\n\u003e reasons (either 1MB or 1 block maximum).\n\u003e\n\u003e Similarly, transactions could be combined together and compressed\n\u003e \"ctxs\". The inv messages could be modified so that you can\n\u003e request groups of 10-20 transactions. That would depend on how\n\u003e much of an improvement compressed transactions would represent.\n\u003e\n\u003e More generally, you could define a message which is a compressed\n\u003e message holder. That is probably to complex to be worth the\n\u003e effort though.\n\u003e\n\u003e \n\u003e\n\u003e\u003e\n\u003e\u003e On Tue, Nov 10, 2015 at 5:40 AM, Johnathan Corgan via\n\u003e\u003e bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e On Mon, Nov 9, 2015 at 5:58 PM, gladoscc via bitcoin-dev\n\u003e\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e\u003e \n\u003e\u003e\n\u003e\u003e I think 25% bandwidth savings is certainly\n\u003e\u003e considerable, especially for people running full\n\u003e\u003e nodes in countries like Australia where internet\n\u003e\u003e bandwidth is lower and there are data caps.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e This reinforces the idea that such trade-off decisions\n\u003e\u003e should be be local and negotiated between peers, not a\n\u003e\u003e required feature of the network P2P.\n\u003e\u003e \n\u003e\u003e\n\u003e\u003e -- \n\u003e\u003e Johnathan Corgan\n\u003e\u003e Corgan Labs - SDR Training and Development Services\n\u003e\u003e http://corganlabs.com\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151128/66db15c2/attachment-0001.html\u003e",
"sig": "c7241bd3dba0ae46220dcca924e67d8939f5e909043c6e5670e81355a1b207a21af368b1d3ec7398f18b2dcc2bd1af44c018e618ba7de5ba47b50d525c81d226"
}