gettimeofday() moving backwards

gettimeofday() moving backwards

[Paul Richards]

Hi,
I am using linux kernel v2.4.20 with ACPI patch dated 2002-12-05.

I have noticed that if my processor changes state (800Mhz up to 1200Mhz say)
then gettimeofday() behaves weirdly.  It runs smoothly but every now and again
(on the order of 10 times a second) it makes a correction.  If I have gone from
800Mhz to 1200Mhz then the correction is backwards, otherwise it makes a forward
jump..

I presume that this is because the kernel hasn't noticed that the cpu state has
changed and hasn't corrected the variables that control how the time is
calculated using the tsc.

Is there a patch for this..?  It doesn't sound like *too* big a thing.. ie just
recalculate a cpl of timing variables when the cpu state changes.. but ofc I
don't know the details :)

-- 
Paul Richards



-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/

RE: gettimeofday() moving backwards

[Grover, Andrew]

> From: Paul Richards [mailto:p.a.richards-Y3tGgqFSo3OFxr2TtlUqVg@public.gmane.org] 
> I am using linux kernel v2.4.20 with ACPI patch dated 2002-12-05.
> 
> I have noticed that if my processor changes state (800Mhz up 
> to 1200Mhz say)
> then gettimeofday() behaves weirdly.  It runs smoothly but 
> every now and again
> (on the order of 10 times a second) it makes a correction.  
> If I have gone from
> 800Mhz to 1200Mhz then the correction is backwards, otherwise 
> it makes a forward
> jump..

Hmm, can you mention this on the cpufreq mailing list?
cpufreq-1walMZg8u8rXmaaqVzeoHQ@public.gmane.org .

Thanks -- Regards -- Andy


-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/

Re: gettimeofday() moving backwards

[Dominik Brodowski]

On Wed, Dec 18, 2002 at 01:23:57PM -0800, Grover, Andrew wrote:
> > From: Paul Richards [mailto:p.a.richards-Y3tGgqFSo3OFxr2TtlUqVg@public.gmane.org] 
> > I am using linux kernel v2.4.20 with ACPI patch dated 2002-12-05.
> > 
> > I have noticed that if my processor changes state (800Mhz up 
> > to 1200Mhz say)
> > then gettimeofday() behaves weirdly.  It runs smoothly but 
> > every now and again
> > (on the order of 10 times a second) it makes a correction.  
> > If I have gone from
> > 800Mhz to 1200Mhz then the correction is backwards, otherwise 
> > it makes a forward
> > jump..
> 
> Hmm, can you mention this on the cpufreq mailing list?
> cpufreq-1walMZg8u8rXmaaqVzeoHQ@public.gmane.org .

In kernel 2.5.5x, gettimeofday() should work fine: ACPI uses the cpufreq
infrastructure, which adds -among other things- a hunk in
arch/i386/timer/tsc.c which updates some values on frequency transitions.
(see http://www.brodo.de/cpufreq/ for details on cpufreq).

As cpufreq isn't included in 2.4. kernels, and likely never will, the 2.4.
gettimeofday() call does cause strange results in 2.4.

	Dominik




-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/

Re: gettimeofday() moving backwards

[Pavel Machek]

Hi!

> I am using linux kernel v2.4.20 with ACPI patch dated 2002-12-05.
> 
> I have noticed that if my processor changes state (800Mhz up to 1200Mhz say)
> then gettimeofday() behaves weirdly.  It runs smoothly but every now and again
> (on the order of 10 times a second) it makes a correction.  If I have gone from
> 800Mhz to 1200Mhz then the correction is backwards, otherwise it makes a forward
> jump..
> 
> I presume that this is because the kernel hasn't noticed that the cpu state has
> changed and hasn't corrected the variables that control how the time is
> calculated using the tsc.
> 
> Is there a patch for this..?  It doesn't sound like *too* big a thing.. ie just
> recalculate a cpl of timing variables when the cpu state changes.. but ofc I
> don't know the details :)

Its actually pretty hard to do... Because at least at APM cpu can
change clock any time. And recalibration of delay loop takes quite
long... Still it might be good idea to recalibrate after clock change.

									Pavel
-- 
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?


-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now!  Before the Holidays pass you by.
T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/

Re: gettimeofday() moving backwards

[Herbert Nachtnebel]

In 2.4 there exists CONFIG_ASYNC_TSC to help with such things. 
I never tried it, but it should change the gettimeofday() 
system call to not use the TSC for time calculations. This 
results in a really slow system call since now it uses the PIT
for every access, but the system time should be smoothly again.

Regards, Herbert.

-----Ursprüngliche Nachricht-----
Von: Dominik Brodowski [mailto:linux-JhLEnvuH02M@public.gmane.org]
Gesendet: Mittwoch, 18. Dezember 2002 23:41
An: Grover, Andrew
Cc: 'Paul Richards'; acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
Betreff: Re: [ACPI] gettimeofday() moving backwards


On Wed, Dec 18, 2002 at 01:23:57PM -0800, Grover, Andrew wrote:
> > From: Paul Richards [mailto:p.a.richards-Y3tGgqFSo3OFxr2TtlUqVg@public.gmane.org] 
> > I am using linux kernel v2.4.20 with ACPI patch dated 2002-12-05.
> > 
> > I have noticed that if my processor changes state (800Mhz up 
> > to 1200Mhz say)
> > then gettimeofday() behaves weirdly.  It runs smoothly but 
> > every now and again
> > (on the order of 10 times a second) it makes a correction.  
> > If I have gone from
> > 800Mhz to 1200Mhz then the correction is backwards, otherwise 
> > it makes a forward
> > jump..
> 
> Hmm, can you mention this on the cpufreq mailing list?
> cpufreq-1walMZg8u8rXmaaqVzeoHQ@public.gmane.org .

In kernel 2.5.5x, gettimeofday() should work fine: ACPI uses the cpufreq
infrastructure, which adds -among other things- a hunk in
arch/i386/timer/tsc.c which updates some values on frequency transitions.
(see http://www.brodo.de/cpufreq/ for details on cpufreq).

As cpufreq isn't included in 2.4. kernels, and likely never will, the 2.4.
gettimeofday() call does cause strange results in 2.4.

	Dominik




-------------------------------------------------------
This SF.NET email is sponsored by: Order your Holiday Geek Presents Now!
Green Lasers, Hip Geek T-Shirts, Remote Control Tanks, Caffeinated Soap,
MP3 Players,  XBox Games,  Flying Saucers,  WebCams,  Smart Putty.
T H I N K G E E K . C O M       http://www.thinkgeek.com/sf/
_______________________________________________
Acpi-devel mailing list
Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/acpi-devel


-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now!  Before the Holidays pass you by.
T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/

Re: gettimeofday() moving backwards

[Ducrot Bruno]

On Thu, Dec 19, 2002 at 11:01:22AM +0100, Herbert Nachtnebel wrote:
> In 2.4 there exists CONFIG_ASYNC_TSC to help with such things. 

Warn.  Some libc are broken, and will hang.  Be sure to update.
And mplayer when using win32 dll will segfault, also..

> I never tried it, but it should change the gettimeofday() 
> system call to not use the TSC for time calculations. This 
> results in a really slow system call since now it uses the PIT
> for every access, but the system time should be smoothly again.

ACPI timer could help, I guess.


-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This SF.NET email is sponsored by: Geek Gift Procrastinating?
Get the perfect geek gift now!  Before the Holidays pass you by.
T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/