Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1325CBC4 for ; 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 ; 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 In-reply-to: Date: Thu, 02 Jul 2015 21:19:45 -0700 Message-id: <8019E8A9-AADF-44FE-99BF-8E1CB740E4B7@me.com> References: <5595503D.2010608@phauna.org> To: Jeremy Rubin 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 --Apple-Mail=_25D98F34-B17F-4401-9CFA-4B2EBA2E26A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; 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=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 m= in-s= pec, 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<= br class=3D"">

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