Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 31EB8B68 for ; Fri, 3 Jul 2015 06:18:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from st11p02im-asmtp001.me.com (st11p02im-asmtp001.me.com [17.172.220.113]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ED351F4 for ; Fri, 3 Jul 2015 06:18:06 +0000 (UTC) Received: from [10.0.1.7] (216-19-182-8.dyn.novuscom.net [216.19.182.8]) by st11p02im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0NQW016JLETV1V30@st11p02im-asmtp001.me.com> for bitcoin-dev@lists.linuxfoundation.org; Fri, 03 Jul 2015 06:17:58 +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-1507030115 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 X-Pgp-Agent: GPGMail 2.5 From: Jean-Paul Kogelman In-reply-to: Date: Thu, 02 Jul 2015 23:18:25 -0700 Message-id: <7D0D54F6-4CA4-427F-9296-E7C4C5AD7380@me.com> References: <5595503D.2010608@phauna.org> <8019E8A9-AADF-44FE-99BF-8E1CB740E4B7@me.com> To: Jeremy Rubin X-Mailer: Apple Mail (2.2098) X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,HTML_MESSAGE, MIME_QP_LONG_LINE,RCVD_IN_DNSWL_LOW,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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 06:18:08 -0000 --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 = 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 = > 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 = > 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 > 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 >> = >> = 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 = >> 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 = >>=20 >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org = >> 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
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:

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.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.

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). 

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:

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.

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 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.

    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<= /a>

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>

_______________________________________________
bitcoin-dev = mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>



= --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--