Re: [Cerowrt-devel] Latest build test - new sqm-scripts seem to work; "cake overhead 40" didn't

[Sebastian Moeller <moeller0@gmx.de>]

Hi Alan,

On Jun 19, 2015, at 19:35 , Alan Jenkins <alan.christopher.jenkins@gmail.com> wrote:

> On 19/06/2015, Sebastian Moeller <moeller0@gmx.de> wrote:
>> Hi Alan,
>> 
>> excellent, thanks a million.
>> 
>> On Jun 19, 2015, at 16:44 , Alan Jenkins
>> <alan.christopher.jenkins@gmail.com> wrote:
>> 
>>> Hi
>>> 
>>> I guess I've done the complementary half to Seb's test :).  Basically
>>> "cake overhead 40" didn't work, but that's the fault of cake in this
>>> build.  Or tc, as Johnathan suggested.  (The "cake atm" part seems to
>>> work, as per my previous test).
>> 
>> 	Great!
>> 
>>> 
>>> "tc qdisc" says "cake overhead 0", as Sebastian noticed.  And the test
>>> results show "cake overhead 40" does not give a measurable
>>> improvement.  But "tc stab overhead 40" does.
>>> 
>>> I ran this test with the updated sqm-scripts and I think they're doing
>>> the right thing.
>> 
>> 	Thanks for testing this, especially as I can not due to a lack of an
>> ADSL-link (and lack of cake actually, last I looked all I could find was
>> cookies in my browser and a promise of pie in my router)
>> 
>>> 
>>> 
>>> Method:
>>> 
>>> I used the updated files from sqm-scripts,
>>> 
>>> (once I remembered to mark them executable.  Lacking that causes a
>>> failure with no error messages, because sqm-scripts checks before
>>> running them :)
>>> 
>>> but didn't bother updating & using luci-app-sqm.
>> 
>> 	Ah, okay, I guess I did test this part with Dave’s help, so this should
>> work with the most recent sqm.lua.
>> 
>>> 
>>> The test was to compare netperf-runner results - ping during combined
>>> upload & download - for "overhead 40" and "overhead 0".  I tested both
>>> values of linklayer_adaptation_mechanism.
>>> 
>>> I had to repeat 6 times (60s per run for each overhead) because of
>>> random variation in the range of 3-4ms.  I alternated "overhead 40"
>>> and "overhead 0" to try and exclude longer-term variation effects.
>>> 
>>> With "stab overhead 40", median latency was better by about 3-4ms.
>>> With "cake overhead 40", there is no such effect.
>> 
>> 	Intersting, when I still had a 6M/1M ADSL link, I saw much larger latency
>> under load increases when setting the per packet overhead to small, but I
>> had my egress shaper running at 100% of line rate, so the system was rigged
>> for maximum effect that way. How are your shapers typically set?
> 
> For this test I try to push it, today I used 95%.  I started trying
> 100%, which is still much better than unshaped.  I was scared off by
> the random variation, I think it was higher at 100%.

	Fair enough, but only at 100% you will notice if the overhead is off by a single byte… You are running sqm on the pppoe interface, correct?

> 
> For long term use I reduce it, because I've seen the line rate vary
> slightly.  (1020k up today, 912 a while back.  Currently it reports a
> "max" figure I don't understand, it's about 1100 despite being
> rebooted daily.  16390k down).

	A pity that your line is that flaky, but it only differs between reboots and does not change during the day? As far as I know only SRA would allow rate changes while the sync stays up. So you either have unscheduled resyncs during the day which drag in a rate change or between days. Anyway aiming with the shaper rate at below the best case sync seems wise unless you want to fiddle with modem and router daily. (It would be sweet if one could query the actual sync speed from XDSL-modems from the LAN side in a standardized fashion, so sqm could learn to set the shaper automatically).

Best Regards
	Sebastian

> 
> Alan