* [bitcoin-dev] Defining a min spec
@ 2015-07-02 4:04 Jean-Paul Kogelman
2015-07-02 7:18 ` Henning Kopp
2015-07-02 12:33 ` Mistr Bigs
0 siblings, 2 replies; 11+ messages in thread
From: Jean-Paul Kogelman @ 2015-07-02 4:04 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]
Hi folks,
I’m 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’s 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.
One way of doing so is to work backwards from what we have right now: Block size (network / disk I/O), SigOps/block (CPU), UTXO size (memory), etc. Then there’s Pieter’s analysis of network bottlenecks and how it affects orphan rates that could be used to set some form of cap on what transfer time + verification time should be to keep the orphan rate at an acceptable level.
So taking all of the above (and more) into account, what configuration would be the bare minimum to comfortably run Bitcoin Core at maximum load and can it be reasonably expected to still be out there in the field running Bitcoin Core? Also, can the parameters that were used to determine this min spec be codified in some way so that they can later be used if Bitcoin Core is optimized (or extended with new functionality) and see how it affects the min spec? Basically, with any reasonably big change, one of the first questions could be: “How does this change affect min spec?"
For example, currently OpenSSL is used to verify the signatures in the transactions. The new secp256k1 implementation is several times faster than (depending on CPU architecture, I’m sure) OpenSSL’s implementation. So it would result in faster verification time. This can then result in the following things; either network I/O and CPU requirements are adjusted downward in the min spec (you can run the new Bitcoin Core on a cheaper configuration), or other parameters can be adjusted upwards (number of SigOps / transaction, block size?), through proper rollout obviously. Since we know how min spec is affected by these changes, they should be non-controversial by default. Nobody running min spec is going to be affected by it, etc.
Every change that has a positive effect on min spec (do more on the same hardware) basically pushes the need to start following any of the curve laws (Nielsen, Moore) forward. No need for miners / node operators to upgrade.
Once we hit what we call SOL (Speed Of Light, the fastest something can go on a specific platform) it’s time to start looking at periodically adjusting min spec upwards, or by that time maybe it’s possible to use conservative plots of the curve laws as a basis.
Lastly, a benchmark test could be developed that can tell everyone running Bitcoin Core how their setup compares to the min spec and how long they can expect to run on this setup.
What do you guys think?
jp
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Defining a min spec
2015-07-02 4:04 [bitcoin-dev] Defining a min spec Jean-Paul Kogelman
@ 2015-07-02 7:18 ` Henning Kopp
2015-07-02 8:33 ` Jean-Paul Kogelman
2015-07-02 12:33 ` Mistr Bigs
1 sibling, 1 reply; 11+ messages in thread
From: Henning Kopp @ 2015-07-02 7:18 UTC (permalink / raw)
To: Jean-Paul Kogelman; +Cc: bitcoin-dev
Hi Jean-Paul,
that's a very interesting point of view and I have never thought about
it this way, since I have a totally different background.
How would you go on about defining a min spec? Is this done by testing
the software on different hardware configurations or are you looking
at the requirements a priori?
Best regards
Henning
On Wed, Jul 01, 2015 at 09:04:19PM -0700, Jean-Paul Kogelman wrote:
> Hi folks,
>
> I’m 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’s 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.
>
> One way of doing so is to work backwards from what we have right now: Block size (network / disk I/O), SigOps/block (CPU), UTXO size (memory), etc. Then there’s Pieter’s analysis of network bottlenecks and how it affects orphan rates that could be used to set some form of cap on what transfer time + verification time should be to keep the orphan rate at an acceptable level.
>
> So taking all of the above (and more) into account, what configuration would be the bare minimum to comfortably run Bitcoin Core at maximum load and can it be reasonably expected to still be out there in the field running Bitcoin Core? Also, can the parameters that were used to determine this min spec be codified in some way so that they can later be used if Bitcoin Core is optimized (or extended with new functionality) and see how it affects the min spec? Basically, with any reasonably big change, one of the first questions could be: “How does this change affect min spec?"
>
> For example, currently OpenSSL is used to verify the signatures in the transactions. The new secp256k1 implementation is several times faster than (depending on CPU architecture, I’m sure) OpenSSL’s implementation. So it would result in faster verification time. This can then result in the following things; either network I/O and CPU requirements are adjusted downward in the min spec (you can run the new Bitcoin Core on a cheaper configuration), or other parameters can be adjusted upwards (number of SigOps / transaction, block size?), through proper rollout obviously. Since we know how min spec is affected by these changes, they should be non-controversial by default. Nobody running min spec is going to be affected by it, etc.
>
> Every change that has a positive effect on min spec (do more on the same hardware) basically pushes the need to start following any of the curve laws (Nielsen, Moore) forward. No need for miners / node operators to upgrade.
>
> Once we hit what we call SOL (Speed Of Light, the fastest something can go on a specific platform) it’s time to start looking at periodically adjusting min spec upwards, or by that time maybe it’s possible to use conservative plots of the curve laws as a basis.
>
> Lastly, a benchmark test could be developed that can tell everyone running Bitcoin Core how their setup compares to the min spec and how long they can expect to run on this setup.
>
> What do you guys think?
>
>
> jp
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
Henning Kopp
Institute of Distributed Systems
Ulm University, Germany
Office: O27 - 3402
Phone: +49 731 50-24138
Web: http://www.uni-ulm.de/in/vs/~kopp
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Defining a min spec
2015-07-02 7:18 ` Henning Kopp
@ 2015-07-02 8:33 ` Jean-Paul Kogelman
0 siblings, 0 replies; 11+ messages in thread
From: Jean-Paul Kogelman @ 2015-07-02 8:33 UTC (permalink / raw)
To: Henning Kopp; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 6906 bytes --]
In the case of Bitcoin Core, for a starting point, you basically have to work backwards from what we have right now. We know some of the bounds already. Block size already tells you a lot about your bandwidth requirements, and Pieter’s simulations gives you even more information when you take orphan rates into account. There’s also a hard cap on the number of SigOps if I recall correctly, so that’s probably a good starting point for a MIPS metric, etc.
Memory is probably the hardest to pin down since some memory structures like (from what I understand, correct me if I’m wrong) the UTXO database live fully in memory and are basically unbounded. Perhaps this can somehow be capped at a certain size and move all the really old UTXO’s that are unlikely to move to disk and just take the CPU / disk hit in the unlikely event that they are referenced by a new block. Has the address database been capped yet? Mempool? I realize that it’s probably debatable whether or not this behaviour should be independent of available memory since any bugs here could affect consensus (especially the UTXO db).
Ultimately, what comes out of it is a list of numbers. A Mbit network I/O, B MIPS, C MB memory, D Disk space, etc. At that point you can debate whether or not such a machine can be considered an entrypoint bitcoin full node. You round up the numbers that are not really available anymore in off the shelf hardware (like disk space) and you round down the numbers that seem too high. For all we know we’re already over budget on some of the metrics that we decide to track as min spec. Network I/O for example. At that point you can start focussed research into bringing Bitcoin Core back into budget on those metrics. Then the discussion moves from “it’s probably too high” to “we’re X% over budget”.
The most valuable thing that could come out of this is to get some kind of formulation how all the different levers in Bitcoin Core affect the min spec and ideally have a benchmark tool. For example, we could settle on a min spec that would exclude the Raspberry Pi 1 on MIPS, but when secp256k1 is enabled for validation, the MIPS requirement could drop significantly, allowing us to adjust the min spec downward to include the Raspberry Pi 1 again (again, just an example).
Ideally some people would have the actual min spec machine built and running. The cost of that shouldn’t be too high (it’s the min spec after all) and I’m sure people would be happy to chip in a couple bits for this.
Remember, the min spec should be able to handle Bitcoin Core running under full load; that’s maxed out blocks with maxed out SigOps, etc.
jp
> On Jul 2, 2015, at 12:18 AM, Henning Kopp <henning.kopp@uni-ulm•de> wrote:
>
> Hi Jean-Paul,
>
> that's a very interesting point of view and I have never thought about
> it this way, since I have a totally different background.
>
> How would you go on about defining a min spec? Is this done by testing
> the software on different hardware configurations or are you looking
> at the requirements a priori?
>
> Best regards
> Henning
>
>
> On Wed, Jul 01, 2015 at 09:04:19PM -0700, Jean-Paul Kogelman wrote:
>> Hi folks,
>>
>> I’m 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’s 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.
>>
>> One way of doing so is to work backwards from what we have right now: Block size (network / disk I/O), SigOps/block (CPU), UTXO size (memory), etc. Then there’s Pieter’s analysis of network bottlenecks and how it affects orphan rates that could be used to set some form of cap on what transfer time + verification time should be to keep the orphan rate at an acceptable level.
>>
>> So taking all of the above (and more) into account, what configuration would be the bare minimum to comfortably run Bitcoin Core at maximum load and can it be reasonably expected to still be out there in the field running Bitcoin Core? Also, can the parameters that were used to determine this min spec be codified in some way so that they can later be used if Bitcoin Core is optimized (or extended with new functionality) and see how it affects the min spec? Basically, with any reasonably big change, one of the first questions could be: “How does this change affect min spec?"
>>
>> For example, currently OpenSSL is used to verify the signatures in the transactions. The new secp256k1 implementation is several times faster than (depending on CPU architecture, I’m sure) OpenSSL’s implementation. So it would result in faster verification time. This can then result in the following things; either network I/O and CPU requirements are adjusted downward in the min spec (you can run the new Bitcoin Core on a cheaper configuration), or other parameters can be adjusted upwards (number of SigOps / transaction, block size?), through proper rollout obviously. Since we know how min spec is affected by these changes, they should be non-controversial by default. Nobody running min spec is going to be affected by it, etc.
>>
>> Every change that has a positive effect on min spec (do more on the same hardware) basically pushes the need to start following any of the curve laws (Nielsen, Moore) forward. No need for miners / node operators to upgrade.
>>
>> Once we hit what we call SOL (Speed Of Light, the fastest something can go on a specific platform) it’s time to start looking at periodically adjusting min spec upwards, or by that time maybe it’s possible to use conservative plots of the curve laws as a basis.
>>
>> Lastly, a benchmark test could be developed that can tell everyone running Bitcoin Core how their setup compares to the min spec and how long they can expect to run on this setup.
>>
>> What do you guys think?
>>
>>
>> jp
>
>
>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> --
> Henning Kopp
> Institute of Distributed Systems
> Ulm University, Germany
>
> Office: O27 - 3402
> Phone: +49 731 50-24138
> Web: http://www.uni-ulm.de/in/vs/~kopp
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Defining a min spec
2015-07-02 4:04 [bitcoin-dev] Defining a min spec Jean-Paul Kogelman
2015-07-02 7:18 ` Henning Kopp
@ 2015-07-02 12:33 ` Mistr Bigs
2015-07-02 14:52 ` Owen Gunden
1 sibling, 1 reply; 11+ messages in thread
From: Mistr Bigs @ 2015-07-02 12:33 UTC (permalink / raw)
Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1086 bytes --]
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>
wrote:
> I’m 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’s 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.
>
>
[-- Attachment #2: Type: text/html, Size: 1376 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Defining a min spec
2015-07-02 12:33 ` Mistr Bigs
@ 2015-07-02 14:52 ` Owen Gunden
2015-07-03 3:13 ` Jeremy Rubin
0 siblings, 1 reply; 11+ messages in thread
From: Owen Gunden @ 2015-07-02 14:52 UTC (permalink / raw)
To: bitcoin-dev
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’m 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’s 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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Defining a min spec
2015-07-02 14:52 ` Owen Gunden
@ 2015-07-03 3:13 ` Jeremy Rubin
2015-07-03 3:25 ` Jeff Garzik
2015-07-03 4:19 ` Jean-Paul Kogelman
0 siblings, 2 replies; 11+ messages in thread
From: Jeremy Rubin @ 2015-07-03 3:13 UTC (permalink / raw)
To: Owen Gunden; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2556 bytes --]
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’m 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’s 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
>
[-- Attachment #2: Type: text/html, Size: 4128 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Defining a min spec
2015-07-03 3:13 ` Jeremy Rubin
@ 2015-07-03 3:25 ` Jeff Garzik
2015-07-03 4:19 ` Jean-Paul Kogelman
1 sibling, 0 replies; 11+ messages in thread
From: Jeff Garzik @ 2015-07-03 3:25 UTC (permalink / raw)
To: Jeremy Rubin; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3245 bytes --]
If the freedom to pick architecture exists, Moxie is a nice, compact, easy
to audit alternative:
http://moxielogic.org/blog/pages/architecture.html
https://github.com/jgarzik/moxiebox
Scaling can occur at the core level, rather than hyper-pipelining, keeping
the architecture itself nice and clean and simple.
On Thu, Jul 2, 2015 at 11: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’m 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’s 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
>
>
[-- Attachment #2: Type: text/html, Size: 5378 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Defining a min spec
2015-07-03 3:13 ` Jeremy Rubin
2015-07-03 3:25 ` Jeff Garzik
@ 2015-07-03 4:19 ` Jean-Paul Kogelman
2015-07-03 5:33 ` Jeremy Rubin
1 sibling, 1 reply; 11+ messages in thread
From: Jean-Paul Kogelman @ 2015-07-03 4:19 UTC (permalink / raw)
To: Jeremy Rubin; +Cc: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 4472 bytes --]
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’d be lucky to get about 33% effective utilization out of them (up to 50%, tops, but that’s really pushing it), so if you were to map this onto another architecture, you’d 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’t the important part. It’s the ability to measure the impact of a change that’s important. If some metric changes by, say, 5%, then it doesn’t really matter if it’s 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 <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.
>
> 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> <mailto:jeanpaulkogelman@me•com <mailto:jeanpaulkogelman@me•com>>> wrote:
>
> I’m 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’s 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 <mailto:bitcoin-dev@lists•linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>
> _______________________________________________
> 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>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #1.2: Type: text/html, Size: 7103 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Defining a min spec
2015-07-03 4:19 ` Jean-Paul Kogelman
@ 2015-07-03 5:33 ` Jeremy Rubin
2015-07-03 6:18 ` Jean-Paul Kogelman
2015-07-03 10:55 ` Jeff Garzik
0 siblings, 2 replies; 11+ messages in thread
From: Jeremy Rubin @ 2015-07-03 5:33 UTC (permalink / raw)
To: Jean-Paul Kogelman; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 5738 bytes --]
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’d be lucky
> to get about 33% effective utilization out of them (up to 50%, tops, but
> that’s really pushing it), so if you were to map this onto another
> architecture, you’d 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’t the important part. It’s
> the ability to measure the impact of a change that’s important. If some
> metric changes by, say, 5%, then it doesn’t really matter if it’s 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’m 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’s 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
>
>
>
[-- Attachment #2: Type: text/html, Size: 8034 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Defining a min spec
2015-07-03 5:33 ` Jeremy Rubin
@ 2015-07-03 6:18 ` Jean-Paul Kogelman
2015-07-03 10:55 ` Jeff Garzik
1 sibling, 0 replies; 11+ messages in thread
From: Jean-Paul Kogelman @ 2015-07-03 6:18 UTC (permalink / raw)
To: Jeremy Rubin; +Cc: bitcoin-dev
[-- Attachment #1.1: Type: text/plain, Size: 7135 bytes --]
I get it. :) Being able to run Bitcoin Core on open hardware is a noble (and important) goal! I hope that once we’ve figured out what the current requirements are that we can adjust these requirements (if needed) to include certain open hardware platforms. But that’s the next step. Bitcoin Core is a project in flight. Let’s first see where we’re 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’t surprise me if many of the real world requirements will center around Bitcoin Core’s 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 <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.
>
> 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’d be lucky to get about 33% effective utilization out of them (up to 50%, tops, but that’s really pushing it), so if you were to map this onto another architecture, you’d 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’t the important part. It’s the ability to measure the impact of a change that’s important. If some metric changes by, say, 5%, then it doesn’t really matter if it’s 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 <mailto: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 <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.
>>
>> 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> <mailto:jeanpaulkogelman@me•com <mailto:jeanpaulkogelman@me•com>>> wrote:
>>
>> I’m 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’s 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 <mailto:bitcoin-dev@lists•linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>
>> _______________________________________________
>> 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>
>>
>> _______________________________________________
>> 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>
>
>
[-- Attachment #1.2: Type: text/html, Size: 10739 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Defining a min spec
2015-07-03 5:33 ` Jeremy Rubin
2015-07-03 6:18 ` Jean-Paul Kogelman
@ 2015-07-03 10:55 ` Jeff Garzik
1 sibling, 0 replies; 11+ messages in thread
From: Jeff Garzik @ 2015-07-03 10:55 UTC (permalink / raw)
To: Jeremy Rubin; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
On Fri, Jul 3, 2015 at 1:33 AM, Jeremy Rubin <
jeremy.l.rubin.travel@gmail•com> wrote:
> 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.
>
Moxie was designed to be small and efficient from the compiler standpoint.
As a side effect, it is easy to audit from a security perspective. It
started life as a simulator + gcc compiler backend, and then later became
an FPGA implementation.
Moxie would benefit from focused effort in building out the hardware side
to be efficient on FPGA, developing and testing multi-core support and
related efforts. This area is less mature and could use attention. Start
at https://github.com/atgreen/moxiedev/tree/master/moxie/cores/moxie
In terms of other projects, there are many open source processor cores at
http://opencores.org
[-- Attachment #2: Type: text/html, Size: 2090 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2015-07-03 10:55 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-07-02 4:04 [bitcoin-dev] Defining a min spec Jean-Paul Kogelman
2015-07-02 7:18 ` Henning Kopp
2015-07-02 8:33 ` Jean-Paul Kogelman
2015-07-02 12:33 ` Mistr Bigs
2015-07-02 14:52 ` Owen Gunden
2015-07-03 3:13 ` Jeremy Rubin
2015-07-03 3:25 ` Jeff Garzik
2015-07-03 4:19 ` Jean-Paul Kogelman
2015-07-03 5:33 ` Jeremy Rubin
2015-07-03 6:18 ` Jean-Paul Kogelman
2015-07-03 10:55 ` Jeff Garzik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox