[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: non-monotonic do_gettimeofday?

On Tuesday 03 September 2002 21.59, Akshay Adhikari wrote:
> hi,
> in kernel 2.4.14, I have noticed that sometimes when the CPU load is
> extremely high, the clock jumps backwards. Here is how it happens: I send
> UDP packets and receive them back from an echoer, much like
> ping. The packets have a user space send timestamp using gettimeofday,
> and _kernel_ space receive timestamps retrieved using the SIOCGSTAMP
> ioctl.
> To get high precision receive timestamps, I have replaced the
> get_fast_time call in netif_rx with the do_gettimeofday call.
> Sometimes, under high load conditions, the kernel receive timestamps are
> smaller than the user receive timestamps.
> Is this the same bug that used to be in 2.4.5? (there was a report of
> this on the mailing list a while back).
Probbaly not the same, but something nearby. Exactly what version of 
linux/arch/cris/kernel/time.c are you using?
(Check the $Id: tag)
If you are using version 1.11 there has been changes after that that
might fix this:
@@ -124,11 +211,11 @@ void do_gettimeofday(struct timeval *tv)
        *tv = xtime;
        tv->tv_usec += do_gettimeoffset();
-       if (tv->tv_usec >= 1000000) {
+       restore_flags(flags);
+       while (tv->tv_usec >= 1000000) {
                tv->tv_usec -= 1000000;
-       restore_flags(flags);

Other changes in newer version is that we use the prescale timer to get
an exact 100Hz clock (otherwise it's 64 ppm to fast, as indicated in the 
datasheet), there might be some wrap problem not properly handled
in the new code, although I haven't had any problems in my tests.

> a related question: do_gettimeofday disables interrupts, right?. does this
> mean
> that we could lose timer interrupts (or any other interrupts) simply by
> calling gettimeofday in a tight loop (and this is a possible reason for
> the non-monotonic timestamps?), or is the timer interrupt non-maskable?

It's not non-maskable, so it might be off, but I dought it's off for that 
long - that would indicate some other problem somewhere.

> TIA,
> akshay