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
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
|
Return-Path: <jeanpaulkogelman@me.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1325CBC4
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 3 Jul 2015 04:19:21 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from st11p02im-asmtp002.me.com (st11p02im-asmtp002.me.com
[17.172.220.114])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F27BC10A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 3 Jul 2015 04:19:19 +0000 (UTC)
Received: from [10.0.1.7] (216-19-182-8.dyn.novuscom.net [216.19.182.8])
by st11p02im-asmtp002.me.com
(Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31
2015))
with ESMTPSA id <0NQW00G9A9C4B200@st11p02im-asmtp002.me.com> for
bitcoin-dev@lists.linuxfoundation.org;
Fri, 03 Jul 2015 04:19:18 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.14.151,1.0.33,0.0.0000
definitions=2015-07-03_02:2015-07-02, 2015-07-03,
1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
adjust=0
reason=mlx scancount=1 engine=7.0.1-1412110000
definitions=main-1507030078
MIME-version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-type: multipart/signed;
boundary="Apple-Mail=_D6ECB8B3-F762-4578-8422-0386D3B37078";
protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
In-reply-to: <CAJ+8mEM-MfRTTTK6-QnrvVtC63N5DZL6PiWSxsqTNm0KSYo=KQ@mail.gmail.com>
Date: Thu, 02 Jul 2015 21:19:45 -0700
Message-id: <8019E8A9-AADF-44FE-99BF-8E1CB740E4B7@me.com>
References: <F6C7E867-1CCA-4DFB-8A88-361316A76FC3@me.com>
<CABssiCq5JZdkQNmZ1x8OhNYqVxQOPXWe0Ui7wL7dCK9yQe9AoQ@mail.gmail.com>
<5595503D.2010608@phauna.org>
<CAJ+8mEM-MfRTTTK6-QnrvVtC63N5DZL6PiWSxsqTNm0KSYo=KQ@mail.gmail.com>
To: Jeremy Rubin <jeremy.l.rubin.travel@gmail.com>
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_MESSAGE,
MIME_QP_LONG_LINE,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD 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] Defining a min spec
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: Fri, 03 Jul 2015 04:19:21 -0000
--Apple-Mail=_D6ECB8B3-F762-4578-8422-0386D3B37078
Content-Type: multipart/alternative;
boundary="Apple-Mail=_25D98F34-B17F-4401-9CFA-4B2EBA2E26A2"
--Apple-Mail=_25D98F34-B17F-4401-9CFA-4B2EBA2E26A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
Ideally, the metrics that we settle on would be architecture agnostic =
and have some sort of conversion metric to map it onto any specific =
architecture. An Intel based architecture is going to perform vastly =
different from an ARM based one for example.
Simple example: The PS3 PPE and Xbox 360 CPU are RISC processors that =
run at 3.2GHz, but their non-vector performance is rather poor. You=E2=80=99=
d be lucky to get about 33% effective utilization out of them (up to =
50%, tops, but that=E2=80=99s really pushing it), so if you were to map =
this onto another architecture, you=E2=80=99d have at least a 3x =
conversion from this end alone (the other end could also have a scaling =
factor).
Ultimately, how these values are expressed isn=E2=80=99t the important =
part. It=E2=80=99s the ability to measure the impact of a change =
that=E2=80=99s important. If some metric changes by, say, 5%, then it =
doesn=E2=80=99t really matter if it=E2=80=99s expressed in MIPS, INTOPS, =
MB or GB. The fact that it changed is what matters and what the effect =
is on the baseline (that ultimately could be expressed as a certain =
specific hardware configuration). It would probably be practical to have =
a number of comparable concrete min spec configurations and even more =
ideal would be if people in the community would have these systems up =
and running to do actual on-target performance benchmarks.
jp
> On Jul 2, 2015, at 8:13 PM, Jeremy Rubin =
<jeremy.l.rubin.travel@gmail.com> wrote:
>=20
> Might I suggest that the min-spec, if developed, target the RISC-V =
Rocket architecture (running on FPGA, I suppose) as a reference point =
for performance? This may be much lower performance than desirable, =
however, it means that we don't lock people into using large-vendor =
chipsets which have unknown, or known to be bad, security properties =
such as Intel AMT.
>=20
> In general, targeting open hardware seems to me to be more critical =
than performance metrics for the long term health of Bitcoin, however, =
performance is still important.
>=20
> Does anyone know how the RISC-V FPGA performance stacks up to, say, a =
Raspberry Pi?
>=20
> On Thu, Jul 2, 2015 at 10:52 PM, Owen Gunden <ogunden@phauna.org =
<mailto:ogunden@phauna.org>> wrote:
> I'm also a user who runs a full node, and I also like this idea. I =
think Gavin has done some back-of-the-envelope calculations around this =
stuff, but nothing so clearly defined as what you propose.
>=20
> On 07/02/2015 08:33 AM, Mistr Bigs wrote:
> I'm an end user running a full node on an aging laptop.
> I think this is a great suggestion! I'd love to know what system
> requirements are needed for running Bitcoin Core.
>=20
> On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman
> <jeanpaulkogelman@me.com <mailto:jeanpaulkogelman@me.com> =
<mailto:jeanpaulkogelman@me.com <mailto:jeanpaulkogelman@me.com>>> =
wrote:
>=20
> I=E2=80=99m a game developer. I write time critical code for a =
living and
> have to deal with memory, CPU, GPU and I/O budgets on a daily =
basis.
> These budgets are based on what we call a minimum specification =
(of
> hardware); min spec for short. In most cases the min spec is based
> on entry model machines that are available during launch, and will
> give the user an enjoyable experience when playing our games.
> Obviously, we can turn on a number of bells and whistles for =
people
> with faster machines, but that=E2=80=99s not the point of this =
mail.
>=20
> The point is, can we define a min spec for Bitcoin Core? The =
number
> one reason for this is: if you know how your changes affect your
> available budgets, then the risk of breaking something due to
> capacity problems is reduced to practically zero.
>=20
>=20
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--Apple-Mail=_25D98F34-B17F-4401-9CFA-4B2EBA2E26A2
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
charset=utf-8
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">Ideally, the metrics that we settle on would be architecture =
agnostic and have some sort of conversion metric to map it onto any =
specific architecture. An Intel based architecture is going to perform =
vastly different from an ARM based one for example.<div class=3D""><br =
class=3D""></div><div class=3D"">Simple example: The PS3 PPE and Xbox =
360 CPU are RISC processors that run at 3.2GHz, but their non-vector =
performance is rather poor. You=E2=80=99d be lucky to get about 33% =
effective utilization out of them (up to 50%, tops, but that=E2=80=99s =
really pushing it), so if you were to map this onto another =
architecture, you=E2=80=99d have at least a 3x conversion from this end =
alone (the other end could also have a scaling factor). <div =
class=3D""><br class=3D""></div><div class=3D"">Ultimately, how these =
values are expressed isn=E2=80=99t the important part. It=E2=80=99s the =
ability to measure the impact of a change that=E2=80=99s important. If =
some metric changes by, say, 5%, then it doesn=E2=80=99t really matter =
if it=E2=80=99s expressed in MIPS, INTOPS, MB or GB. The fact that it =
changed is what matters and what the effect is on the baseline (that =
ultimately could be expressed as a certain specific hardware =
configuration). It would probably be practical to have a number of =
comparable concrete min spec configurations and even more ideal would be =
if people in the community would have these systems up and running to do =
actual on-target performance benchmarks.</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D"">jp</div><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On Jul 2, 2015, at 8:13 PM, Jeremy Rubin <<a =
href=3D"mailto:jeremy.l.rubin.travel@gmail.com" =
class=3D"">jeremy.l.rubin.travel@gmail.com</a>> wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><span style=3D"font-size:12.8000001907349px" class=3D"">Might =
I suggest that the </span><span class=3D"" =
style=3D"font-size:12.8000001907349px;background-color:rgb(255,255,255)">m=
in</span><span style=3D"font-size:12.8000001907349px" =
class=3D"">-</span><span class=3D"" =
style=3D"font-size:12.8000001907349px;background-color:rgb(255,255,255)">s=
pec</span><span style=3D"font-size:12.8000001907349px" class=3D"">, if =
developed, target the RISC-V Rocket architecture (running on FPGA, I =
suppose) as a reference point for performance? This may be much lower =
performance than desirable, however, it means that we don't lock people =
into using large-vendor chipsets which have unknown, or known to be bad, =
security properties such as Intel AMT.</span><div =
style=3D"font-size:12.8000001907349px" class=3D""><br =
class=3D""></div><div style=3D"font-size:12.8000001907349px" class=3D"">In=
general, targeting open hardware seems to me to be more critical than =
performance metrics for the long term health of Bitcoin, however, =
performance is still important.<div class=3D""><br class=3D""></div><div =
class=3D"">Does anyone know how the RISC-V FPGA performance stacks up =
to, say, a Raspberry Pi?</div></div></div><div class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Thu, Jul 2, 2015 at 10:52 PM, =
Owen Gunden <span dir=3D"ltr" class=3D""><<a =
href=3D"mailto:ogunden@phauna.org" target=3D"_blank" =
class=3D"">ogunden@phauna.org</a>></span> wrote:<br =
class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex">I'm also a user who =
runs a full node, and I also like this idea. I think Gavin has done some =
back-of-the-envelope calculations around this stuff, but nothing so =
clearly defined as what you propose.<span class=3D""><br class=3D"">
<br class=3D"">
On 07/02/2015 08:33 AM, Mistr Bigs wrote:<br class=3D"">
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
I'm an end user running a full node on an aging laptop.<br class=3D"">
I think this is a great suggestion! I'd love to know what system<br =
class=3D"">
requirements are needed for running Bitcoin Core.<br class=3D"">
<br class=3D"">
On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman<br =
class=3D""></span><span class=3D"">
<<a href=3D"mailto:jeanpaulkogelman@me.com" target=3D"_blank" =
class=3D"">jeanpaulkogelman@me.com</a> <mailto:<a =
href=3D"mailto:jeanpaulkogelman@me.com" target=3D"_blank" =
class=3D"">jeanpaulkogelman@me.com</a>>> wrote:<br class=3D"">
<br class=3D"">
I=E2=80=99m a game developer. I write time critical code =
for a living and<br class=3D"">
have to deal with memory, CPU, GPU and I/O budgets on a =
daily basis.<br class=3D"">
These budgets are based on what we call a minimum =
specification (of<br class=3D"">
hardware); min spec for short. In most cases the min spec =
is based<br class=3D"">
on entry model machines that are available during launch, =
and will<br class=3D"">
give the user an enjoyable experience when playing our =
games.<br class=3D"">
Obviously, we can turn on a number of bells and whistles =
for people<br class=3D"">
with faster machines, but that=E2=80=99s not the point of =
this mail.<br class=3D"">
<br class=3D"">
The point is, can we define a min spec for Bitcoin Core? =
The number<br class=3D"">
one reason for this is: if you know how your changes =
affect your<br class=3D"">
available budgets, then the risk of breaking something due =
to<br class=3D"">
capacity problems is reduced to practically zero.<br =
class=3D"">
<br class=3D"">
<br class=3D"">
<br class=3D""></span><span class=3D"">
_______________________________________________<br class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D"">
<br class=3D"">
</span></blockquote><div class=3D"HOEnZb"><div class=3D"h5">
_______________________________________________<br class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank"=
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D"">
</div></div></blockquote></div><br class=3D""></div>
_______________________________________________<br class=3D"">bitcoin-dev =
mailing list<br class=3D""><a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
br class=3D""></div></blockquote></div><br =
class=3D""></div></div></body></html>=
--Apple-Mail=_25D98F34-B17F-4401-9CFA-4B2EBA2E26A2--
--Apple-Mail=_D6ECB8B3-F762-4578-8422-0386D3B37078
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJVlg1iAAoJEG93Vo4Z7tpF2EgP+wavHU6BqliDJrB316dHFhto
zjM8hstRyPr2/RyFqyUDIztKC8zxI5ge1oYIduvcZ7qH1F0AdwKsDFRr6LQqTeuJ
uWAW2WPRdxPrgWiW6xwrFGW88Oy99L5N0qfLjrOhMPWPnNJISvmrJPXbWLq3mAjD
XqxPkFwZODVmVPz41tE2LVUP9NygdwMa74OZFAZFtQGgycalnSa+c/3GtX1siAD+
tCF0isgngPd+WW68E0HQ4N51VQQfDf53rbilXSgeZjfI5FwZx9oBU+Den0+zOzxe
lxm9X1rcyyMe6f+8Uta09k8QJyMmloN/TDUtLONsXA8hf2rDspFY9gqJ7sq7yHiF
asaiATR9dhKfROlBDyn7RZChTnzisZN7mCVxeTH7plWLQqJZeDxwZPvzsjnqzLGz
5UckI2cJWmMZDVLzpN9EpG2qwhr09t1poK0aA/eGdA0Who8oApGLRqmS6gK+QTHo
jaAgSgX0oKPe/ilgxAVg8D1oKdx0nWPLDYoeXgtqD+8Tfp9jzBdezRJmnotbTx+M
Jyi1DG5AkSHaJcWTrL9lRk+ULfivUqAwkHMU8eEq0cAFLDhND7rHtE2QTKKZ6dE+
atJl2MjwSqCE4y0C50804b0tH5j8mAT/fKaDEPQQbSwaDH/9Uh08jiBZveAG947r
9X1H5g+caDOV4jcbvTzX
=S/Rf
-----END PGP SIGNATURE-----
--Apple-Mail=_D6ECB8B3-F762-4578-8422-0386D3B37078--
|
