MIME-version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-type: multipart/signed;
	boundary="Apple-Mail=_FF6AB4C0-148B-4369-A092-6D52C559A4F3";
	protocol="application/pgp-signature"; micalg=pgp-sha512
From: Jean-Paul Kogelman <jeanpaulkogelman@me.com>
In-reply-to: <CAJ+8mEOrO3ZvKCiTsX7VzF5Lwug+QE7x+k2EP1nQeqzSuK7AtA@mail.gmail.com>
Date: Thu, 02 Jul 2015 23:18:25 -0700
Message-id: <7D0D54F6-4CA4-427F-9296-E7C4C5AD7380@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>
	<CAJ+8mEOrO3ZvKCiTsX7VzF5Lwug+QE7x+k2EP1nQeqzSuK7AtA@mail.gmail.com>
To: Jeremy Rubin <jeremy.l.rubin.travel@gmail.com>
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Defining a min spec
Precedence: list


--Apple-Mail=_FF6AB4C0-148B-4369-A092-6D52C559A4F3
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_C650B0F2-5B95-4F03-88FA-FC650A43C914"


--Apple-Mail=_C650B0F2-5B95-4F03-88FA-FC650A43C914
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I get it. :) Being able to run Bitcoin Core on open hardware is a noble =
(and important) goal! I hope that once we=E2=80=99ve figured out what =
the current requirements are that we can adjust these requirements (if =
needed) to include certain open hardware platforms. But that=E2=80=99s =
the next step. Bitcoin Core is a project in flight. Let=E2=80=99s first =
see where we=E2=80=99re at.

What are the critical wall-time requirements? As discussed earlier, the =
block propagation times are very important to keep orphan rates low. =
This sounds like one of the inputs that can be used to model bandwidth =
and CPU requirements. Other inputs for this could be as simple as the =
minimum number of connected nodes (multiplier on outbound bandwidth, but =
not CPU), etc. It wouldn=E2=80=99t surprise me if many of the real world =
requirements will center around Bitcoin Core=E2=80=99s ability to talk =
to the outside world.

jp


> On Jul 2, 2015, at 10:33 PM, Jeremy Rubin =
<jeremy.l.rubin.travel@gmail.com> wrote:
>=20
> Jean-Paul,
>=20
> 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.
>=20
> 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.
>=20
> Jeff,
>=20
> 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?
>=20
> 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.
>=20
> On Fri, Jul 3, 2015 at 12:19 PM, Jean-Paul Kogelman =
<jeanpaulkogelman@me.com <mailto:jeanpaulkogelman@me.com>> 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.
>=20
> 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).
>=20
> 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.
>=20
>=20
> jp
>=20
>=20
>> On Jul 2, 2015, at 8:13 PM, Jeremy Rubin =
<jeremy.l.rubin.travel@gmail.com =
<mailto: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 =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>=20
>=20


--Apple-Mail=_C650B0F2-5B95-4F03-88FA-FC650A43C914
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""><div class=3D"">I get it. :) Being able to run Bitcoin Core =
on open hardware is a noble (and important) goal! I hope that once =
we=E2=80=99ve figured out what the <i class=3D"">current</i> =
requirements are that we can adjust these requirements (if needed) to =
include certain open hardware platforms. But that=E2=80=99s the next =
step. Bitcoin Core is a project in flight. Let=E2=80=99s first see where =
we=E2=80=99re at.&nbsp;</div><div class=3D""><br class=3D""></div><div =
class=3D"">What are the critical wall-time requirements? As discussed =
earlier, the block propagation times are very important to keep orphan =
rates low. This sounds like one of the inputs that can be used to model =
bandwidth and CPU requirements. Other inputs for this could be as simple =
as the minimum number of connected nodes (multiplier on outbound =
bandwidth, but not CPU), etc. It wouldn=E2=80=99t surprise me if many of =
the real world requirements will center around Bitcoin Core=E2=80=99s =
ability to talk to the outside world.&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D"">jp</div><div class=3D""><br =
class=3D""></div><br class=3D""><div><blockquote type=3D"cite" =
class=3D""><div class=3D"">On Jul 2, 2015, at 10:33 PM, Jeremy Rubin =
&lt;<a href=3D"mailto:jeremy.l.rubin.travel@gmail.com" =
class=3D"">jeremy.l.rubin.travel@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">Jean-Paul,<div class=3D""><br class=3D""></div><div =
class=3D"">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.</div><div class=3D""><br class=3D""></div><div =
class=3D"">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.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Jeff,</div><div =
class=3D""><br class=3D""></div><div class=3D"">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?</div><div class=3D""><br class=3D""></div><div =
class=3D"">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.&nbsp;</div></div><div class=3D"gmail_extra"><br =
class=3D""><div class=3D"gmail_quote">On Fri, Jul 3, 2015 at 12:19 PM, =
Jean-Paul Kogelman <span dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:jeanpaulkogelman@me.com" target=3D"_blank" =
class=3D"">jeanpaulkogelman@me.com</a>&gt;</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"><div =
style=3D"word-wrap:break-word" 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).&nbsp;<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><span class=3D"HOEnZb"><font =
color=3D"#888888" class=3D""><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""></div><div class=3D"">jp</div></font></span><div=
 class=3D""><div class=3D"h5"><div class=3D""><br class=3D""></div><div =
