Henning Kopp [ARCHIVE] on Nostr: đź“… Original date posted:2015-07-02 đź“ť Original message:Hi Jean-Paul, that's a ...
đź“… Original date posted:2015-07-02
đź“ť Original message: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 at 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
đź“ť Original message: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 at 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