3.1 KiB
Reworking Almost Done
Date: 2025-06-05
Goals and expectations
Build the framework for the entire fabric's logic.
Results
Nicely done.
This should've been split into several commits, but it's still work on the same project. The following is all that's been done:
- Completed the hub's logic.
- Began reworking the interfaces' logic, already done with the RX side of things (the RX side always seem simpler).
- Built my own
git
server usinggitea
andnginx
to host my stuff (ROSE included). - Removed
specifications.md
and revisedprotocol.md
to keep them updated with the reworked routing logic.
Is KISS elegance?
Keep It Simple, Stupid. Is this elegance?
It could be, when everything else is working within strict bounds (e.g. the hub's strict logic), leveraging that strictness to simplify some logic (e.g. adding a cooldown period for queue slot allocation) is elegance. Leveraging the strictness allows the logic to be simplified, and the simplicity is elegance in its most natural form.
Reflections
- KISS. Letting the interfaces manage the packet addresses was a great decision. It dumbed down the hub's logic at the cost of adding a bit of complexity to the interfaces' logic. This would also make things do one thing and do that thing well.
- Be organized. Organize the components by their functionalities. It would prove to be very useful when there's a dozen latches coming in and out of the interfaces/hub and you'd like to know if you missed something.
- Get sidetracked, absorb outside stimulation. Even though my last
devlog said to focus, there's still the need to know how other
things operate, even if they may seem irrelevant. I remember
reading the code for
SMaRTT-REPS
andSTrack
and some new CC algorithms for UET during my time at Huawei, and then reading one of their proprietary CC algorithms, which had a much simpler logic but performs similar to the above-mentioned more complex ones. Getting sidetracked would help you think - is there a simpler way to achieve what I want? - Get started. I think I might stress this every time two commits happen days away from each other, but I can never stress this enough. I spent hours deciding whether or not to start coding with the time I have on hand, but the real action only took a fraction of that time. Begin, progress is progress, no matter how much it is.
Final thoughts
There are a lot of ideas that are still "under validation" in my mind, like for example implementing a dual-issue round-robin scheme for the hub to increase the maximum throughput and prepare ROSE for scale. They don't go unnoticed, I'd add them to the devlog and hoping that someday when I get the leisure to return to them, I can implement them.
Also, finding time for ROSE has been hard, only fragments of time has been found on most days. But there's no say that I can't do something with that time.
Next steps
Complete the TX logic, figure out the byte syncing for the SPI side of things, and also test the things out on a TB and hopefully start making my way back to C land on RPi's.