đź“… Original date posted:2015-07-03
📝 Original message: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 at 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 at me.com <mailto:jeanpaulkogelman at 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 at gmail.com <mailto:jeremy.l.rubin.travel at 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 at phauna.org <mailto:ogunden at 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 at me.com <mailto:jeanpaulkogelman at me.com> <mailto:jeanpaulkogelman at me.com <mailto:jeanpaulkogelman at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150702/e7e20133/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150702/e7e20133/attachment.sig>;
Jean-Paul Kogelman [ARCHIVE] /
npub1sa…8y304
2023-06-07 15:41:31
in reply to nevent1q…ax83
Author Public Key
npub1sa86gng3pvs3jgyt5majwcrhn8ck5qxgy9pjqxkh79u638cd7dys28y304Published at
2023-06-07 15:41:31Event JSON
{
"id": "2208a1fdc1bb1f92139674ef87f53312fcb4cbe6636570e9db1fb1962078fb03",
"pubkey": "874fa44d110b2119208ba6fb27607799f16a00c82143201ad7f179a89f0df349",
"created_at": 1686152491,
"kind": 1,
"tags": [
[
"e",
"cbeb59b6768e318715a77120e4857024067bd925936ab9abad26dc3d4a343b49",
"",
"root"
],
[
"e",
"7a23bc2f0b13d5a9ab6ca2785fa57fa5874bf03e8a2ae9b7761bc7bc62b1e8e7",
"",
"reply"
],
[
"p",
"372c316761360b4ea20f2d7e81a59363b7e45b8e945a5381c3122049c2c4b84a"
]
],
"content": "📅 Original date posted:2015-07-03\n📝 Original message: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.\n\nWhat 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.\n\njp\n\n\n\u003e On Jul 2, 2015, at 10:33 PM, Jeremy Rubin \u003cjeremy.l.rubin.travel at gmail.com\u003e wrote:\n\u003e \n\u003e Jean-Paul,\n\u003e \n\u003e 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.\n\u003e \n\u003e 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.\n\u003e \n\u003e Jeff,\n\u003e \n\u003e 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?\n\u003e \n\u003e 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.\n\u003e \n\u003e On Fri, Jul 3, 2015 at 12:19 PM, Jean-Paul Kogelman \u003cjeanpaulkogelman at me.com \u003cmailto:jeanpaulkogelman at me.com\u003e\u003e wrote:\n\u003e 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.\n\u003e \n\u003e 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).\n\u003e \n\u003e 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.\n\u003e \n\u003e \n\u003e jp\n\u003e \n\u003e \n\u003e\u003e On Jul 2, 2015, at 8:13 PM, Jeremy Rubin \u003cjeremy.l.rubin.travel at gmail.com \u003cmailto:jeremy.l.rubin.travel at gmail.com\u003e\u003e wrote:\n\u003e\u003e \n\u003e\u003e 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.\n\u003e\u003e \n\u003e\u003e 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.\n\u003e\u003e \n\u003e\u003e Does anyone know how the RISC-V FPGA performance stacks up to, say, a Raspberry Pi?\n\u003e\u003e \n\u003e\u003e On Thu, Jul 2, 2015 at 10:52 PM, Owen Gunden \u003cogunden at phauna.org \u003cmailto:ogunden at phauna.org\u003e\u003e wrote:\n\u003e\u003e 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.\n\u003e\u003e \n\u003e\u003e On 07/02/2015 08:33 AM, Mistr Bigs wrote:\n\u003e\u003e I'm an end user running a full node on an aging laptop.\n\u003e\u003e I think this is a great suggestion! I'd love to know what system\n\u003e\u003e requirements are needed for running Bitcoin Core.\n\u003e\u003e \n\u003e\u003e On Thu, Jul 2, 2015 at 6:04 AM, Jean-Paul Kogelman\n\u003e\u003e \u003cjeanpaulkogelman at me.com \u003cmailto:jeanpaulkogelman at me.com\u003e \u003cmailto:jeanpaulkogelman at me.com \u003cmailto:jeanpaulkogelman at me.com\u003e\u003e\u003e wrote:\n\u003e\u003e \n\u003e\u003e I’m a game developer. I write time critical code for a living and\n\u003e\u003e have to deal with memory, CPU, GPU and I/O budgets on a daily basis.\n\u003e\u003e These budgets are based on what we call a minimum specification (of\n\u003e\u003e hardware); min spec for short. In most cases the min spec is based\n\u003e\u003e on entry model machines that are available during launch, and will\n\u003e\u003e give the user an enjoyable experience when playing our games.\n\u003e\u003e Obviously, we can turn on a number of bells and whistles for people\n\u003e\u003e with faster machines, but that’s not the point of this mail.\n\u003e\u003e \n\u003e\u003e The point is, can we define a min spec for Bitcoin Core? The number\n\u003e\u003e one reason for this is: if you know how your changes affect your\n\u003e\u003e available budgets, then the risk of breaking something due to\n\u003e\u003e capacity problems is reduced to practically zero.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e\u003e \n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev \u003chttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\u003e\n\u003e \n\u003e \n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150702/e7e20133/attachment.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 842 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150702/e7e20133/attachment.sig\u003e",
"sig": "aaa1a2e880f6d447b61ff2a4e3f38f8ef6ce70c86bf46577ebc539aadd56f2b472a6a39af8a1408ffecfc7e6c93f24033dd46c8638edc62f70e48f06787eecf3"
}