System time slowdown after upgrading from 2.4 to 2.6

System time slowdown after upgrading from 2.4 to 2.6

[Ivan Kalatchev]

Hi all,

We have a project that uses PC-104 (ZFx86 100 MHz CPU) Linux box to acquire
some seismological signals. System resides on a M-Systems DiskOnChip 2000.
We have an ISA acquisition card that acquires data into FIFO buffer and
triggers interrupt as soon as 341 points were acquired (then this data is
read out in interrupt handler routine). System worked perfectly well when we
used 2.4.18 kernel. When I printk-ed system time (do_gettimeofday)  in
interrupt routine, at 1kHz sampling frequency interrupts were reported every
341 msec as they should do.
But after I've switched to 2.6 kernel (2.6.7 - preempted, then I tried
2.6.8 - non-preempted) time between successive interrupts at 1kHz became 335
msec, losing 6 msec at each interrupt. What is interesting, when sampling
frequency is 10 kHz, with 2.4.18 kernel interrupts are reported every 34
msec, which is right, but with 2.6 kernels interrupts are coming at 28 msec
interval, again losing same 6 msec!

Any ideas why this might happen?

Please, CC me all answers/comments posted to the list in response to this
posting.
Regards,

Ivan Kalatchev

Senior Software Developer
Engineering Seismology Group Canada Inc.
ISO 9001-2000
1 Hyperion Court, Kingston,
Ontarion, Canada K7K 7G3
phone: (613) 548-8287 ext.247
fax:     (613) 548-8917

Re: System time slowdown after upgrading from 2.4 to 2.6

[john stultz]

On Thu, 2004-08-19 at 12:42, Ivan Kalatchev wrote:
> We have a project that uses PC-104 (ZFx86 100 MHz CPU) Linux box to acquire
> some seismological signals. System resides on a M-Systems DiskOnChip 2000.
> We have an ISA acquisition card that acquires data into FIFO buffer and
> triggers interrupt as soon as 341 points were acquired (then this data is
> read out in interrupt handler routine). System worked perfectly well when we
> used 2.4.18 kernel. When I printk-ed system time (do_gettimeofday)  in
> interrupt routine, at 1kHz sampling frequency interrupts were reported every
> 341 msec as they should do.
> But after I've switched to 2.6 kernel (2.6.7 - preempted, then I tried
> 2.6.8 - non-preempted) time between successive interrupts at 1kHz became 335
> msec, losing 6 msec at each interrupt. What is interesting, when sampling
> frequency is 10 kHz, with 2.4.18 kernel interrupts are reported every 34
> msec, which is right, but with 2.6 kernels interrupts are coming at 28 msec
> interval, again losing same 6 msec!
> 
> Any ideas why this might happen?

Hmm. Strange. Just to remove some variables, are you running NTP on the
system? Could you also send your 2.6 dmesg?

thanks
-john

Re: System time slowdown after upgrading from 2.4 to 2.6

[Tim Schmielau]

On Thu, 19 Aug 2004, Ivan Kalatchev wrote:
> We have a project that uses PC-104 (ZFx86 100 MHz CPU) Linux box to acquire
> some seismological signals. System resides on a M-Systems DiskOnChip 2000.
> We have an ISA acquisition card that acquires data into FIFO buffer and
> triggers interrupt as soon as 341 points were acquired (then this data is
> read out in interrupt handler routine). System worked perfectly well when we
> used 2.4.18 kernel. When I printk-ed system time (do_gettimeofday)  in
> interrupt routine, at 1kHz sampling frequency interrupts were reported every
> 341 msec as they should do.
> But after I've switched to 2.6 kernel (2.6.7 - preempted, then I tried
> 2.6.8 - non-preempted) time between successive interrupts at 1kHz became 335
> msec, losing 6 msec at each interrupt. What is interesting, when sampling
> frequency is 10 kHz, with 2.4.18 kernel interrupts are reported every 34
> msec, which is right, but with 2.6 kernels interrupts are coming at 28 msec
> interval, again losing same 6 msec!

How long does the interrupt handler take to read the data? You might lose
timer interrupts during data readout. Timer interrupts in 2.6 are 10 times 
as frequent as in 2.4
Try changing
  # define HZ   1000
back to
  # define HZ    100
in include/asm-i386/param.h. If that helps, just leave it that way.

Tim