path: root/8a/c7a2739010637b905c990cfe9f3dd345f63388

Return-Path: <jeremy.l.rubin.travel@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 870EFBA2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  3 Jul 2015 05:33:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0D68A19D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  3 Jul 2015 05:33:25 +0000 (UTC)
Received: by wgqq4 with SMTP id q4so79195002wgq.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 02 Jul 2015 22:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=n/EHBEw8tOopkqK1COzT55k6g8scEuYmg5C1ZQ2CYcg=;
	b=YkOYJ2dBOsA+lz9C1QC6PQLcWE3ahG+X19w4w4P1CGVypGkM/uPRAxAOf2w4RV8HST
	W9qmsq/LwdKDpvyWex6ZjBPjKivlhxdPMdRvLJMUAza4eP8X6LnIu7i2kv6PIamYlZgx
	H6XpGGbjo2rr9clTD0IBr5iufmXFNbkoHk3cEyOd20LlsdUvm/tDevKyQXVna0MSdCR2
	aDa4VKLiQpf0vZa2maV7piAYzgWZvohHGLJlqnaubjuKWJRQSw8AmjLNHkDXxHL072e1
	VRX6yTInlCiBVlGqA9A91vBaTsRZxJSlmmyhGrhvTHvde/MB8z1EWFXNgVWiJt8rE6in
	rC+Q==
X-Received: by 10.194.77.144 with SMTP id s16mr18194005wjw.145.1435901603626; 
	Thu, 02 Jul 2015 22:33:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.229.195 with HTTP; Thu, 2 Jul 2015 22:33:03 -0700 (PDT)
In-Reply-To: <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>
	<8019E8A9-AADF-44FE-99BF-8E1CB740E4B7@me.com>
From: Jeremy Rubin <jeremy.l.rubin.travel@gmail.com>
Date: Fri, 3 Jul 2015 13:33:03 +0800
Message-ID: <CAJ+8mEOrO3ZvKCiTsX7VzF5Lwug+QE7x+k2EP1nQeqzSuK7AtA@mail.gmail.com>
To: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
Content-Type: multipart/alternative; boundary=047d7bd9147a0447b70519f1e5c0
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] 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 05:33:26 -0000

--047d7bd9147a0447b70519f1e5c0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Jean-Paul,

I think you're missing what I'm saying -- the point of my suggestion to
make Rocket a min-spec is more along the lines of saying that the Rocket
serves as a fixed point, Bitcoin Core performance must be acceptable on
that platform, however it can be lower. Yes there are conversion factors
and different architectures will perform differently. However, there still
must be some baseline, a point at which we can say processors below it no
longer are supported. I am saying that line should never be set so high as
to exclude presently available open hardware.

Ultimately, this ends up making an odd, but nice, goal for Bitcoin
development. If Bitcoin Core needs more MIPS, the community must ensure the
availability of open hardware that it can run on.

Jeff,

Moxie looks fantastic! The reason I thought RISC-V was a good selection is
the very active development community which is pushing the performance of
the ISA implementations forward. Can you speak to the health of Moxie
development? Ultimately, ensuring support for many open architectures would
be preferable. Are there other reasonable open-source processors that you
are aware of?

I would be willing to work on a design a Bitcoin specific open-hardware
processor, up to the FPGA bound, if this would be useful for this goal.

On Fri, Jul 3, 2015 at 12:19 PM, Jean-Paul Kogelman <jeanpaulkogelman@me.co=
m
> wrote:

> 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=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 anothe=
r
> architecture, you=E2=80=99d have at least a 3x conversion from this end a=
lone (the
> other end could also have a scaling factor).
>
> Ultimately, how these values are expressed isn=E2=80=99t the important pa=
rt. It=E2=80=99s
> the ability to measure the impact of a change that=E2=80=99s important. I=
f 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 mor=
e
> 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:
>
> 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 ha=
ve
> unknown, or known to be bad, security properties such as Intel AMT.
>
> 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.
>
> Does anyone know how the RISC-V FPGA performance stacks up to, say, a
> Raspberry Pi?
>
> On Thu, Jul 2, 2015 at 10:52 PM, Owen Gunden <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.
>>
>> 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.
>>>
>>> On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman
>>> <jeanpaulkogelman@me.com <mailto:jeanpaulkogelman@me.com>> wrote:
>>>
>>>     I=E2=80=99m a game developer. I write time critical code for a livi=
ng 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=
.
>>>
>>>     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.
>>>
>>>
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>  _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

--047d7bd9147a0447b70519f1e5c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Jean-Paul,<div><br></div><div>I think you&#39;re missing w=
hat I&#39;m saying -- the point of my suggestion to make Rocket a min-spec =
is more along the lines of saying that the Rocket serves as a fixed point, =
Bitcoin Core performance must be acceptable on that platform, however it ca=
n be lower. Yes there are conversion factors and different architectures wi=
ll perform differently. However, there still must be some baseline, a point=
 at which we can say processors below it no longer are supported. I am sayi=
ng that line should never be set so high as to exclude presently available =
open hardware.</div><div><br></div><div>Ultimately, this ends up making an =
odd, but nice, goal for Bitcoin development. If Bitcoin Core needs more MIP=
S, the community must ensure the availability of open hardware that it can =
run on.</div><div><br></div><div>Jeff,</div><div><br></div><div>Moxie looks=
 fantastic! The reason I thought RISC-V was a good selection is the very ac=
