Dave Taht writes: > I find it puzzling that you still lose the measurement flows early on. > Setting some QoS on via WTD might be interesting. Well if you can be more specific, I'll be happy to. Was looking for a way to have per-protocol QoS settings, but there does not seem to be any From the documentation (only IP-based). > If you have a later OS than 3.13 on the sources/sinks you might want > to try sch_fq (and sch_pfifo_fast for reference) - the improvements to > Linux's TCP are such that on a short path like this that the control > loop stays very tight - only two TSO offloads per flow, really > accurate use of tcp timestamps, etc. Added a result set with sch_fq in place of fq_codel to the bottom of the same page. Doesn't appear to make much of a difference... > See also if you have hardware flow control enabled (via ethtool) If by that you mean pause frames, ethtool seems to think not: Settings for eth2: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: off Supports Wake-on: d Wake-on: d Current message level: 0x00000007 (7) drv probe link Link detected: yes -Toke