Chris McGee escreveu:
> Giancarlo, thank you for your ideas.
>
>
>
>
>
>   
>>>> 2) Regarding hfsc, what is the old "bandwidth" statement used for? It 
>>>>         
>> seems 
>>     
>>>> like it would be obsolete. Changing it doesn't seem to affect 
>>>>         
>> anything, 
>>     
>>>> either. The manpage doesn't say. :)
>>>>   
>>>>         
>>> What do you mean by "old" bandwidth?
>>>       
>>
>>
>>
>> I mean that the bandwidth statement seems to be deprecated... you can set 
>> those numbers to anything you want, and the behavior of the scheduler 
>> doesn't seem to change. Also, upper limit, lower limit, priority, and 
>> linkshare are all specifically defined in other statements, so it seems 
>> like a bandwidth directive really doesn't give the scheduler any 
>> instructions that it didn't already have.
>>
>>
>>
>> What I'm asking is whether hfsc even looks at the value of the 
>> "bandwidth" statement. (I know that it is used in cbq and priq, and I 
>> know what it does there, but hfsc is new to me. :)  )
>>
>>
>>
>>
>>     
>>> The linkshare statement specify how much of the bandwidth of that queue
>>> will be shared with other queues when not used. Think in it like a
>>> shared pool.
>>>       
>>
>> Ahh, it must default to 100% then, because I see full usage (up to 
>> whatever I define the bandwidth as) of the link with no linkshare 
>> statements in my config file.
>>
>>
>>  >If you modem doesn't get to renegotiate the speed with you ISP, then 
>> you are doomed,
>>
>>     
>>> because snmp won't work, so you variable rate won't work either. 
>>>       
>>
>> I never thought of using snmp for this. I bet it doesn't help even if it 
>> does work (I bet everyone's modem is running at 38mb/s, and the bandwidth 
>> of the segment itself limits the number of packets that pass), but if the 
>> client modems DO renegotiate individual speeds, that would be neat. I 
>> have a Motorola SB5100, which does have some SNMP functions. I'm 
>> installing scli from ports right now, and I'll play with it. That would 
>> rock. However, I bet it doesn't renegotiate; my available bandwidth just 
>> depends on how much traffic the other users on my segment are generating.
>>
>>
>>
>>     
>>> You can do something. You can install syweb or any other graph tool to 
>>>       
>> measure how
>>     
>>> your bandwidth vary trough, i'd say, a week. Based on that, you can have
>>> cron entries to change you hfsc rates trough the day. This could work 
>>>       
>> also.
>>
>>
>>
>> That's a good idea, but that is sort of hit or miss since the congestion 
>> is obviously sort of random.
>>
>>
>>
>> Thanks again! I'll let you know how the snmp thing works out (still 
>> building dependencies) :).
>>     
>
>
>   
Looks like i didn't got your reply before. I hardly doubt that your
modem renegotiate the speed but, worth checking. Also, what you said
about the same subnet, it's true. If the others users on the same subnet
of yours do a burst, your rate will suffer also. Try to see what your
minimum rate is, and configure that for your total bandwidth parameter.
When the rate goes up, the percentages you used, might follow it though,
i didn't tested it.

My regards,

-- 
Giancarlo Razzolini
http://lock.razzolini.adm.br
Linux User 172199
Red Hat Certified Engineer no:804006389722501
Verify:https://www.redhat.com/certification/rhce/current/
Moleque Sem Conteudo Numero #002
OpenBSD Stable
Ubuntu 8.04 Hardy Heron
4386 2A6F FFD4 4D5F 5842  6EA0 7ABE BBAB 9C0E 6B85

Reply via email to