📅 Original date posted:2015-07-23
📝 Original message:This looks like the beginnings of some great analysis.
Per Peter's remarks, I think it would be productive to run the test(s) on a
simulated network with worst case network failure(s) so that we can
determine the safety margin needed.
I have potential access to h/w resources that would be available for
running such tests at the necessary scales.
Cheers,
p.
On Fri, Jul 24, 2015 at 1:14 AM, Slurms MacKenzie via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The library used isn't open source, so unfortunately not. It shouldn't be
> too hard to replicate in python-bitcoinlib or bitcoinj though.
>
> *Sent:* Thursday, July 23, 2015 at 6:55 PM
> *From:* "Jameson Lopp" <jameson.lopp at gmail.com>
> *To:* slurms at gmx.us
> *Cc:* bitcoin-dev at lists.linuxfoundation.org
> *Subject:* Re: [bitcoin-dev] Bitcoin Node Speed Test
> Are you willing to share the code that you used to run the test?
>
> - Jameson
>
> On Thu, Jul 23, 2015 at 10:19 AM, slurms--- via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> 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
>
>
> _______________________________________________
> 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/20150724/48d9276d/attachment.html>;
Pindar Wong [ARCHIVE] /
npub1gg…t7uvk
2023-06-07 15:43:19
in reply to nevent1q…3rtj
Author Public Key
npub1gg0pysd236d4em7pts906ev9kf6f30j8werd40j2vwpes7fqdn4qtt7uvkSeen on
wss://relay.noswhere.comPublished at
2023-06-07 15:43:19Event JSON
{
"id": "882aa4562661b96855f3e0cbd213b65636154e6c30b56b24c72b6a1f74ba4694",
"pubkey": "421e1241aa8e9b5cefc15c0afd6585b27498be477646dabe4a63839879206cea",
"created_at": 1686152599,
"kind": 1,
"tags": [
[
"e",
"db0eb2204009a6b618d874147fda66733ace7abb340d9450e85ebe8e0a9d6b6a",
"",
"root"
],
[
"e",
"7f98880ddcf55b2373c71d0c4b805681e6d802d53f96577af2d72b243d6aa50b",
"",
"reply"
],
[
"p",
"d1e5e343064328be063c36deb0dacb660b8589dcbca90112f9c449503b63ebba"
]
],
"content": "📅 Original date posted:2015-07-23\n📝 Original message:This looks like the beginnings of some great analysis.\n\nPer Peter's remarks, I think it would be productive to run the test(s) on a\nsimulated network with worst case network failure(s) so that we can\ndetermine the safety margin needed.\n\nI have potential access to h/w resources that would be available for\nrunning such tests at the necessary scales.\n\nCheers,\n\np.\n\n\nOn Fri, Jul 24, 2015 at 1:14 AM, Slurms MacKenzie via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e The library used isn't open source, so unfortunately not. It shouldn't be\n\u003e too hard to replicate in python-bitcoinlib or bitcoinj though.\n\u003e\n\u003e *Sent:* Thursday, July 23, 2015 at 6:55 PM\n\u003e *From:* \"Jameson Lopp\" \u003cjameson.lopp at gmail.com\u003e\n\u003e *To:* slurms at gmx.us\n\u003e *Cc:* bitcoin-dev at lists.linuxfoundation.org\n\u003e *Subject:* Re: [bitcoin-dev] Bitcoin Node Speed Test\n\u003e Are you willing to share the code that you used to run the test?\n\u003e\n\u003e - Jameson\n\u003e\n\u003e On Thu, Jul 23, 2015 at 10:19 AM, slurms--- via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e On this day, the Bitcoin network was crawled and reachable nodes surveyed\n\u003e\u003e to find their maximum throughput in order to determine if it can safely\n\u003e\u003e support a faster block rate. Specifically this is an attempt to prove or\n\u003e\u003e disprove the common statement that 1MB blocks were only suitable slower\n\u003e\u003e internet connections in 2009 when Bitcoin launched, and that connection\n\u003e\u003e speeds have improved to the point of obviously supporting larger blocks.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e The testing methodology is as follows:\n\u003e\u003e\n\u003e\u003e * Nodes were randomly selected from a peers.dat, 5% of the reachable\n\u003e\u003e nodes in the network were contacted.\n\u003e\u003e\n\u003e\u003e * A random selection of blocks was downloaded from each peer.\n\u003e\u003e\n\u003e\u003e * There is some bias towards higher connection speeds, very slow\n\u003e\u003e connections (\u003c30KB/s) timed out in order to run the test at a reasonable\n\u003e\u003e rate.\n\u003e\u003e\n\u003e\u003e * The connecting node was in Amsterdam with a 1GB NIC.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Results:\n\u003e\u003e\n\u003e\u003e * 37% of connected nodes failed to upload blocks faster than 1MB/s.\n\u003e\u003e\n\u003e\u003e * 16% of connected nodes uploaded blocks faster than 10MB/s.\n\u003e\u003e\n\u003e\u003e * Raw data, one line per connected node, kilobytes per second\n\u003e\u003e http://pastebin.com/raw.php?i=6b4NuiVQ\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e This does not support the theory that the network has the available\n\u003e\u003e bandwidth for increased block sizes, as in its current state 37% of nodes\n\u003e\u003e would fail to upload a 20MB block to a single peer in under 20 seconds\n\u003e\u003e (referencing a number quoted by Gavin). If the bar for suitability is\n\u003e\u003e placed at taking only 1% of the block time (6 seconds) to upload one block\n\u003e\u003e to one peer, then 69% of the network fails for 20MB blocks. For comparison,\n\u003e\u003e only 10% fail this metric for 1MB blocks.\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\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\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150724/48d9276d/attachment.html\u003e",
"sig": "56ba097e00f2ae1403a07cdb79a40718717f34449d6d24e329b746df4459164c3f977c2c95fe070bdbb941d1d85fef260835e0a0edc7cdb72ba13445fefde0fb"
}