[Cerowrt-devel] archer c7 v2, policing, hostapd, test openwrt build

[Sebastian Moeller]

Hi Jonathan,

On Mar 24, 2015, at 09:13 , Jonathan Morton <chromatix99 at gmail.com> wrote:

> What I'm seeing on your first tests is that double egress gives you slightly more download at the expense of slightly less upload throughout. The aggregate is higher.

	But it is only slightly higher, and the uplink is not really saturated, it should be at around 30Mbps not 10 Mbps. Just to be clear we are talking about the same data: columns 5 and 6 are without sqm running, showing the download approaching the theoretical maximum, but pummeling the upload while doing so, cerowrt 3.10.50-1 might hit other limits besides shaping that limit the performance in this situation; the initial double egress columns are 3 and 4.

> 
> Your second set of tests tells me almost nothing, because it exercises the upload more and the download less.

	Why nothing? By reducing the total load on the shaper we can now see that avoiding the IFB overhead increases the upload by roughly 10Mbps, almost doubling it. IMHO this is the only real proof that ingress shaping via IFB has some cost associated. I realize that the IFB directly only affects the download direction but in this case the recovered CPU cycles seem to be used to increase the upload performance (which due to using simple instead of amplest.qos was costlier than it needed be).


> Hence why I'm asking for effectively the opposite test. The aggregate is still significantly higher with double egress, though.

	I have not performed any statistical test, so I am talking about subjective significance here, but I be the significance of the upload increase in the dual_symmetric_egress (columns 7 and 8) is going to be higher than the significance of the download increase in the double_egress situation (columns 3 and 4: larger mean difference similar variance, from quick visual inspection ;) )

> 
> The ping numbers also tell me that there's no significant latency penalty either way.

	Yes, the ping numbers are pretty nice, but even with SQM disabled the worst case latency is not too bad (not sure why though, I remember it to be much worse). Also the IPv6 RTT to Sweden seems consistently better than the IPV4 RTT; but then again this is DTAG linked, with DTAG’s new network being designed in Sweden, so maybe this is piggy-backing on their testing set-up or so ;) .

> Even when CPU saturated, it's still effectively controlling the latency better than leaving the pipe open.

Many thanks for the discussion & Best Regards
	Sebastian

> 
> - Jonathan Morton