1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
Return-Path: <gavinandresen@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id BE0FD40A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 15:04:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f49.google.com (mail-la0-f49.google.com
[209.85.215.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C3C12112
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 15:04:41 +0000 (UTC)
Received: by lahe2 with SMTP id e2so96974414lah.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jul 2015 08:04:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=CYRhsUiJZSJE5ad/WgXX3LS43/mt1cmLgChJamQz1l8=;
b=ur32+9Mi7yPt+mEeyQsvypiSYOYxTixe3VKYsettsb26QeGj9fFh2skGonyMFwbEZZ
YBOjSBqo0ZcpKIjo5uZxLLLJwC+7jfnoi2qbhQ9q+CyGCfkUoHND8s5JL+Xq8X0QXhxi
PTBTd9yxBL6nK8N/72U5ZuvCqDRJxoQtiV5DedBiVElAhRzzxktufZq3T689cNTNcztd
wXa7iJi/5oVbV9jyUNx2tX1074sXgR37UixtjLanbtSRpqGwlCsxfwoGnrfNrzFIkmym
qeoabYe73Xn+/h2sooGGxCPtBIfYxcp7RYSarP3GNl0rCVZM1pNyiYzVz7SePlR7U7mq
duYg==
MIME-Version: 1.0
X-Received: by 10.152.19.67 with SMTP id c3mr8531070lae.4.1437663879966; Thu,
23 Jul 2015 08:04:39 -0700 (PDT)
Received: by 10.25.90.75 with HTTP; Thu, 23 Jul 2015 08:04:39 -0700 (PDT)
In-Reply-To: <trinity-c97bc41b-a953-4580-b2d2-ebdda9eb96b2-1437661199263@3capp-mailcom-bs02>
References: <trinity-c97bc41b-a953-4580-b2d2-ebdda9eb96b2-1437661199263@3capp-mailcom-bs02>
Date: Thu, 23 Jul 2015 11:04:39 -0400
Message-ID: <CABsx9T2VnMSQpwdh8FWcfhM8ETb-x6Es4WW1vLKVyQKtLcpe8A@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: slurms@gmx.us
Content-Type: multipart/alternative; boundary=089e0149420adf379b051b8c3432
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Bitcoin Node Speed Test
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2015 15:04:42 -0000
--089e0149420adf379b051b8c3432
Content-Type: text/plain; charset=UTF-8
Ahh, data... a breath of fresh air...
Can you re-analyze for 8MB blocks? There is no current proposal for 20MB
blocks.
Also, most hashing power is now using Matt Corallo's fast block propagation
network; slow 'block' propagation to merchants/end-users doesn't really
matter (as long as it doesn't get anywhere near the 10-minute block time).
On Thu, Jul 23, 2015 at 10:19 AM, slurms--- via bitcoin-dev <
bitcoin-dev@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
--
Gavin Andresen
--089e0149420adf379b051b8c3432
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ahh, data... a breath of fresh air...<div><br></div><div>C=
an you re-analyze for 8MB blocks?=C2=A0 There is no current proposal for 20=
MB blocks.</div><div><br></div><div>Also, most hashing power is now using M=
att Corallo's fast block propagation network; slow 'block' prop=
agation to merchants/end-users doesn't really matter (as long as it doe=
sn't get anywhere near the 10-minute block time).</div></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Jul 23, 2015 at 10:=
19 AM, slurms--- via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bi=
tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li=
nuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">O=
n this day, the Bitcoin network was crawled and reachable nodes surveyed to=
find their maximum throughput in order to determine if it can safely suppo=
rt a faster block rate. Specifically this is an attempt to prove or disprov=
e the common statement that 1MB blocks were only suitable slower internet c=
onnections in 2009 when Bitcoin launched, and that connection speeds have i=
mproved to the point of obviously supporting larger blocks.<br>
<br>
<br>
The testing methodology is as follows:<br>
<br>
=C2=A0* Nodes were randomly selected from a peers.dat, 5% of the reachable =
nodes in the network were contacted.<br>
<br>
=C2=A0* A random selection of blocks was downloaded from each peer.<br>
<br>
=C2=A0* There is some bias towards higher connection speeds, very slow conn=
ections (<30KB/s) timed out in order to run the test at a reasonable rat=
e.<br>
<br>
=C2=A0* The connecting node was in Amsterdam with a 1GB NIC.<br>
<br>
=C2=A0<br>
Results:<br>
<br>
=C2=A0* 37% of connected nodes failed to upload blocks faster than 1MB/s.<b=
r>
<br>
=C2=A0* 16% of connected nodes uploaded blocks faster than 10MB/s.<br>
<br>
=C2=A0* Raw data, one line per connected node, kilobytes per second <a href=
=3D"http://pastebin.com/raw.php?i=3D6b4NuiVQ" rel=3D"noreferrer" target=3D"=
_blank">http://pastebin.com/raw.php?i=3D6b4NuiVQ</a><br>
<br>
<br>
This does not support the theory that the network has the available bandwid=
th for increased block sizes, as in its current state 37% of nodes would fa=
il 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 th=
is metric for 1MB blocks.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class=
=3D"gmail_signature">--<br>Gavin Andresen<br></div>
</div>
--089e0149420adf379b051b8c3432--
|
