On Mon, Sep 18, 2006 at 11:58:21AM +0200, Andi Kleen wrote:
> > > The x86-64 timer subsystems currently doesn't have clocksources
> > > at all, but it supports TSC and some other timers.
> >
>
> > until I hacked arch/i386/kernel/tsc.c
>
> Then you don't use x86-64.
>
Oh. I mean I made arch/i386/kernel/tsc.c compile on x86-64
by hacking some Makefiles and headers.
But the question is, why stock 2.6.18-rc7 could not use TSC on its own?
> > > > 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's not just electrical power - the hardware is more stressed and will
> likely fail earlier too. As a rule of thumb the hotter your hardware runs
> the earlier it will fail.
What hardware exactly. Doesn't it affect only CPU? And they are not
know to fail before any other components.
> >
> > > > 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?
>
> The problem is not really using a packet socket, but using the SIOCGSTAMP
> ioctl on it. As soon as someone issues it the system will take accurate
> time stamps for each incoming packet until the respective socket is closed.
>
> Quick fix is to change user space to use gettimeofday() when it reads
> the packet instead.
Ok, thank you, I now understand.
>
> For netdev: I'm more and more thinking we should just avoid the problem
> completely and switch to "true end2end" timestamps. This means don't
> time stamp when a packet is received, but only when it is delivered
> to a socket. The timestamp at receiving is a lie anyways because
> the network hardware can add an arbitary long delay before the driver interrupt
> handler runs. Then the problem above would completely disappear.
> Comments? Opinions?
>
> -Andi
>
~
:wq
With best regards,
Vladimir Savkin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
