📅 Original date posted:2015-07-23
📝 Original message:Thank you a lot for doing this test!
Two questions:
1) A node is typically connected to many nodes that would all in parallel
download said block. In your test you measured how fast new blocks that
presumably are being uploaded in parallel to all those other nodes are being
uploaded? Or did you download blocks while those nodes were basically idle?
2) What is your percentage of the very slow connections?
On 07/23/2015 11:19 AM, slurms--- via bitcoin-dev wrote:
> On this day, the Bitcoin network was crawled and reachable nodes surveyed to find their maximum throughput in order to determine if it can safely support a faster block rate. Specifically this is an attempt to prove or disprove the common statement that 1MB blocks were only suitable slower internet connections in 2009 when Bitcoin launched, and that connection speeds have improved to the point of obviously supporting larger blocks.
>
>
> The testing methodology is as follows:
>
> * Nodes were randomly selected from a peers.dat, 5% of the reachable nodes in the network were contacted.
>
> * A random selection of blocks was downloaded from each peer.
>
> * There is some bias towards higher connection speeds, very slow connections (<30KB/s) timed out in order to run the test at a reasonable rate.
>
> * The connecting node was in Amsterdam with a 1GB NIC.
>
>
> Results:
>
> * 37% of connected nodes failed to upload blocks faster than 1MB/s.
>
> * 16% of connected nodes uploaded blocks faster than 10MB/s.
>
> * Raw data, one line per connected node, kilobytes per second http://pastebin.com/raw.php?i=6b4NuiVQ
>
>
> This does not support the theory that the network has the available bandwidth for increased block sizes, as in its current state 37% of nodes would fail to upload a 20MB block to a single peer in under 20 seconds (referencing a number quoted by Gavin). If the bar for suitability is placed at taking only 1% of the block time (6 seconds) to upload one block to one peer, then 69% of the network fails for 20MB blocks. For comparison, only 10% fail this metric for 1MB blocks.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/042b0879/attachment-0001.sig>;
Leo Wandersleb [ARCHIVE] /
npub13l…skwkm
2023-06-07 15:43:20
in reply to nevent1q…t9lg
Author Public Key
npub13lchmhzu8cv25gxwcksn6jymnlvlu3zzh4az5aa3h799evyw6kdq7skwkmPublished at
2023-06-07 15:43:20Event JSON
{
"id": "7dd2b784ef72c1f1717b47a5bfe4ddecd7590574a693c5a431cb741b57f11eaa",
"pubkey": "8ff17ddc5c3e18aa20cec5a13d489b9fd9fe4442bd7a2a77b1bf8a5cb08ed59a",
"created_at": 1686152600,
"kind": 1,
"tags": [
[
"e",
"db0eb2204009a6b618d874147fda66733ace7abb340d9450e85ebe8e0a9d6b6a",
"",
"root"
],
[
"e",
"b0eb5410a18a7aeca8aef1b62c30ee194239488390f931b594fb737d113059e8",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2015-07-23\n📝 Original message:Thank you a lot for doing this test!\n\nTwo questions:\n\n1) A node is typically connected to many nodes that would all in parallel\ndownload said block. In your test you measured how fast new blocks that\npresumably are being uploaded in parallel to all those other nodes are being\nuploaded? Or did you download blocks while those nodes were basically idle?\n\n2) What is your percentage of the very slow connections?\n\nOn 07/23/2015 11:19 AM, slurms--- via bitcoin-dev wrote:\n\u003e On this day, the Bitcoin network was crawled and reachable nodes surveyed to find their maximum throughput in order to determine if it can safely support a faster block rate. Specifically this is an attempt to prove or disprove the common statement that 1MB blocks were only suitable slower internet connections in 2009 when Bitcoin launched, and that connection speeds have improved to the point of obviously supporting larger blocks.\n\u003e\n\u003e\n\u003e The testing methodology is as follows:\n\u003e\n\u003e * Nodes were randomly selected from a peers.dat, 5% of the reachable nodes in the network were contacted.\n\u003e\n\u003e * A random selection of blocks was downloaded from each peer.\n\u003e\n\u003e * There is some bias towards higher connection speeds, very slow connections (\u003c30KB/s) timed out in order to run the test at a reasonable rate.\n\u003e\n\u003e * The connecting node was in Amsterdam with a 1GB NIC. \n\u003e\n\u003e \n\u003e Results:\n\u003e\n\u003e * 37% of connected nodes failed to upload blocks faster than 1MB/s.\n\u003e\n\u003e * 16% of connected nodes uploaded blocks faster than 10MB/s.\n\u003e\n\u003e * Raw data, one line per connected node, kilobytes per second http://pastebin.com/raw.php?i=6b4NuiVQ\n\u003e\n\u003e\n\u003e This does not support the theory that the network has the available bandwidth for increased block sizes, as in its current state 37% of nodes would fail to upload a 20MB block to a single peer in under 20 seconds (referencing a number quoted by Gavin). If the bar for suitability is placed at taking only 1% of the block time (6 seconds) to upload one block to one peer, then 69% of the network fails for 20MB blocks. For comparison, only 10% fail this metric for 1MB blocks.\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\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 473 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/042b0879/attachment-0001.sig\u003e",
"sig": "936067f569fd21a5ea0709effb85573ae08fe87e5cca164df4ea1981cacd45d13f7d99d2f39e1ead64f05f45a8bf47e63e9b0ae6450a20dd354bb2af6fa20170"
}