ong with your patch, Mike.
>
>
>
> On Mon, 5/15/17, Mike Belopuhov wrote:
>
> Subject: Re: pf queue definition: bandwidth resolution problem
> To: "Carl Mascott"
> Cc: "Theo Buehler" , tech@openbsd.org
> Date: Monday, May 15, 2
Subject: Re: pf queue definition: bandwidth resolution problem
To: "Carl Mascott"
Cc: "Theo Buehler" , tech@openbsd.org
Date: Monday, May 15, 2017, 3:28 PM
On Sun, May 14, 2017 at 21:08 +, Carl
Mascott wrote:
> OK, I was indeed missing
something. Thanks, Th
On Mon, May 15, 2017 at 09:28:57PM +0200, Mike Belopuhov wrote:
> On Sun, May 14, 2017 at 21:08 +, Carl Mascott wrote:
> > OK, I was indeed missing something. Thanks, Theo and Mike.
> >
> > I think I see another very minor problem, though.
> > Let the pf BW be 9,999,999.
> > Shift right 3 digi
e right, initially I had a "<= " there but then I got
sidetracked with a hypothetical problem that right now seems
like my imagination. I've double checked numbers and indeed,
it should be "if (rtmp <= )".
>
> --------
this, presumably to avoid overflow to 10,000 (5 digits).
However, since (i < 3) it could have been rounded and scaled again, to 10M.
Slightly more accurate but not a big deal.
On Sun, 5/14/17, Theo Buehler wrote:
Subject: Re: pf queue definition: b
on Tuesday.
>
> Yes, I understand that systat can display only 4 digits for BW.
> That's 5 digits with my guard digit, which is shifted out (and not displayed)
> at the end.
> So, with the guard digit, 6 digits is too many.
>
>
> ----------
On Sun, May 14, 2017 at 08:29:18PM +, Carl Mascott wrote:
> It looks to me like you are rounding on each iteration of the for-loop:
>
> +for (i = 0; rate > && i <= 3; i++) {
> +rtmp = rate / 1000;
> +if (rtmp < )
This is only true in the last iteration.
> +
4/17, Mike Belopuhov wrote:
Subject: Re: pf queue definition: bandwidth resolution problem
To: "Carl Mascott"
Cc: tech@openbsd.org, t...@openbsd.org
Date: Sunday, May 14, 2017, 4:05 PM
On Sun, May 14, 2017 at 19:48 +, Carl
Mascott wrote:
> I have a suggestion RE
your pftop
On Sun, May 14, 2017 at 19:48 +, Carl Mascott wrote:
> I have a suggestion RE your pftop.c patch. You are rounding
> multiple times, after each scale operation. This is known as
> rounding the intermediate results of a calculation and degrades
> accuracy. If you're not familiar with the issu
------------
> On Sat, 5/13/17, Carl Mascott
wrote:
>
> Subject:
Re: pf queue definition: bandwidth resolution problem
> To: "Mike Belopuhov"
> Cc: m...@openbsd.org
> Date: Saturday, May 13, 2017, 4:55 PM
>
&g
On Sun, May 14, 2017 at 02:02:39AM +0200, Mike Belopuhov wrote:
> Good call. This one is a bit more complicated since we have 5 positions
> to display and the last one is sort of reserved for the unit specifier.
>
> So ignoring the unit we can display numbers from 1 to .
> However, when trunc
iodically,
> but if that's not the case then the same fix is needed in systat.
>
>
>
> --------
> On Sat, 5/13/17, Carl Mascott wrote:
>
> Subject: Re: pf queue definition: bandwidth resolution problem
> To: "Mike Belopu
--
On Sat, 5/13/17, Carl Mascott wrote:
Subject: Re: pf queue definition: bandwidth resolution problem
To: "Mike Belopuhov"
Cc: m...@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 b
y 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 wrote:
Subject: Re: pf queue definition: bandwidth resolution problem
To
> or ~1M.
>
> When I have time I'll do a simple test.
>
>
>
>
> On Sat, 5/13/17, Mike Belopuhov wrote:
>
> Subject: Re: pf queue definition: bandwidth resolution problem
> To: "Carl Mascott"
> Cc: m
15 matches
Mail list logo
