[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090529195828.GB2753@ami.dom.local>
Date: Fri, 29 May 2009 21:58:28 +0200
From: Jarek Poplawski <jarkao2@...il.com>
To: Stephen Hemminger <shemminger@...tta.com>
Cc: Antonio Almeida <vexwek@...il.com>, netdev@...r.kernel.org,
kaber@...sh.net, davem@...emloft.net, devik@....cz,
Eric Dumazet <dada1@...mosbay.com>,
Vladimir Ivashchenko <hazard@...ncoudi.com>
Subject: Re: [PATCH iproute2] Re: HTB accuracy for high speed
On Fri, May 29, 2009 at 10:28:45AM -0700, Stephen Hemminger wrote:
> On Fri, 29 May 2009 18:02:39 +0100
> Antonio Almeida <vexwek@...il.com> wrote:
>
> > On Thu, May 28, 2009 at 10:12 PM, Jarek Poplawski wrote:
> > > Yes, but according to my assessment there should be "only" 50Mbit
> > > difference for this rate/packet size. Anyway, could you try a testing
> > > patch below, which should add some granularity to this rate table?
> > >
> > > Thanks,
> > > Jarek P.
> > > ---
> > >
> > > include/net/pkt_sched.h | 4 ++--
> > > 1 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h
> > > index e37fe31..f0faf03 100644
> > > --- a/include/net/pkt_sched.h
> > > +++ b/include/net/pkt_sched.h
> > > @@ -42,8 +42,8 @@ typedef u64 psched_time_t;
> > > typedef long psched_tdiff_t;
> > >
> > > /* Avoid doing 64 bit divide by 1000 */
> > > -#define PSCHED_US2NS(x) ((s64)(x) << 10)
> > > -#define PSCHED_NS2US(x) ((x) >> 10)
> > > +#define PSCHED_US2NS(x) ((s64)(x) << 6)
> > > +#define PSCHED_NS2US(x) ((x) >> 6)
> > >
> > > #define PSCHED_TICKS_PER_SEC PSCHED_NS2US(NSEC_PER_SEC)
> > > #define PSCHED_PASTPERFECT 0
> >
> > It's better! This patch gives more accuracy to HTB. Here some values:
> > Note that these are boundary values, so, e.g., any HTB configuration
> > between 377000Kbit and 400000Kbit would fall in the same step - close
> > to 397977Kbit.
> > This test was made over the same conditions: generating 950Mbit/s of
> > unidirectional tcp traffic of 800 bytes packets long.
>
> You really need to get a better box than the dual core AMD.
> There is only millisecond (or worse with HZ=100) resolution possible because
> there is no working TSC on that hardware.
I think this could cause problems with peak rates but IMHO there is
no reason for htb to miss per second (4s) estimations against the same
clock. Plus it mostly confirms theoretical limits of currently used
rate tables vs. usecond time/ticket accounting.
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists