From: Thomas Graf <tgraf@suug.ch>
To: jamal <hadi@cyberus.ca>
Cc: "David S. Miller" <davem@davemloft.net>, netdev@oss.sgi.com
Subject: Re: [PATCH 2/3] NET: Generic rate estimator
Date: Mon, 4 Oct 2004 17:29:15 +0200 [thread overview]
Message-ID: <20041004152915.GC15898@postel.suug.ch> (raw)
In-Reply-To: <1096901984.1073.9.camel@jzny.localdomain>
* jamal <1096901984.1073.9.camel@jzny.localdomain> 2004-10-04 10:59
> is that bad to let those have a slight different innacurate value?
I don't see this as a problem, I think the timers will be more
inacurate anyway.
> BTW wasnt there a jiffies2ms converter somewhere that we could use?
> I thought i saw something posted of that nature recently.
#define PSCHED_US2JIFFIE(delay)
#define PSCHED_JIFFIE2US(delay)
but we don't have half a jiffie ;) The only way to make it accurate in
the case of 122 and 50 would be to set timer_expires based on a flip-flop
adding HZ/4 and (HZ/4)+1 repeaditly and this only works if HZ%2==0.
I would be fine using PSCHED_ because the user can decide accuracy
over performance and vice versa. It would make the code dependant on
sch_api.c though.
> There should really be no difference between the two;-> you realize /4
> is merely <<2 ?
Oh yes there is: HZ=50, idx=2
(HZ/4)<<idx:
octave:8> 50/4
ans = 12.500
octave:9> dec2bin(12)
ans = 1100
octave:10> bin2dec('110000')
ans = 48
(HZ<<idx)/4:
octave:11> dec2bin(50)
ans = 110010
octave:12> bin2dec('11001000')
ans = 200
octave:13> 200/4
ans = 50
It avoids carrying on the inaccuracy, of course this only works because
(2*HZ)%4==0 is true for all existing HZ values. Or do I misundstand the
compiler and it's all in floating points?
next prev parent reply other threads:[~2004-10-04 15:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-03 21:31 [PATCH 0/3] NET: Generic network statistics/estimator Thomas Graf
2004-10-03 21:34 ` [PATCH 1/3] NET: Generic network statistics API Thomas Graf
2004-10-03 21:39 ` [PATCH 2/3] NET: Generic rate estimator Thomas Graf
2004-10-03 23:14 ` David S. Miller
2004-10-03 23:36 ` Thomas Graf
2004-10-04 1:16 ` jamal
2004-10-04 12:53 ` Thomas Graf
2004-10-04 13:24 ` jamal
2004-10-04 14:15 ` Thomas Graf
2004-10-04 14:59 ` jamal
2004-10-04 15:29 ` Thomas Graf [this message]
2004-10-04 19:30 ` [RESEND PATCH " Thomas Graf
2004-10-04 20:07 ` jamal
2004-10-04 20:20 ` Thomas Graf
2004-10-03 23:57 ` [PATCH " Thomas Graf
2004-10-05 21:03 ` David S. Miller
2004-10-05 22:21 ` [RFC] Replacing qdisc tc_stats with generic statistics to make it extendable Thomas Graf
2004-10-06 17:41 ` David S. Miller
2004-10-03 21:41 ` [PATCH 3/3] NET: Generic network statistics/estimator documentation Thomas Graf
2004-10-03 21:47 ` [PATCH 0/3] NET: Generic network statistics/estimator Thomas Graf
2004-10-03 22:23 ` David S. Miller
2004-10-03 22:34 ` jamal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041004152915.GC15898@postel.suug.ch \
--to=tgraf@suug.ch \
--cc=davem@davemloft.net \
--cc=hadi@cyberus.ca \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.