Chris McGee escreveu:
> Hi guys-
>
>
>
> I've been using an OpenBSD firewall on my home network for about 10
> years. I recently upgraded the hardware to a retired gaming machine and
> went to OpenBSD 4.3 (woo!).
>
>
>
> I'm playing with the new scheduler in altq, and I like the way that it
> works, but the documentation is iffy and it still doesn't look like it
> solves one problem that priq and cbq couldn't solve... prioritizing
> outbound traffic on a variable-bandwidth link. (Yes, I've got a cable
> modem. =D)
>
>
>
> Here's the problem I'm trying to solve: My cable modem allows around
> 750kb/s when traffic is really ugly, and about 2100kb/s in the dead of the
> night. In order for the scheduler to know when to start limiting traffic,
> I have to tell it how fast the link is.... but I don't *know* how fast the
> link is, because it varies.
>
>
>
> I've been trying the following rules:
>
>
>
> altq on $ext_if bandwidth 2048Kb hfsc queue { ack, dns, games, def, bt }
> queue ack bandwidth 80% priority 6 qlimit 500 hfsc (realtime 50%
> ecn)
> queue dns bandwidth 5% priority 5 qlimit 500 hfsc (realtime 5%
> ecn)
> queue games bandwidth 5% priority 3 qlimit 500 hfsc (realtime 5% ecn)
> queue def bandwidth 5% priority 2 qlimit 500 hfsc (realtime 10%
> ecn default)
> queue bt bandwidth 5% priority 1 qlimit 500 hfsc (upperlimit 80%
> red)
>
>
>
> (the ack queue is TCP ack's, the dns queue is DNS requests, high priority
> user traffic and VOIP goes in "games", and the rest is regular and
> low-priority user traffic.
>
>
>
> When I'm usually using the internet connection, my outbound bandwidth is
> probably around 1200kb. Cranking the bandwidth down to 750 or so is one
> solution, but then I'm artificially limiting my own upstream to the worst
> case scenario.
>
>
>
> My questions are:
>
>
>
> 1) Is there a more effective way I could be doing the above?
>
Yes and no. You could have your modem checked by snmp every and so
seconds to see what velocity it was getting from your ISP. But this is
even if it supports it, and even if it changes the negotiated speed
trough these variations.
> 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?
> 3) Another hfsc question- exactly what does the linkshare statement do? The
> manpage says : " linkshare <sc> The bandwidth share of a backlogged
> queue.").
>
>
>
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.
>
>
> Thanks :)
>
>
>
> --Chris
>
>
>
My suggestion for you would be you to configure the highest rate you can
get as the bandwidth for the interface, to see how it would be. If your
rate decreases, it will get slow for the things that have less priority,
but, the altq implementation of openbsd kind of auto regulate the token
bucket based on the interface speed. 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. 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.
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
