finished the hub's logic, half done with the interfaces, and hopefully working on pi logic soon
This commit is contained in:
71
devlog/2025-06-05-Much-progress.md
Normal file
71
devlog/2025-06-05-Much-progress.md
Normal file
@ -0,0 +1,71 @@
|
||||
# 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.
|
Reference in New Issue
Block a user