Message-ID: <55B11825.90700@LeoWandersleb.de>
Date: Thu, 23 Jul 2015 13:36:53 -0300
From: Leo Wandersleb <leo@LeoWandersleb.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: bitcoin-dev@lists.linuxfoundation.org
References: <trinity-c97bc41b-a953-4580-b2d2-ebdda9eb96b2-1437661199263@3capp-mailcom-bs02>
In-Reply-To: <trinity-c97bc41b-a953-4580-b2d2-ebdda9eb96b2-1437661199263@3capp-mailcom-bs02>
OpenPGP: id=FAE4D5168E9EF9F104AA1B2D6B9A1F0CB7C20812
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="0sxK7gNAVdqP3KVcXG3QwVU5sUjNt3so0"
Subject: Re: [bitcoin-dev] Bitcoin Node Speed Test
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--0sxK7gNAVdqP3KVcXG3QwVU5sUjNt3so0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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 be=
ing
uploaded? Or did you download blocks while those nodes were basically idl=
e?

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 survey=
ed to find their maximum throughput in order to determine if it can safel=
y support a faster block rate. Specifically this is an attempt to prove o=
r 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 n=
odes 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 conne=
ctions (<30KB/s) timed out in order to run the test at a reasonable rate.=

>
>  * The connecting node was in Amsterdam with a 1GB NIC.=20
>
> =20
> 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://p=
astebin.com/raw.php?i=3D6b4NuiVQ
>
>
> This does not support the theory that the network has the available ban=
dwidth for increased block sizes, as in its current state 37% of nodes wo=
uld fail to upload a 20MB block to a single peer in under 20 seconds (ref=
erencing 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 on=
e peer, then 69% of the network fails for 20MB blocks. For comparison, on=
ly 10% fail this metric for 1MB blocks.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--0sxK7gNAVdqP3KVcXG3QwVU5sUjNt3so0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJVsRglAAoJEGuaHwy3wggS6qkIAJh7xucvjgcuXklCr0uUxXr9
WKJRYA3fVarsISVxTSSKFMQb7jg2XX1+j8NIEv2L2hcitajiHj0Nc5oJQEjNyMdh
FPHXlmTgTU69KqugtiYy/SHK1YYvJsBzD+/OI09G3ugoWLGEOh5iD96y8jrIoVwc
sQiWgvkm7fpy2oI/S8WOTinwf+I7qSkNTycQVZvWtaHBFm5BnAMeh7T8964hYRZt
0iZtLfFx5PTpBg/ALhqJN124KDEKijMa17ICRYqLGOp4xjH9UGXPn4H4zH2l82o9
oCcFas5REZYlg6mHjQvPG3x24ieMwn+nI2XcY7W7mYslXyULDAS7em1Ooz9PWBI=
=mg7R
-----END PGP SIGNATURE-----

--0sxK7gNAVdqP3KVcXG3QwVU5sUjNt3so0--