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 > > What happens if you disable all forms of AQM on the outgoing interface? This is on a gigE and bridged to wifi network primarily. Sorry, dude, ain't my fault here for a change. :) We're not even driving the interface hard enough for much fq to kick in. tc -s qdisc show dev enp7s0 qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn Sent 3757104160 bytes 2768425 pkt (dropped 0, overlimits 0 requeues 704) backlog 0b 0p requeues 704 maxpacket 68130 drop_overlimit 0 new_flow_count 695 ecn_mark 0 new_flows_len 0 old_flows_len 0 I don't see any drops on the outbound interface. I do see babel perhaps bottlenecking on the send buf a bit. It's on recv that's the issue here, more, I think. Need to do less work per recv. I can of course throw aqm at it, as normally I do run a box with sqm on it at 20Mbits, (where certainly drops become a huge issue) and am looking at wifi and get stats on that, but for a change, it's the code, not the network. I'm of course very interested in someday returning to the short-rtt-metric and ecn work, but what I wanted mostly to be done was to be able to deploy rfc-bis with confidence. I have a heck of a lot more confidence now... (how's the hmac branch? :) I'd like to get back on my atomic attempt also as the big reason networkmanager/odhcpd/dnsmasq go nuts is sending a lot of ip del/adds that could be modifies... > I.e. use large FIFO queues both at the interface layer and in the wifi > driver? I'll take a harder look at that later. I think increasing (sigh) the sndbuf and rcvbuf might "help"... but that way lies madness. babel recognizing there's congestion in the sndbuf and rescheduling/dropping that packet in order to get to the important ones (hellos) would be better. Not really testing wifi, I'd started with the intent to blow up bird. And I did. And then I got some lithium to throw in the pond.... > > -- Juliusz -- Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-205-9740 _______________________________________________ Babel-users mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/babel-users
