High latency with small datachannel packets

[stevenlovegrove]

Working from head of main, I see very high latency when sending small packets - they are being delivered in bursts with large gaps > 500ms. I'm streaming to chrome via localhost. If I artificially increase the size of my data, I can reduce the latency considerably, so my first thought is that there is some min packet size / buffering issue, though I can't find any parameter to adjust, or piece of code responsible for that.

I've also been trying to reduce latency by disabling retransmits and ordering, but I seem to be hitting #371 which appears unresolved and I can verify that reliability configuration is not properly propagated. Even after I apply zduny@8a9138c from @zduny, and ensuring that the appropriate unorder and reliability values are set when getting to association_internal.rs logic, I can see packets are getting appended to the inflight queue and I'm receiving ACKS from the client (as shown when enabling trace logging) and latency isn't lowered. Presumably that is not expected? I can see that my outgoing packets and these ACKS are not interleaved - I can't determine if that is because of the output buffering or some in-flight flush logic?

Any pointers on what I could check in the code regarding these issues (1. buffering, 2. reliability config)?

[ris-work]

This is something I have noted as well. I have a temporary workaround which disables some reliability (retransmits) and stats aggregators and congestion control. It works very well with high throughput small packet applications. The fixes are in my repo, but they only work with unreliable datachannels. Do not use them at all if you need any form of reliability.
Moreover, this replacing this tokio thing in my application with native threads has resulted in about 10-100x speedup (>240Mbps from a few kbps) on local settings on an old intel i5 (3rd gen). Lowered RAM usage too (consumes only about 7-8 MiB max ram, even with 4 threads).