tive development community which is pushing the performance of the ISA impl=
ementations forward. Can you speak to the health of Moxie development? Ulti=
mately, ensuring support for many open architectures would be preferable. A=
re there other reasonable open-source processors that you are aware of?</di=
v><div><br></div><div>I would be willing to work on a design a Bitcoin spec=
ific open-hardware processor, up to the FPGA bound, if this would be useful=
 for this goal.=C2=A0</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Fri, Jul 3, 2015 at 12:19 PM, Jean-Paul Kogelman <span =
dir=3D"ltr">&lt;<a href=3D"mailto:jeanpaulkogelman@me.com" target=3D"_blank=
">jeanpaulkogelman@me.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div style=3D"word-wrap:break-word">Ideally, the metrics that we set=
tle on would be architecture agnostic and have some sort of conversion metr=
ic 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><=
br></div><div>Simple example: The PS3 PPE and Xbox 360 CPU are RISC process=
ors that run at 3.2GHz, but their non-vector performance is rather poor. Yo=
u=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 conversio=
n from this end alone (the other end could also have a scaling factor).=C2=
=A0<div><br></div><div>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 i=
f people in the community would have these systems up and running to do act=
ual on-target performance benchmarks.</div><span class=3D"HOEnZb"><font col=
or=3D"#888888"><div><br></div><div><br></div><div>jp</div></font></span><di=
v><div class=3D"h5"><div><br></div><div><br><div><blockquote type=3D"cite">=
<div>On Jul 2, 2015, at 8:13 PM, Jeremy Rubin &lt;<a href=3D"mailto:jeremy.=
l.rubin.travel@gmail.com" target=3D"_blank">jeremy.l.rubin.travel@gmail.com=
</a>&gt; wrote:</div><br><div><div dir=3D"ltr"><span style=3D"font-size:12.=
8000001907349px">Might I suggest that the=C2=A0</span><span style=3D"font-s=
ize:12.8000001907349px;background-color:rgb(255,255,255)">min</span><span s=
tyle=3D"font-size:12.8000001907349px">-</span><span style=3D"font-size:12.8=
000001907349px;background-color:rgb(255,255,255)">spec</span><span style=3D=
"font-size:12.8000001907349px">, if developed, target the RISC-V Rocket arc=
hitecture (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&#39;t lock people into using large-vendor chipsets which have unkno=
wn, or known to be bad, security properties such as Intel AMT.</span><div s=
tyle=3D"font-size:12.8000001907349px"><br></div><div style=3D"font-size:12.=
8000001907349px">In general, targeting open hardware seems to me to be more=
 critical than performance metrics for the long term health of Bitcoin, how=
ever, performance is still important.<div><br></div><div>Does anyone know h=
ow the RISC-V FPGA performance stacks up to, say, a Raspberry Pi?</div></di=
v></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, J=
ul 2, 2015 at 10:52 PM, Owen Gunden <span dir=3D"ltr">&lt;<a href=3D"mailto=
:ogunden@phauna.org" target=3D"_blank">ogunden@phauna.org</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">I&#39;m also a user who runs a full =
node, and I also like this idea. I think Gavin has done some back-of-the-en=
velope calculations around this stuff, but nothing so clearly defined as wh=
at you propose.<span><br>
<br>
On 07/02/2015 08:33 AM, Mistr Bigs wrote:<br>
</span><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><span>
I&#39;m an end user running a full node on an aging laptop.<br>
I think this is a great suggestion! I&#39;d love to know what system<br>
requirements are needed for running Bitcoin Core.<br>
<br>
On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman<br></span><span>
&lt;<a href=3D"mailto:jeanpaulkogelman@me.com" target=3D"_blank">jeanpaulko=
gelman@me.com</a> &lt;mailto:<a href=3D"mailto:jeanpaulkogelman@me.com" tar=
get=3D"_blank">jeanpaulkogelman@me.com</a>&gt;&gt; wrote:<br>
<br>
=C2=A0 =C2=A0 I=E2=80=99m a game developer. I write time critical code for =
a living and<br>
=C2=A0 =C2=A0 have to deal with memory, CPU, GPU and I/O budgets on a daily=
 basis.<br>
=C2=A0 =C2=A0 These budgets are based on what we call a minimum specificati=
on (of<br>
=C2=A0 =C2=A0 hardware); min spec for short. In most cases the min spec is =
based<br>
=C2=A0 =C2=A0 on entry model machines that are available during launch, and=
 will<br>
=C2=A0 =C2=A0 give the user an enjoyable experience when playing our games.=
<br>
=C2=A0 =C2=A0 Obviously, we can turn on a number of bells and whistles for =
people<br>
=C2=A0 =C2=A0 with faster machines, but that=E2=80=99s not the point of thi=
s mail.<br>
<br>
=C2=A0 =C2=A0 The point is, can we define a min spec for Bitcoin Core? The =
number<br>
=C2=A0 =C2=A0 one reason for this is: if you know how your changes affect y=
our<br>
=C2=A0 =C2=A0 available budgets, then the risk of breaking something due to=
<br>
=C2=A0 =C2=A0 capacity problems is reduced to practically zero.<br>
<br>
<br>
<br></span><span>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
<br>
</span></blockquote><div><div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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>
</div></div></blockquote></div><br></div>
_______________________________________________<br>bitcoin-dev mailing list=
<br><a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a><br><a href=3D"https://lists.l=
inuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank">https://=
lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br></div></block=
quote></div><br></div></div></div></div></div></blockquote></div><br></div>

--047d7bd9147a0447b70519f1e5c0--