Dave Taht <[email protected]> writes: > On Thu, Nov 8, 2018 at 1:40 PM Dave Taht <[email protected]> wrote: >> >> On Thu, Nov 8, 2018 at 1:21 PM Juliusz Chroboczek <[email protected]> wrote: >> > >> > > things fall apart at about 32k in this case. >> > >> > That's pretty good. We'll reach your 64k target when we get around to >> >> It's a worthy goal, but really excessive. :) I basically wanted to >> know the limits >> of the lowest end hw I had, for real, before daring to try and deploy >> ipv6 willy nilly again. >> >> > fixing the resend data structure >> >> Got any ideas? I enjoyed poking into the latest trie research (source >> specific routing is a new area!) and I really enjoyed learning about >> skiplists last week, am liking the uthash potential long term... >> >> > and implement pacing in the buffer >> > flushing code. >> >> Pacing can be done at the socket layer now and it's been working for >> udp and QUIC since, oh, about 4.12? 4.9? can't >> remember. I tried this at one point. Easy patch to fiddle with to >> "just turn it on" >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=62748f32d501f5d3712a7c372bbb92abc7c62bc7 > > This no longer requires the fq scheduler, btw. Problem is (as the quic > folk are experiencing) is that the kernel doesn't know > (at least not with public patches) that you can send udp at one rate > one way, and another at another. tcp can do it per connection.
There is also a socket option that allows you to set an "earliest send time" on each packet... Can't remember what it's called, but it ties into Van's timer wheel idea... -Toke _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
