You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Document hardware spec requirements for Linux streaming system #38
We need to find, document, and then ultimately purchase servers for the Linux streaming system.
Purchasing is out-of-scope for this ticket; this ticket is to:
Find a suitable spec for our data streaming Linux systems
Use old ESS servers, or another suitable server, as a performance-testing platform
Talk to other teams who have experience with similar systems (e.g. SuperMuSR)
Research general industry recommendations based on our expected message rates, messages sizes, and so on
Decide on the expected lifetime of the system
Ensure sufficient performance headroom is available for foreseeable future use-cases (for at least the expected lifetime of the system), code that will be run on this server by other teams, etc
Document spares strategy
Consider using same hardware as SuperMuSR - share spares?
Consider using a standardised "neutron" spec - which then needs to be high enough to cope with any neutron instrument
Document (with justification) the spec that we intend to use as a data streaming ADR
Steer from HRPD-X project management in broad terms is that the sums we're talking about are not particularly large / significant in the context of the wider project, and if there are tradeoffs on cost/reliability we should probably err towards higher reliability (up to a point, obviously).
We may want to spec-up a couple of different hardware options (for example, single node versus a multi-node cluster with some resiliency) and present them at e.g. a HRPD-X computing meeting.
From looking at their cluster at the moment, SuperMuSR test cluster looks to have a data rate of around 750 mbit/s (which for a 5-node cluster is ~150 mbit/s per node). Have asked what worst-case they have specced for.
HRPD-X is expecting ~50 mbit/s 99th percentile and SANDALS-II is expecting ~600 mbit/s 99th percentile. So it would seem reasonable to use one node of the SuperMuSR spec for HRPD-X, we would likely then need more than one redpanda node (4?) for SANDALS-II.
Note: SuperMuSR nodes are only acting as Kafka brokers and their compute nodes are separate, ours would also be running some additional processes e.g. kdaediag, filewriter, etc so will need some extra performance headroom compared to SuperMuSR.
As a sanity check I checked online for best-practice kafka/redpanda cluster sizing guides - the per-node throughput ranges quoted online are 400 mbit/s to ~2 gbit/s. Leaving some performance headroom for particularly fast-counting samples/beamline configurations, this is approximately in line with the SuperMuSR specs.
Activity
Tom-Willemsen commentedon Feb 27, 2026
Steer from HRPD-X project management in broad terms is that the sums we're talking about are not particularly large / significant in the context of the wider project, and if there are tradeoffs on cost/reliability we should probably err towards higher reliability (up to a point, obviously).
We may want to spec-up a couple of different hardware options (for example, single node versus a multi-node cluster with some resiliency) and present them at e.g. a HRPD-X computing meeting.
Tom-Willemsen commentedon Mar 3, 2026
https://docs.redpanda.com/current/deploy/redpanda/manual/production/requirements/
Tom-Willemsen commentedon Mar 5, 2026
SuperMuSR redpanda cluster is 5 nodes, each node is:
SuperMuSR additionally have a 5 node "compute" cluster which will likely be similar spec nodes to above.
Tom-Willemsen commentedon Mar 6, 2026
From looking at their cluster at the moment, SuperMuSR test cluster looks to have a data rate of around 750 mbit/s (which for a 5-node cluster is ~150 mbit/s per node). Have asked what worst-case they have specced for.
HRPD-X is expecting ~50 mbit/s 99th percentile and SANDALS-II is expecting ~600 mbit/s 99th percentile. So it would seem reasonable to use one node of the SuperMuSR spec for HRPD-X, we would likely then need more than one redpanda node (4?) for SANDALS-II.
Note: SuperMuSR nodes are only acting as Kafka brokers and their compute nodes are separate, ours would also be running some additional processes e.g.
kdaediag, filewriter, etc so will need some extra performance headroom compared to SuperMuSR.As a sanity check I checked online for best-practice kafka/redpanda cluster sizing guides - the per-node throughput ranges quoted online are 400 mbit/s to ~2 gbit/s. Leaving some performance headroom for particularly fast-counting samples/beamline configurations, this is approximately in line with the SuperMuSR specs.