class=3D""><br class=3D""><div class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D"">On Jul 2, 2015, at 8:13 PM, Jeremy Rubin =
&lt;<a href=3D"mailto:jeremy.l.rubin.travel@gmail.com" target=3D"_blank" =
class=3D"">jeremy.l.rubin.travel@gmail.com</a>&gt; wrote:</div><br =
class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><span =
style=3D"font-size:12.8000001907349px" class=3D"">Might I suggest that =
the&nbsp;</span><span =
style=3D"font-size:12.8000001907349px;background-color:rgb(255,255,255)" =
class=3D"">min</span><span style=3D"font-size:12.8000001907349px" =
class=3D"">-</span><span =
style=3D"font-size:12.8000001907349px;background-color:rgb(255,255,255)" =
class=3D"">spec</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"">&lt;<a =
href=3D"mailto:ogunden@phauna.org" target=3D"_blank" =
class=3D"">ogunden@phauna.org</a>&gt;</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"">
&lt;<a href=3D"mailto:jeanpaulkogelman@me.com" target=3D"_blank" =
class=3D"">jeanpaulkogelman@me.com</a> &lt;mailto:<a =
href=3D"mailto:jeanpaulkogelman@me.com" target=3D"_blank" =
class=3D"">jeanpaulkogelman@me.com</a>&gt;&gt; wrote:<br class=3D"">
<br class=3D"">
&nbsp; &nbsp; I=E2=80=99m a game developer. I write time critical code =
for a living and<br class=3D"">
&nbsp; &nbsp; have to deal with memory, CPU, GPU and I/O budgets on a =
daily basis.<br class=3D"">
&nbsp; &nbsp; These budgets are based on what we call a minimum =
specification (of<br class=3D"">
&nbsp; &nbsp; hardware); min spec for short. In most cases the min spec =
is based<br class=3D"">
&nbsp; &nbsp; on entry model machines that are available during launch, =
and will<br class=3D"">
&nbsp; &nbsp; give the user an enjoyable experience when playing our =
games.<br class=3D"">
&nbsp; &nbsp; Obviously, we can turn on a number of bells and whistles =
for people<br class=3D"">
&nbsp; &nbsp; with faster machines, but that=E2=80=99s not the point of =
this mail.<br class=3D"">
<br class=3D"">
&nbsp; &nbsp; The point is, can we define a min spec for Bitcoin Core? =
The number<br class=3D"">
&nbsp; &nbsp; one reason for this is: if you know how your changes =
affect your<br class=3D"">
&nbsp; &nbsp; available budgets, then the risk of breaking something due =
to<br class=3D"">
&nbsp; &nbsp; 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""><div 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"">
</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" 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" =
target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D""></div></blockquote></div><br =
class=3D""></div></div></div></div></div></blockquote></div><br =
class=3D""></div>
</div></blockquote></div><br class=3D""></body></html>=

--Apple-Mail=_C650B0F2-5B95-4F03-88FA-FC650A43C914--

--Apple-Mail=_FF6AB4C0-148B-4369-A092-6D52C559A4F3
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

iQIcBAEBCgAGBQJVlikxAAoJEG93Vo4Z7tpFd2AQAIYdBh16AFs6w7u2fZoYFlpH
xisRnRRGHuCy+0AUv7VnfczaE5rhmajhT2RiWVLjqHtRGWCwYFYdyNn+4m2Aw+b9
/ThZ60HTpOGcPtjBr/e+fGQ9wJdTNOCtrtJ1BjJLP7VQNZifGoHJK4LozQgWf1wn
2pjcQE/Oyv1T+fYggAVthKgaX8JwNIx6yDy+XSf9UHwqoOsuhQ1cUxS9tUe+9AoH
iiR2CScgRytRcqnl59E46jL/eDoJegSadxpKYgI/d+1cBtRWQw6l6BmAjogPDdqg
5DaH9Ykk5ke6YHJWaBKyURC9GBz/RZDoiKsuqbWunzowNWWinnXSNgN2PuEl3utq
q/B1PNz5SBPwzs7R7jXgjRUcqqZGIGUXFToeW0axNsLa3n+FKuXchmcoNCsbfFSv
giWZ2e5G+3Ikj2ljy7o//Pi56svi2GFKx54OHlGkQD8utZwAGgfkYsHfddfdzoeM
DaSuFWroN+qzTy3YjZOGpb83DaKiCcgnSK7zkUcwpmfSdptaQXi9BL4cewR5i9CC
yIWJZ2w/G/oy8BqbDMZmYXdXMdEcgiirc9gq53J++SSpkg7Teh8s0txrD2Sd0tdu
NSSuz4fSxeLzMAUlixlyhmSdUJITGj3jUGMTCUXNA7qSPmlSRiAcFDQtVHvSjlLq
46Ud4SNsous9VU8k54ca
=k96z
-----END PGP SIGNATURE-----

--Apple-Mail=_FF6AB4C0-148B-4369-A092-6D52C559A4F3--