[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060916120845.GA18912@tentacle.sectorb.msk.ru>
Date: Sat, 16 Sep 2006 16:08:46 +0400
From: "Vladimir B. Savkin" <master@...torb.msk.ru>
To: Andi Kleen <ak@...e.de>
Cc: Jesper Dangaard Brouer <hawk@...u.dk>,
Harry Edmon <harry@...os.washington.edu>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: Network performance degradation from 2.6.11.12 to 2.6.16.20
On Mon, Jun 19, 2006 at 05:24:31PM +0200, Andi Kleen wrote:
>
> > If you use "pmtmr" try to reboot with kernel option "clock=tsc".
>
> That's dangerous advice - when the system choses not to use
> TSC it often has a reason.
I just found out that TSC clocksource is not implemented on x86-64.
Kernel version 2.6.18-rc7, is it true?
I've also had experience of unsychronized TSC on dual-core Athlon,
but it was cured by idle=poll.
>
> >
> > On my Opteron AMD system i normally can route 400 kpps, but with
> > timesource "pmtmr" i could only route around 83 kpps. (I found the timer
> > to be the issue by using oprofile).
>
> Unless you're using packet sniffing or any other application
> that requests time stamps on a socket then the timer shouldn't
> make much difference. Incoming packets are only time stamped
> when someone asks for the timestamps.
>
It seems that dhcpd3 makes the box timestamping incoming packets,
killing the performance. I think that combining router and DHCP server
on a same box is a legitimate situation, isn't it?
~
:wq
With best regards,
Vladimir Savkin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists