Dave Taht <dave.taht@gmail.com> 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