Re: Dual Xeon Time skips with 2.6

Re: Dual Xeon Time skips with 2.6

[Robert Hancock]

Cornelius Thiele wrote:
> Hello,
> 
> we have a dual xeon 3,0ghz system with hyperthreading running here with 
> kernel 2.6.13 / 2.6.12 and are experiencing time skips. Meaning, when 
> you enter 'date' in the shell the result will be different depending on 
> which cpu the command is scheduled. The longer the system is up the 
> greater the difference. The increase is approximately 5 minutes per day; 
> as you can probably imagine this adds up to quite a lot over weeks and 
> screws up our logging and any other program that needs timing or writes 
> timestamp to disk somewhere.
> 
> $> / # dmesg | grep time
> time.c: Using 3.579545 MHz PM timer.
> time.c: Detected 3000.236 MHz processor.
> Using local APIC timer interrupts.
> Detected 12.500 MHz APIC timer.
> time.c: Using PIT/TSC based timekeeping.
> 
> [ ... w/o bogomips and pci timing... ]
> 
> The CPUs seem to be put in sync only at system startup:
> 
> dmesg | grep TSC
> CPU 1: Syncing TSC to CPU 0.
> CPU 1: synchronized TSC with CPU 0 (last diff 142 cycles, maxerr 1267 
> cycles)
> [... for CPU1-4 ...]
> 
> but they drift apart quite heavily after that.
> 
> The server runs on a Tyan Mainboard, I'd be happy to provide any more 
> infos if needed or try out some things, because we really need to have a 
> server with only _one_ system time :)

You can probably avoid this problem by using "notsc" on the kernel 
command line. It would seem that somehow the TSC drift is too small for 
the kernel to notice on boot, but causes problems anyway..

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Re: Dual Xeon Time skips with 2.6

[Cornelius Thiele]

Robert Hancock wrote:
  > You can probably avoid this problem by using "notsc" on the kernel
> command line. It would seem that somehow the TSC drift is too small for 
> the kernel to notice on boot, but causes problems anyway..

Thanks very much, that fixed it.

Greetings,
	Cornelius Thiele

Re: Dual Xeon Time skips with 2.6

[Bill Davidsen]

Robert Hancock wrote:

> You can probably avoid this problem by using "notsc" on the kernel 
> command line. It would seem that somehow the TSC drift is too small for 
> the kernel to notice on boot, but causes problems anyway..
> 
This sounds familiar, although much larger than what I see, is it 
possible for an Intel dual core CPU to do this as well? I sometimes see 
very unintuitive timestamps on network stuff.
-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: Dual Xeon Time skips with 2.6

[Robert Hancock]

Bill Davidsen wrote:
> This sounds familiar, although much larger than what I see, is it 
> possible for an Intel dual core CPU to do this as well? I sometimes see 
> very unintuitive timestamps on network stuff.

As far as I know that shouldn't happen.. though people thought the same 
thing with AMD dual core CPUs and it turns out the TSCs can apparently 
drift, I believe this was recently changed.

Can you verify whether or not this sort of time skew is actually happening?

-- 
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/

Dual Xeon Time skips with 2.6

[Cornelius Thiele]

Hello,

we have a dual xeon 3,0ghz system with hyperthreading running here with 
kernel 2.6.13 / 2.6.12 and are experiencing time skips. Meaning, when 
you enter 'date' in the shell the result will be different depending on 
which cpu the command is scheduled. The longer the system is up the 
greater the difference. The increase is approximately 5 minutes per day; 
as you can probably imagine this adds up to quite a lot over weeks and 
screws up our logging and any other program that needs timing or writes 
timestamp to disk somewhere.

$> / # dmesg | grep time
time.c: Using 3.579545 MHz PM timer.
time.c: Detected 3000.236 MHz processor.
Using local APIC timer interrupts.
Detected 12.500 MHz APIC timer.
time.c: Using PIT/TSC based timekeeping.

[ ... w/o bogomips and pci timing... ]

The CPUs seem to be put in sync only at system startup:

dmesg | grep TSC
CPU 1: Syncing TSC to CPU 0.
CPU 1: synchronized TSC with CPU 0 (last diff 142 cycles, maxerr 1267 
cycles)
[... for CPU1-4 ...]

but they drift apart quite heavily after that.

The server runs on a Tyan Mainboard, I'd be happy to provide any more 
infos if needed or try out some things, because we really need to have a 
server with only _one_ system time :)

Greetings,
	Cornelius Thiele