Re: Network performance degradation from 2.6.11.12 to 2.6.16.20

["Vladimir B. Savkin" <master@sectorb.msk.ru>]

On Mon, Sep 18, 2006 at 10:35:38AM +0200, Andi Kleen wrote:
> > I just found out that TSC clocksource is not implemented on x86-64.
> > Kernel version 2.6.18-rc7, is it true?
> 
> The x86-64 timer subsystems currently doesn't have clocksources
> at all, but it supports TSC and some other timers.

Hm. On my box, TSC did not work, until I hacked arch/i386/kernel/tsc.c
in it. 
Neither clock=tsc nor clocksource=tsc didn't have any effect.

> > I've also had experience of unsychronized TSC on dual-core Athlon,
> > but it was cured by idle=poll.
> 
> You can use that, but it will make your system run quite hot 
> and cost you a lot of powe^wmoney.

Here in Russia electric power is cheap compared with hardware upgrade.

> > 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?
> 
> Yes.  Good point. DHCP is broken and needs to be fixed. Can you
> send a bug report to the DHCP maintainers? 
> 
> iirc the problem used to be that RAW sockets didn't do something
> they need them to do. Maybe we can fix that now.

Will try some days later.

Oh, and pppoe-server uses some kind of packet socket too, doesn't it?

> 
> If that's not possible we can probably add a ioctl or similar
> to disable time stamping for packet sockets (DHCP shouldn't really
> need a fine grained time stamp). dhcpcd would need to use that then.

I would like some sysctl very much, too. Let tcpdump show imprecise
timestamps when forwarding performance is more important.
After all, Ciscos don't have any tcpdump analog at all, and they are 
very popular :)

> 
> Keep me updated what they say.
> 
> -Andi
> 
~
:wq
                                        With best regards, 
                                           Vladimir Savkin.