Conversation
The previous behavior was saving everything (both in-order and out-of-order fragments) in req_u->dat_y and in the case of out-of-order fragments, we were skipping the lss verifification check. They were of course in the misordered queue as well, and burning them was just doing nothing—we were never transferring them to the main queue, they were already there— but, the misorderd handling was not increasing the pending fragment, so it's likely that we were hearing those fragments again, this time in order, so when trying to burn the queue we were failing to verify them since they were duplicates.
run all tests with: `zig build ur-test ent-test hashtable-test jets-test nock-test retrieve-test serial-test ames-test boot-test newt-test vere-noun-test unix-test benchmarks`
(u3h_put_get returns the key-value pair, and the jumbo cache line was in the value)
This PR does all kinds of stuff. The main ones are the following: The udp receive buffer for ames and mesa is now statically allocated. The sending buffer for ames is also statically allocated, so now we use `uv_udp_try_send` instead of `uv_udp_send` in ames. The meaning of the bitset in the mesa pending request structure is different. It used to answer the question whether we have an outstanding request for a particular fragment, whereas now it answers the question "do we have this fragment?". The misordered queue for mesa is now arbitrarily large instead of 8 fragments long. This means that we can receive fragments in any order.
A beautiful idea but given that the receive buffer sometimes ends up as the sender buffer in `ames.c` and that `uv_udp_try_send` fails a lot with dead flow consolidation turned on we have to revert this.
My changing of the semantics of the request bitset in #754 messed with the congestion control. This PR restores the outstanding fragments in flight tracking by using a counter, getting 30 mb/s with this for pokes on a M2 max locally.
I was messing with static udp receive buffer allocation in #754. We decided to revert it in #755, but I missed one `c3_free` in the stun request packet codepath, causing a fairly significant memory leak when `vere-v3.2` was deployed on a galaxy. This restores the old free and plugs the leak. This bug was unreleased and only appeared on `edge` and specifically only on galaxies, it showed up now because I updated the custom binary on `~fen` for unrelated reasons.
This PR contains several big improvements to the mesa driver: * We don't allocate nouns all over the place anymore. * To enable the previous we don't use our HAMT anymore, instead we use a [off-the-shelf hashtable](https://github.com/JacksonAllan/Verstable). * We don't do individual `malloc` and `free` calls all over the place anymore. The allocations have been grouped into lifetimes each with their own memory arena. * We don't allocate at all when we don't need to. As a result we go from around 15 megabytes/second to 190 megabytes/second bandwidth for localhost peeking on my macbook M2. Corresponding speeds between two terrible 1 cpu 2gb VM:s situated on the other sides of the Atlantic go from around 2 megabytes/s to 18 megabytes/s. There is still room to optimize the speed of directed messaging but this is certainly good enough for an initial release. The main thing that's somewhat wonky still is the congestion control.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.