One more thing:
The BW column of "systat queues" has the same truncation error.
I'm guessing that "systat queues" is running "pfctl -vsqueue" periodically, but
if that's not the case then the same fix is needed in systat.
--------------------------------------------
On Sat, 5/13/17, Carl Mascott <cmasc...@yahoo.com> wrote:
Subject: Re: pf queue definition: bandwidth resolution problem
To: "Mike Belopuhov" <m...@belopuhov.com>
Cc: misc@openbsd.org
Date: Saturday, May 13, 2017, 4:55 PM
I forgot to ask: How will I know when there's
a snapshot with a fixed pfctl binary?
Any problem with dropping the new pfctl
binary into my 6.1-stable (i386) system?
P.S. I'm new to OpenBSD.
--------------------------------------------
On Sat, 5/13/17, Carl Mascott <cmasc...@yahoo.com>
wrote:
Subject: Re: pf queue definition:
bandwidth resolution problem
To: "Mike Belopuhov" <m...@belopuhov.com>
Cc: misc@openbsd.org,
t...@openbsd.org
Date: Saturday, May 13, 2017, 4:21 PM
First, just to be safe, I did a
bandwidth
test with only one queue, max
bandwidth 1999K.
pf is fine: measured speed was about
2M.
Just eyeballing it, I don't see
anything wrong with your patch, but I
have no way to test
it: I'm not set up to build from
source.
If I understand correctly you have
already tested it.
In that case, I guess it's OK to
commit
it (or however the process works..).
Gee, this was easy. Thanks!
--------------------------------------------
On Sat, 5/13/17, Mike Belopuhov <m...@belopuhov.com>
wrote:
Subject: Re: pf queue
definition:
bandwidth resolution problem
To: "Carl Mascott" <cmasc...@yahoo.com>
Cc: misc@openbsd.org,
t...@openbsd.org
Date: Saturday, May 13, 2017,
3:23 PM
Ah, I see what you mean.
Indeed, we
have to
make sure the remainder
is 0 when we're
displaying the bandwidth. I
think
the diff below is
what we want. Works fine here,
any
OKs?
On Sat, May 13, 2017 at 18:34
+0000,
Carl
Mascott wrote:
> You missed the point. I
didn't do any testing. I just
looked
at the output of
"pfctl -squeue" (correction: In
the
original post
I wrote "pfctl -srules") and
noticed
that the
assigned queue bandwidths
reported by
pfctl were in some
cases much different than the
specified queue bandwidth
parameters in pf.conf. To put
it
another way, the readback
of defined bandwidth does not
match
the definition.
>
> From observation it
looks like specified bandwidths
in
pf.conf with 4 or more
digits followed by 'K' have the
3
LSD's dropped
and 'K' changed to 'M' in the
output
of
"pfctl -squeue." Example: 1800K
in
pf.conf becomes
1M in the output of "pfctl
-squeue" --
a very
significant difference.
>
> It remains to be
determined
whether the
fault is in the setting of
bandwidth
by pf or in the
reporting of bandwidth by
pfctl.
Actual tests with a simple
queue, as you suggested, could
determine whether pf is
enforcing the correct bandwidth
values. To make it easiest
to see an error the optimum leaf
queue
max bandwidth to use
is 1999K. Then see whether the
measured bandwidth is ~2M or
~1M.
>
> When I have
time I'll do a simple test.
>
>
>
>
--------------------------------------------
> On Sat, 5/13/17, Mike
Belopuhov
<m...@belopuhov.com>
wrote:
>
> Subject:
Re: pf queue definition:
bandwidth
resolution problem
> To: "Carl Mascott" <cmasc...@yahoo.com>
> Cc: misc@openbsd.org
> Date: Saturday, May 13,
2017,
12:02
PM
>
> On Tue,
May 09, 2017 at 19:47 +0000,
Carl
>
Mascott wrote:
> > Intel Atom
D2500
> 1.66GHz
>
> OpenBSD i386 v6.1-stable
> >
> > I can't get pf
> to give me the queue
bandwidths
that I
specify in
> pf.conf.
> >
> >
> pf.conf:
> >
> > queue
> rootq
on $ext_if bandwidth 9M max 9M
qlimit
100
> > queue
qdef
parent
rootq
> bandwidth 3650K default
> >
>
queue qrtp parent rootq
bandwidth 350K
min 350K burst
700K
> for 200ms
>
> queue qweb
parent
>
rootq bandwidth 4M
> >
queue
> qpri parent rootq
bandwidth
900K min 50K burst 1800K for
> 200ms
> > queue
qdns
parent
> rootq bandwidth 100K min
10K
burst 200K
for 1000ms
> >
> > output of pfctl
> -srules:
> >
> > queue
> rootq
on bge0 bandwidth 9M, max 9M
qlimit
100
> > queue qdef parent
rootq
bandwidth
3M
> default qlimit 50
> > queue qrtp parent
> rootq bandwidth 350K, min
350K
burst
700K for 200ms qlimit
> 50
> > queue qweb parent
rootq
bandwidth
4M
> qlimit 50
>
> queue qpri parent rootq
>
bandwidth 900K, min 50K burst 1M
for
200ms qlimit 50
> > queue qdns parent
rootq
bandwidth
100K,
> min 10K burst 200K for
1000ms
qlimit 50
> >
>
> > Discrepancies in
the
above:
> >
> >
> defined
actual
> >
>
----------
---------
> > qdef BW 3650K
3M
> > qpri burst
1800K
1M
> >
> > It looks like for
> anything specified as
abcdK the
result
is aM, i.e., for any
> bandwidth >=
1000K the resulting bandwidth
is
>
truncated (not rounded) to
<msd>M, where
> <msd> = most
significant
digit.
Any bandwidth
> < 1000K works
correctly.
> >
> > Is this a bug, a
misfeature, or
a
> feature?
>
> Thanks!
> >
>
Index:
sbin/pfctl/pfctl_parser.c
===================================================================
RCS file:
/home/cvs/src/sbin/pfctl/pfctl_parser.c,v
retrieving revision 1.309
diff
-u -p -r1.309 pfctl_parser.c
---
sbin/pfctl/pfctl_parser.c
26 Oct
2016 14:15:59
-0000 1.309
+++
sbin/pfctl/pfctl_parser.c
13 May
2017 19:18:19
-0000
@@ -1177,7 +1177,7 @@
print_bwspec(const char
*prefix,
struct
printf("%s%u%%",
prefix,
bw->percent);
else if
(bw->absolute) {
rate =
bw->absolute;
- for (i = 0;
rate >= 1000 && i
<= 3;
i++)
+ for (i = 0; rate
>=
1000
&& i <= 3 &&
(rate
% 1000 == 0); i++)
rate /=
1000;
printf("%s%u%c",
prefix, rate, unit[i]);
}
