Girish Venkatachalam wrote: > On 08:00:08 Nov 16, Jonathan Stewart wrote: > >> I though about doing something like that but the usable upload is >> so variable that 60% could completely knock the normal_folk off >> when it gets congested. I have 256kbit up right now and get >> anywhere from as low as 64kbit to 160kbit+ actual throughput >> depending on how busy the system is. If PF had a weighted round >> robin queuing system that would be almost perfect because then it >> would scale with the amount of bandwidth available. Ideally >> something that says if one queue has priority 5 and another 3 for >> every 5 packets sent from the first one 3 are sent from the other, >> unless there is something wrong with that I'm missing (other than >> increased jitter.) > > What is stopping you from using the priority field with HFSC? > > And why don't you determine the average uplink bandwidth > statistically? > > If you measure it for a week or so and mark out the variance and > figure out the standard deviation or some such thing...then you can > do what you want. > > From my experience with ADSL links I find that there is usually not > much variance in the uplink path. > > Is my reasoning correct?
In my situation the up and down speeds are that variable over that large of a range. I'm on a commercial satellite system and for download (more accurate numbers) I get anywhere from 90KB/s to as low as 10KB/s, almost a full order of magnitude. Upload covers an equivalent range just lower numbers overall. I think trying to queue with PF is not very common in situations like mine, probably because it is very hard to do right, and I think that is why the existing queuing algorithms don't handle it very well. Jonathan Stewart
