From: Matt Corallo <lf-lists@mattcorallo•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Node Speed Test
Date: Fri, 24 Jul 2015 02:48:03 +0000 [thread overview]
Message-ID: <55B1A763.3000000@mattcorallo.com> (raw)
In-Reply-To: <trinity-c97bc41b-a953-4580-b2d2-ebdda9eb96b2-1437661199263@3capp-mailcom-bs02>
You may see much better throughput if you run a few servers around the
globe and test based on closest-by-geoip. TCP throughput is rather
significantly effected by latency, though I'm not really sure what you
should be testing here, ideally.
On 07/23/15 14:19, 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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
next prev parent reply other threads:[~2015-07-24 2:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-23 14:19 slurms
2015-07-23 15:04 ` Gavin Andresen
2015-07-23 15:55 ` Jameson Lopp
2015-07-23 17:14 ` Slurms MacKenzie
2015-07-23 17:41 ` Pindar Wong
2015-07-23 16:05 ` Peter Todd
2015-07-23 19:56 ` Marcel Jamin
2015-07-23 19:57 ` Joseph Gleason ⑈
2015-07-24 2:55 ` Peter Todd
2015-07-23 16:36 ` Leo Wandersleb
2015-07-23 17:12 ` Slurms MacKenzie
2015-07-24 2:48 ` Matt Corallo [this message]
2015-07-24 3:19 ` Slurms MacKenzie
2015-07-24 3:54 ` grarpamp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55B1A763.3000000@mattcorallo.com \
--to=lf-lists@mattcorallo$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox