Re: ALTQ priq: bandwidth or no?
* Daniel Hartmeier <[EMAIL PROTECTED]> [2006-05-14 20:15]: > As I understand it, priq only affects things at all when a queue is > exceeding its bandwidth limit. As long as a queue is below the limit, it > does ABSOLUTELY NOTHING. Only when the limit is exceeded, priq drops > packets instead of sending them out, picking which packets to drop based > on the priorities. that is not entirely true. priq changes the order packets are sent out in, so that packets with a higher priority are sent out first. > It DOES NOT send out packets in an order (based on priorities) other > than the one they were queued in, while the bandwidth limit is not > reached. actually, it does - but of course that only kicks in when you have some packets queued. when your link is not saturated, there isn't much queued at all, so there is little to no effect from priq. check sys/altq/altq_priq.c:priq_dequeue() to see how packets are sent out - just by walking the queues (there likely is more than one outbound queue per interface when altq is in use) from highest to lowest priority. -- BS Web Services, http://www.bsws.de/ OpenBSD-based Webhosting, Mail Services, Managed Servers, ... Unix is very simple, but it takes a genius to understand the simplicity. (Dennis Ritchie)
Re: ALTQ priq: bandwidth or no?
Ah, you mean the following section in pf.conf(5)
bandwidth
Specifies the maximum bitrate to be processed by the queue. This
value must not exceed the value of the parent queue and can be
specified as an absolute value or a percentage of the parent
queue's bandwidth. If not specified, defaults to 100% of the par-
ent queue's bandwidth. The priq scheduler does not support band-
width specification.
(in particular, the last sentence)
But you have to read this in context. This section is about queue
definitions, i.e. lines that start with 'queue ...'. Not the 'altq on
...' lines.
The 'altq on ...' lines ALWAYS support the 'bandwidth' option. In fact,
they require it. If you omit it, and an interface knows its link layer's
media baudrate, pfctl will simply fill that in for you (and do NOTHING
more magical, it's precisely the same as if you had specified it).
So, given that you have a line like
altq on $ext_if priq bandwidth 200Kb queue { q_max, q_hig, q_def, q_low }
and you now define the queues like
queue q_max priority 7
queue q_hig priority 5
queue q_def priority 3
queue q_low priority 1 priq(default)
you can't use 'bandwidth' as option on those four lines (wouldn't make
sense to me, either). That's what the paragraph above means. And it's
clearly put in that context, read paragraph introducing the 'queue' options.
Daniel
Re: ALTQ priq: bandwidth or no?
* Damian Gerow <[EMAIL PROTECTED]> wrote: > The man page dictates that priq doesn't do bandwidth shaping, yet to define > a priq queue, you have to declare the bandwidth available. So which is it? How does the man page dictate (or even imply) that priq doesn't use the bandwidth parameter? As I understand it, priq only affects things at all when a queue is exceeding its bandwidth limit. As long as a queue is below the limit, it does ABSOLUTELY NOTHING. Only when the limit is exceeded, priq drops packets instead of sending them out, picking which packets to drop based on the priorities. It DOES NOT send out packets in an order (based on priorities) other than the one they were queued in, while the bandwidth limit is not reached. Hence, its entire operation is defined through the bandwidth parameter, and without any defined bandwidth limit, it couldn't do anything at all. > When defining the queue, it's the same available bandwidth for both ingress > and egress traffic. What happens to asynchronous links? There are no inbound queues in ALTQ. Incoming packets are simply not queued at all, and ALTQ does not in any way affect them or count them towards anything. Therefore this is not an issue. Daniel
Re: ALTQ priq: bandwidth or no?
Damian Gerow wrote:
> Thus spake Melameth, Daniel D. ([EMAIL PROTECTED]) [13/05/06
> 20:06]:
> > It would seem altq wants a bandwidth declaration. However, from
> > man 5 pf.conf:
> >
> > If bandwidth is not specified, the interface bandwidth is used.
>
> And OpenBSD complains bitterly when not defining the bandwidth on a
> pppoe virtual interface:
>
> # pfctl -F queue -f /etc/pf.conf
> altq cleared
> cannot determine interface bandwidth for pppoe0, specify an
> absolute bandwidth
> altq not defined on pppoe0
> /etc/pf.conf:73: errors in queue definition
>
> pfctl: Syntax error in config file: pf rules not loaded
> #
Perhaps the man page should be updated, but this doesn't appear to be
anything major and the message is quite verbose.
> > In any event, all my priq queues appear to simply be prioritized
> > and the overall outbound bandwidth of all queues, collectively,
> > never exceeds the altq bandwidth keyword--and this works well for
> > me with the exception of the annoying PR 4312.
>
> The way I'm reading 4312 is that priq is doing something it isn't
> supposed to do -- bandwidth throttling. No?
>
> And yes, it looks like I've run into 4312 as well. Annoying.
>
> The answer to my previous question leads me to one followup:
>
> My altq definition:
>
> altq on $ext_if priq bandwidth 700Kb queue { default, high,
> bittorrent, vpn, pubservices } queue default priority 3
> priq(default) queue high priority 7
> queue bittorrent priority 0
> queue vpn priority 4
> queue pubservices priority 5
> As priq seems to be doing bandwidth throttling, does this not place
> an artificial bandwidth restriction of 700Kb/s on my /inbound/
> traffic as well (which is something more in the order of a raw
> 3Mbps)? Yes, I fully recognize that by the time it gets here it's
> already traversed the pipe, but if altq only allows the OS to process
> at 700Kbps, then the pipe is effectively 700Kbps.
>
> (FWIW, I've done a few bandwidth tests that conradict that directly
> -- i.e.
> I transfer close to the practical maximum of 3Mbps, not the
> artificial maximum of 700Kbps. Hence my question.)
"Altq" is doing the bandwidth throttling for all queues on the
interface. Since priq cannot do bandwidth throttling on its individual
queues, it just does scheduling. As discussed in the past, altq only
work on outbound packets so this will not, directly, throttle your
download speed unless you apply it on your internal interface (with some
caveats.)
At least that's how I understand it.
Re: ALTQ priq: bandwidth or no?
Thus spake Jeff Quast ([EMAIL PROTECTED]) [14/05/06 08:12]: : THINK about it. I have. Which is why I'm confused on two points: The man page dictates that priq doesn't do bandwidth shaping, yet to define a priq queue, you have to declare the bandwidth available. So which is it? When defining the queue, it's the same available bandwidth for both ingress and egress traffic. What happens to asynchronous links?
Re: ALTQ priq: bandwidth or no?
On 5/13/06, Damian Gerow <[EMAIL PROTECTED]> wrote: As priq seems to be doing bandwidth throttling, does this not place an artificial bandwidth restriction of 700Kb/s on my /inbound/ traffic as well (which is something more in the order of a raw 3Mbps)? You're making an ass of yourself. THINK about it.
Re: ALTQ priq: bandwidth or no?
Thus spake Melameth, Daniel D. ([EMAIL PROTECTED]) [13/05/06 20:06]:
: It would seem altq wants a bandwidth declaration. However, from man 5
: pf.conf:
:
: If bandwidth is not specified, the interface bandwidth is used.
And OpenBSD complains bitterly when not defining the bandwidth on a pppoe
virtual interface:
# pfctl -F queue -f /etc/pf.conf
altq cleared
cannot determine interface bandwidth for pppoe0, specify an absolute
bandwidth
altq not defined on pppoe0
/etc/pf.conf:73: errors in queue definition
pfctl: Syntax error in config file: pf rules not loaded
#
: In any event, all my priq queues appear to simply be prioritized and the
: overall outbound bandwidth of all queues, collectively, never exceeds
: the altq bandwidth keyword--and this works well for me with the
: exception of the annoying PR 4312.
The way I'm reading 4312 is that priq is doing something it isn't supposed
to do -- bandwidth throttling. No?
And yes, it looks like I've run into 4312 as well. Annoying.
The answer to my previous question leads me to one followup:
My altq definition:
altq on $ext_if priq bandwidth 700Kb queue { default, high, bittorrent,
vpn, pubservices }
queue default priority 3 priq(default)
queue high priority 7
queue bittorrent priority 0
queue vpn priority 4
queue pubservices priority 5
is subsequently applied to the interface as such:
pass in quick on $ext_if inet proto tcp from any to $mailserver port
$mailports flags S/SA modulate state queue (pubservices, high)
pass in quick on $ext_if inet proto tcp from any to $webserver port
$webports flags S/SA modulate state queue (default, high)
pass in quick on $ext_if inet proto tcp from any to $btserver port $btports
flags S/SA modulate state queue (bittorrent, default)
pass in quick on $ext_if inet proto gre from any to $ian modulate state
queue (vpn, high)
pass out quick on $ext_if inet proto tcp from $external_addr to any flags
S/SA modulate state queue (default, high)
pass out quick on $ext_if inet proto { udp, icmp } from $external_addr to
any modulate state queue (default)
pass out quick on $ext_if inet proto gre from $external_addr to any
modulate state queue (vpn, high)
As priq seems to be doing bandwidth throttling, does this not place an
artificial bandwidth restriction of 700Kb/s on my /inbound/ traffic as well
(which is something more in the order of a raw 3Mbps)? Yes, I fully
recognize that by the time it gets here it's already traversed the pipe, but
if altq only allows the OS to process at 700Kbps, then the pipe is
effectively 700Kbps.
(FWIW, I've done a few bandwidth tests that conradict that directly -- i.e.
I transfer close to the practical maximum of 3Mbps, not the artificial
maximum of 700Kbps. Hence my question.)
Re: ALTQ priq: bandwidth or no?
Damian Gerow wrote: > Thus spake Jeff Quast ([EMAIL PROTECTED]) [11/05/06 09:22]: > > On 5/11/06, Damian Gerow <[EMAIL PROTECTED]> wrote: > > > I'm not interested in bandwidth limitations, so it looks like > > > priq is likely my best bet. > > > > > Then I create a queue with a bandwidth limit of 700Kbps. > > > > > The man page is a little vague on this point > > "The priq scheduler does not support band-width specification." > > > > huh? > > Exactly my point. The man page states that priq does /not/ support > bandwidth-restricted queues, yet the altq statement has a bandwidth > setting in it (and seems to require it). > > So: does priq do bandwidth queueing at all? Is the altq definition > wrong, or is the manpage misleading? > > (Or am I completely missing something here?) > > > Use cbq if you want to throttle bandwidth to a limit, something > > like: > > I don't. That's the point. It would seem altq wants a bandwidth declaration. However, from man 5 pf.conf: If bandwidth is not specified, the interface bandwidth is used. In any event, all my priq queues appear to simply be prioritized and the overall outbound bandwidth of all queues, collectively, never exceeds the altq bandwidth keyword--and this works well for me with the exception of the annoying PR 4312.
Re: ALTQ priq: bandwidth or no?
Thus spake Jeff Quast ([EMAIL PROTECTED]) [11/05/06 09:22]: : On 5/11/06, Damian Gerow <[EMAIL PROTECTED]> wrote: : >I'm not interested in bandwidth limitations, so it looks like priq is : >likely my best bet. : [...] : >Then I create a queue with a bandwidth limit of 700Kbps. : : >The man page is a little vague on this point : "The priq scheduler does not support band-width specification." : : huh? Exactly my point. The man page states that priq does /not/ support bandwidth-restricted queues, yet the altq statement has a bandwidth setting in it (and seems to require it). So: does priq do bandwidth queueing at all? Is the altq definition wrong, or is the manpage misleading? (Or am I completely missing something here?) : Use cbq if you want to throttle bandwidth to a limit, something like: I don't. That's the point.
MTU on DSL links (Was: Re: ALTQ priq: bandwidth or no?)
Thus spake Jeff Quast ([EMAIL PROTECTED]) [11/05/06 10:17]: : On 5/11/06, jacek <[EMAIL PROTECTED]> wrote: : >hi, that's part of your pf.conf : >---cut : ># normalize outbound packets to prevent mapping of LAN hosts : >scrub out on $ext_if all random-id min-ttl 250 : max-mss 1492 For the record, if you're on DSL and your ISP has an Ethernet cross-connect with the DSL provider (as opposed to ATM), your MTU is better set to 1452. You won't notice any speed difference until the DSL is loaded, at which point there will be less fragmentation on your packets, and less of a chance of your packets being dropped.
Re: ALTQ priq: bandwidth or no?
sorry i replied only to you :) , it's working coz you're setting max value which in your case it's not crossed above 1452 On 5/11/06, Jeff Quast <[EMAIL PROTECTED]> wrote: > > On 5/11/06, jacek <[EMAIL PROTECTED]> wrote: > > hi, that's part of your pf.conf > > ---cut > > # normalize outbound packets to prevent mapping of LAN hosts > > scrub out on $ext_if all random-id min-ttl 250 > max-mss 1492 > > > > Queueing > > ### > > # Note: Only outgoing traffic may be queued. > > ---cut > > i think you made a mistake in setting mss with mtu , > > You're right, fat fingers. > > > is that setting working for you at all ? max-mss for pppoe = 1452 , > other 1460 > Suprisingly, yes. Though it really shouldn't...
Re: ALTQ priq: bandwidth or no?
On 5/11/06, jacek <[EMAIL PROTECTED]> wrote: hi, that's part of your pf.conf ---cut # normalize outbound packets to prevent mapping of LAN hosts scrub out on $ext_if all random-id min-ttl 250 max-mss 1492 Queueing ### # Note: Only outgoing traffic may be queued. ---cut i think you made a mistake in setting mss with mtu , You're right, fat fingers. is that setting working for you at all ? max-mss for pppoe = 1452 , other 1460 Suprisingly, yes. Though it really shouldn't...
Re: ALTQ priq: bandwidth or no?
hi, that's part of your pf.conf
---cut
# normalize outbound packets to prevent mapping of LAN hosts
scrub out on $ext_if all random-id min-ttl 250 max-mss 1492
Queueing ###
# Note: Only outgoing traffic may be queued.
---cut
i think you made a mistake in setting mss with mtu , is that setting
working for you at all ? max-mss for pppoe = 1452 , other 1460
dalgorno
On 5/11/06, Jeff Quast <[EMAIL PROTECTED]> wrote:
>
> On 5/11/06, Damian Gerow <[EMAIL PROTECTED]> wrote:
> > I'm not interested in bandwidth limitations, so it looks like priq is
> likely my best bet.
> [...]
> > Then I create a queue with a bandwidth limit of 700Kbps.
>
> > The man page is a little vague on this point
> "The priq scheduler does not support band-width specification."
>
> huh?
>
> Use cbq if you want to throttle bandwidth to a limit, something like:
>
> altq on $ext_if cbq bandwidth $ext_bw queue \
> { q_ack_dns, q_fast, q_std, q_slow }
>
> # High port traffic, public services, p2p
> queue q_slowbandwidth 5% priority 0 cbq(borrow)
>
> # General tcp, udp, and icmp
> queue q_std bandwidth 20% priority 1 cbq(default, borrow)
>
> # Private and common services
> queue q_fastbandwidth 25% priority 2 cbq(borrow)
>
> # DNS requests and ACKs
> queue q_ack_dns bandwidth 50% priority 3 cbq(borrow)
>
> You need to use cbq. Just do as I did above and allow all the child
> queues to borrow from the root queue, so q_slow, for instance, may be
> limited to a mere 1K/s, but only if a higher priority queue is using
> all of the bandwidth (scp transfer, for instance), otherwise it will
> borrow from the root queue (376Kb/s in my case)
>
> make sure you set queue on pass out rules as well as pass in rules.
>
> look at pfctl -vvs queue to measure your queues' thoroughput
>
> my full pf.nat+queueing.conf here:
>
>
http://cvs.1984.ws/cgi-bin/cvsweb/pf/pf.nat%2bqueuing.conf?rev=1.1&content-ty
pe=text/x-cvsweb-markup
>
> many more here: https://solarflux.org/pf/
>
> you can search in a manpage using /
> or use the online manpage and your browser's find
> search for keyword 'bandwidth', and you would have quickly found the
> line that states priq scheduler does not support bandwidth
> specification.
Re: ALTQ priq: bandwidth or no?
On 5/11/06, Damian Gerow <[EMAIL PROTECTED]> wrote:
I'm not interested in bandwidth limitations, so it looks like priq is likely my
best bet.
[...]
Then I create a queue with a bandwidth limit of 700Kbps.
The man page is a little vague on this point
"The priq scheduler does not support band-width specification."
huh?
Use cbq if you want to throttle bandwidth to a limit, something like:
altq on $ext_if cbq bandwidth $ext_bw queue \
{ q_ack_dns, q_fast, q_std, q_slow }
# High port traffic, public services, p2p
queue q_slowbandwidth 5% priority 0 cbq(borrow)
# General tcp, udp, and icmp
queue q_std bandwidth 20% priority 1 cbq(default, borrow)
# Private and common services
queue q_fastbandwidth 25% priority 2 cbq(borrow)
# DNS requests and ACKs
queue q_ack_dns bandwidth 50% priority 3 cbq(borrow)
You need to use cbq. Just do as I did above and allow all the child
queues to borrow from the root queue, so q_slow, for instance, may be
limited to a mere 1K/s, but only if a higher priority queue is using
all of the bandwidth (scp transfer, for instance), otherwise it will
borrow from the root queue (376Kb/s in my case)
make sure you set queue on pass out rules as well as pass in rules.
look at pfctl -vvs queue to measure your queues' thoroughput
my full pf.nat+queueing.conf here:
http://cvs.1984.ws/cgi-bin/cvsweb/pf/pf.nat%2bqueuing.conf?rev=1.1&content-type=text/x-cvsweb-markup
many more here: https://solarflux.org/pf/
you can search in a manpage using /
or use the online manpage and your browser's find
search for keyword 'bandwidth', and you would have quickly found the
line that states priq scheduler does not support bandwidth
specification.
