Hi all :) I''ve been using a tc setup for almost two years, but at some point (probably when I switched to kernel 2.6.x, but I''m not sure) it has started making something very weird. For a certain class, the rate is 125000bit and the ceil is 270000bit, but the fastest rate I get is about 75-80000bit, instead of the "promised" 125000, *with no other traffic in the device*. If I disable tc entirely, the upload rate is more than 300000bit (a little below the line capacity, which is 320000bit), but as soon as tc is enabled again, the upload speed drops again to 75-80kbit. There is no other traffic on the device, really, it''s just like if the htb couldn''t queue packets fast enough :??? I''ve thought that the culprit may be cpufreq. I have cpufreq scaling activated, and cpufreq reduces the clock speed from 1800MHz to 1000MHz when the processor is idle. This is more or less the same amount that I "lose" in the rate. May this be the problem? How to fix without deactivating cpufreq? I''m using htb+sqf, and I can post here my tc setup if needed (is quite short), including the filters. It should be OK, since it has been working for almost two years. Right now I cannot disable cpufreq because temperature problems, and I cannot shut down the machine either, so I cannot test if cpufreq is the culprit, that''s why I''m asking. I haven''t found anything while googling, either. If anybody has any idea about this problem, please tell. Thanks a lot in advance :)) Raúl Núñez de Arenas Coronado -- Linux Registered User 88736 | dervishd.net It''s my PC and I''ll cry if I want to... RAmen!
DervishD wrote:> Hi all :) > > I''ve been using a tc setup for almost two years, but at some point > (probably when I switched to kernel 2.6.x, but I''m not sure) it has > started making something very weird. > > For a certain class, the rate is 125000bit and the ceil is > 270000bit, but the fastest rate I get is about 75-80000bit, instead of > the "promised" 125000, *with no other traffic in the device*. > > If I disable tc entirely, the upload rate is more than 300000bit (a > little below the line capacity, which is 320000bit), but as soon as tc > is enabled again, the upload speed drops again to 75-80kbit. There is no > other traffic on the device, really, it''s just like if the htb couldn''t > queue packets fast enough :??? > > I''ve thought that the culprit may be cpufreq. I have cpufreq scaling > activated, and cpufreq reduces the clock speed from 1800MHz to 1000MHz > when the processor is idle. This is more or less the same amount that I > "lose" in the rate. May this be the problem? How to fix without > deactivating cpufreq?Could be - I don''t know. Forgetting cpufreq htb can be limited by Hz if the burst size is too small. tc -s -d class ls dev ... should show the size being used.> > I''m using htb+sqf, and I can post here my tc setup if needed (is > quite short), including the filters. It should be OK, since it has been > working for almost two years. Right now I cannot disable cpufreq because > temperature problems, and I cannot shut down the machine either, so I > cannot test if cpufreq is the culprit, that''s why I''m asking. I haven''t > found anything while googling, either.If you have perturb too low on sfq the packet reordering it causes could make the sender back off too much. Andy.> > If anybody has any idea about this problem, please tell. Thanks a > lot in advance :)) > > Raúl Núñez de Arenas Coronado >
Hi Andy :) * Andy Furniss <lists@andyfurniss.entadsl.com> dixit:> DervishD wrote: > > I''ve thought that the culprit may be cpufreq. I have cpufreq scaling > >activated, and cpufreq reduces the clock speed from 1800MHz to 1000MHz > >when the processor is idle. This is more or less the same amount that I > >"lose" in the rate. May this be the problem? How to fix without > >deactivating cpufreq? > > Could be - I don''t know. Forgetting cpufreq htb can be limited by Hz if > the burst size is too small.I''ve tested with a burst size of 1500 (my MTU) and with precomputed values (which are 1614b for burst, 1633b for cburst) and the result is the same. I''m using HZ=1000 in my kernel, so my resolution is 1ms. According to HTB docs, the burst that will cause the rate to be burst-bound is 272000bit * 1m = 272bit.> > I''m using htb+sqf, and I can post here my tc setup if needed (is > >quite short), including the filters. It should be OK, since it has been > >working for almost two years. Right now I cannot disable cpufreq because > >temperature problems, and I cannot shut down the machine either, so I > >cannot test if cpufreq is the culprit, that''s why I''m asking. I haven''t > >found anything while googling, either. > > If you have perturb too low on sfq the packet reordering it causes could > make the sender back off too much.I have a perturb of 10, as I''ve always used. Finally I could turn the machine off and clean the CPU fan, so I''ve make a test using the performance governor and the ondemand governor of cpufreq and yes, the problem is the cpufreq thing :(((( I''ll start a new thread here for this and will report to LKML too. Thanks for your answer :)) Ra?l N??ez de Arenas Coronado -- Linux Registered User 88736 | dervishd.net It''s my PC and I''ll cry if I want to... RAmen!
Andy Furniss
2007-Aug-28 13:20 UTC
[LARTC] HTB doesn''t give me the promised rate: cpufreq?
DervishD wrote:> I''ll start a new thread here for this and will report to LKML too.OK you should probably report to netdev@vger.kernel.org rather than LKML. Andy.
Hi Andy :) * Andy Furniss <lists@andyfurniss.entadsl.com> dixit:> DervishD wrote: > > I''ll start a new thread here for this and will report to LKML too. > > OK you should probably report to netdev@vger.kernel.org rather than LKML.I was considering it, but then I thought that maybe this problem was known and affecting other parts of the kernel. Given the lack of response, probably reporting to netdev is better. I''ll bounce the message there. Thanks :) Ra?l N??ez de Arenas Coronado -- Linux Registered User 88736 | dervishd.net It''s my PC and I''ll cry if I want to... RAmen!