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 }}
This repository has been archived by the owner on Aug 3, 2023. It is now read-only.
Several SpiNNaker maintenance tasks require access to BMPs. Currently, BMP commands are usually issued directly from bmpc or similar applications in the SpiNNaker hardware test suite.
These BMP accesses can "clash" with spalloc_server machine-configuration BMP commands, given that the current BMP software can only handle safely a single outstanding command over the frame CAN bus used for BMP communications.
A possible solution is to add a new spalloc_server service that can forward BMP commands, serialising them with its own BMP commands into a single stream. The serialisation infrastructure is already in place but the client-facing infrastructure needs to be added.
The text was updated successfully, but these errors were encountered:
The only thing I would add to this is to ensure that the commands sent don't interfere with the BMP in any way e.g. ensure it isn't possible to crash the BMP in such a way that would stop the machine being used. A possible solution to this is to add extra spalloc commands that align with specific BMP commands or groups of commands, similar to the power commands that we currently have. This would hopefully avoid potential breakages!
Another option would be to plug certain hardware tests themselves into spalloc as commands. Or instead have tests that run as part of the spalloc server and report (via email probably) when something goes wrong. A board-level test might be run just after each board is released for example, or periodic tests could run over multiple boards when the machine is deemed to be quiet.
spalloc running tests is a good idea but it would still need to provide support for the odd command, such as reading and writing blacklists, and providing board serial numbers, which are used in ad-hoc situations. As you suggest, this support can be provided by spalloc commands, to avoid forwarding an unsafe BMP command.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Several SpiNNaker maintenance tasks require access to BMPs. Currently, BMP commands are usually issued directly from bmpc or similar applications in the SpiNNaker hardware test suite.
These BMP accesses can "clash" with spalloc_server machine-configuration BMP commands, given that the current BMP software can only handle safely a single outstanding command over the frame CAN bus used for BMP communications.
A possible solution is to add a new spalloc_server service that can forward BMP commands, serialising them with its own BMP commands into a single stream. The serialisation infrastructure is already in place but the client-facing infrastructure needs to be added.
The text was updated successfully, but these errors were encountered: