72 lines
3.1 KiB
Markdown
72 lines
3.1 KiB
Markdown
# 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:
|
|
|
|
1. Completed the hub's logic.
|
|
2. Began reworking the interfaces' logic, already done with the RX
|
|
side of things (the RX side always seem simpler).
|
|
3. Built my own `git` server using `gitea` and `nginx` to host my
|
|
stuff (ROSE included).
|
|
4. Removed `specifications.md` and revised `protocol.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
|
|
1. 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.
|
|
2. 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.
|
|
3. 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` and `STrack` 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?
|
|
4. 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.
|