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

[Sebastian Moeller]

Hi Jonathan,


On Mar 29, 2015, at 14:48 , Jonathan Morton <chromatix99 at gmail.com> wrote:

> 
>> On 29 Mar, 2015, at 14:16, Sebastian Moeller <moeller0 at gmx.de> wrote:
> 
> Okay, so it looks like you get another 5% without any shaping running.  So in summary:
> 
> - With no shaping at all, the router is still about 10% down compared to downstream line rate.

	Yes, roughly, but as I tried to explain, this is known quirk currently with VDSL2 lines of DTAG using vectoring, somehow the worst case overhead of the G.INP error correction is subtracted from the shaped rate at the BRAS, so this ~10% is non-recoverable from the user side (it is confusing though).

> - Upstream is fine *if* unidirectional.  The load of servicing downstream traffic hurts upstream badly.

	Yes, that is a theme though all the different variants of the tests I did.

> - Turning on HTB + fq_codel loses you 5%.

	I assume that this partly is caused by the need to shape below the physical link bandwidth, it might be possible to get closer to the limit (if the true bottleneck bandwidth is known, but see above).

> - Using ingress filtering via IFB loses you another 5%.
> - Mangling the Diffserv field loses you yet another 5%.
> 
> Those 5% penalties add up.  People might grudgingly accept a 10% loss of bandwidth to be sure of lower latency, and faster hardware would do better than that, but losing 25% is a bit much.

	But IPv4 simple.qos IFB ingress shaping: ingress 82.3 Mbps versus 93.48 Mbps (no SQM) =>  100 * 82.3 / 93.48 = 88.04%, so we only loose 12% (for the sum of diffserv classification, IFB ingress shaping and HTB) which seems more reasonable (that or my math is wrong). 
	But anyway I do not argue that we should not aim at decreasing overheads, but just that even without these overheads we are still a (binary) order of magnitude short of the goal, a shaper that can do up to symmetric 150Mbps shaping let alone Dave’s goal of symmetric 300 Mbps shaping.


> I should be able to run similar tests through my Pentium-MMX within a couple of days, so we can see whether I get similar overhead numbers out of that;

	That will be quite interesting, my gut feeling is that the percentages will differ considerably between machines/architectures.

> I can even try plugging in your shaping settings, since they’re (just) within the line rate of the 100baseTX cards installed in it.  I could also compare cake’s throughput to that of HTB + fq_codel; I’ve already seen an improvement with older versions of cake, but I want to see what the newest version gets too.

	I really hope to try cake soon ;)

> 
> Come to think of it, I should probably try swapping the same cards into a faster machine as well, to see how much they influence the result.
> 
>>> You see, if we were to use a policer instead of ingress shaping, we’d not only be getting IFB and ingress Diffserv mangling out of the way, but HTB as well.
>> 
>> But we still would run HTB for egress I assume, and the current results with policers Dave hinted at do not seem like good candidates for replacing shaping…
> 
> The point of this exercise was to find out whether a theoretical, ideal policer on ingress might - in theory, mind - give a noticeable improvement of efficiency and thus throughput.

	I think we only have 12% left on the table and there is a need to keep the shaped/policed ingress rate below the real bottleneck rate with a margin, to keep instances of buffering “bleeding” back into the real bottleneck rare…, 

> 
> The existing policers available are indeed pretty unsuitable, as Dave’s tests proved, but there may be a way to do better by adapting AQM techniques to the role.  In particular, Codel’s approach of gradually increasing a sparse drop rate seems like it would work better than the “brick wall” imposed by a plain token bucket.
> 
> Your results suggest that investigating this possibility might still be worthwhile.  Whether anything will come of it, I don’t know.

	Good point.

Best Regards
	Sebastian


> 
> - Jonathan Morton
>