some (hopefully basic) altq questions ...

[Andrew Atrens]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Marquette wrote:
> Redirecting to pf at benzedrine.cx and freebsd-pf at freebsd.org as slightly
> more appropriate lists than misc@
> 
> On 2/8/06, Andrew Atrens <atrens at nortel.com> wrote:
> 
>>Here's what I have today, that looks to be working well -
>>
>>
>>altq on $ext_if cbq bandwidth 100Mb queue { output_ext }
>>queue output_ext bandwidth 850Kb cbq { std_ext,  known_ext, torrent_ext, tcp_ack_ext }
>>queue std_ext     bandwidth 75%  priority 1 cbq(default red) qlimit 100
>>queue torrent_ext bandwidth 75%  priority 1 cbq(red) qlimit 1
>>queue known_ext   bandwidth 90% priority  3 cbq(borrow) qlimit 100
>>queue tcp_ack_ext bandwidth 10% priority  7 cbq(borrow) qlimit 100
> 
> 
> That parses????  It shouldn't!

It does on FreeBSD/DragonFly... Here's the output of pftop -

QUEUE               BANDW SCH  PRI    PKTS   BYTES   DROP_P   DROP_B QLEN BORRO SUSPE  P/S   B/S
root_sis0            100M cbq    0  33669K   3172M        0        0    0     0     0   70   43K
 output_ext          850K cbq            0       0        0        0    0     0     0    0     0
  std_ext            637K cbq      4585421   2142M        0        0    0     0 37200    7    5K
  torrent_ext        637K cbq       27013K 680853K  4892332 2782866K    0     0  960K   60   37K
  known_ext          765K cbq    3 2208318 370475K        0        0    0  4930  2554    2   231
  tcp_ack_ext         85K cbq    7   22124 3491277        0        0    0     9     0    0     0
root_ath0             20M cbq    0  30474K   2653M        0        0    0     0     0   55   30K
 std_int              17M cbq      7490316 145327K        0        0    0    10     0   16    6K
 mail_int             17M cbq    2  147814 107723K        0        0    0     0     0    0     0
 http_int             17M cbq    4 1813838   1763M        0        0    0 27250     0    0     0
 ssh_bulk_int          3M cbq    4   93721  20410K        0        0    0     0     0    0     0
 tcp_ack_int           1M cbq    7  102611  21585K        0        0    0    67     0  0.2    70
 torrent_int          10M cbq    0  21052K 617201K        0        0    0   458     0   38   24K



> 
> # pfctl -nf /tmp/foo
> pfctl: the sum of the child bandwidth higher than parent "output_ext"
> pfctl: the sum of the child bandwidth higher than parent "output_ext"
> pfctl: the sum of the child bandwidth higher than parent "output_ext"
> pfctl: queue bandwidth must be larger than 123.77Kb
> cbq: queue tcp_ack_ext is too slow!
> # cat /tmp/foo
> altq on lo0 cbq bandwidth 100Mb queue { output_ext }
> queue output_ext bandwidth 850Kb cbq { std_ext,  known_ext,
> torrent_ext, tcp_ack_ext }
> queue std_ext     bandwidth 75%  priority 1 cbq(default red) qlimit 100
> queue torrent_ext bandwidth 75%  priority 1 cbq(red) qlimit 1
> queue known_ext   bandwidth 90% priority  3 cbq(borrow) qlimit 100
> queue tcp_ack_ext bandwidth 10% priority  7 cbq(borrow) qlimit 100
> 
> That's from a early January OpenBSD 3.8 snapshot, FYI.
> 
> 
>>Notice the percentages don't add up ?
>>
>>I *thought* I should be doing something like -
>>
>>altq on $ext_if cbq bandwidth 100Mb queue { output_ext }
>>queue output_ext bandwidth 850Kb cbq { std_ext,  known_ext, torrent_ext, tcp_ack_ext }
>>queue std_ext     bandwidth 5%  priority 1 cbq(default red borrow) qlimit 100
>>queue torrent_ext bandwidth 5%  priority 1 cbq(red borrow) qlimit 1
>>queue known_ext   bandwidth 80% priority  3 cbq(borrow) qlimit 100
>>queue tcp_ack_ext bandwidth 10% priority  7 cbq(borrow) qlimit 100
> 
> 
> That's the correct syntax if I grok the man pages correctly myself.
> 
> 
>>But with this config torrent uploads *crawl*, at most using 6 or 7 % of the available
>>bandwidth - lots of dropped packets are preventing tcp from ramping up the connection
>>speed, this regardless of whether or not the bw is being used by the other queues.
> 
> 
> This sounds suspiciously like kern/82271
> (http://www.freebsd.org/cgi/query-pr.cgi?pr=82271) which I'm seeing
> problems with too.  We just noticed however that we were compiling an
> SMP kernel and weren't using option ALTQ_NOPCC which the man page says
> is required although I'm not sure it is (unless you're on a multi-proc
> alpha - see below) as that option is only referenced twice in
> altq_subr.c.  Once do set machclk_usepcc to 0 (which SMP will do also)
> and once if it's running on an alpha and ALTQ_NOPCC isn't defined.

I'm running on a Geode processor. Maybe the pcc is horked on that processor ?

> 
> My next step is to take one of our broken rule files and validate it
> on an openbsd box to see if it works the same there.

Hmm.

> 
> --Bill
> 
> $ grep -A4 -B2 ALTQ_NOPCC *
> altq_subr.c-    else
> altq_subr.c-            tbr_timer = 0;  /* don't need tbr_timer anymore */
> altq_subr.c:#if defined(__alpha__) && !defined(ALTQ_NOPCC)
> altq_subr.c-    {
> altq_subr.c-            /*
> altq_subr.c-             * XXX read out the machine dependent clock
> once a second
> altq_subr.c-             * to detect counter wrap-around.
> --
> altq_subr.c-            }
> altq_subr.c-    }
> altq_subr.c:#endif /* __alpha__ && !ALTQ_NOPCC */
> altq_subr.c-}
> altq_subr.c-
> altq_subr.c-/*
> altq_subr.c- * get token bucket regulator profile
> --
> altq_subr.c-    machclk_usepcc = 1;
> altq_subr.c-
> altq_subr.c:#if (!defined(__i386__) && !defined(__alpha__)) ||
> defined(ALTQ_NOPCC)
> altq_subr.c-    machclk_usepcc = 0;
> altq_subr.c-#endif
> altq_subr.c-#if defined(__FreeBSD__) && defined(SMP)
> altq_subr.c-    machclk_usepcc = 0;
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD6tZd8It2CaCdeMwRAtluAJ0TknJPfHtPqyKX8Rw3cyft32L3BgCgikiO
9cLbWn96jt0BkTXpMKCJMJ4=
=QXwN
-----END PGP SIGNATURE-----