Page 1 of 3 123 LastLast
Results 1 to 10 of 23

Thread: Inconsistency in time(NULL)

  1. #1
    Join Date
    Aug 2008
    Beans
    31

    Inconsistency in time(NULL)

    (Hardy Heron (8.04) running on i386 platform,
    fully updated as of 5/23/09
    libc.a timestamp = 2906374 2008-09-12 10:33)

    Help. I'm frustrated. I'm getting inconsistent results from the time() function in an ordinary c program. Program...

    Code:
    /* ttime.c */
    #include <stdlib.h>
    #include <stdio.h>
    #include <time.h>
    #include <sys/time.h>
    
    int main() {
      time_t tt, tt2;
      struct timeval tv;
      struct timezone tz;
      for (;;) {
        for (;;) {
          tt2 = time(NULL);
          if (tt != tt2) {
            tt = tt2;
            gettimeofday(&tv, &tz);
            break;
          }
        }
        printf("%10d %6d %s", tv.tv_sec, tv.tv_usec, asctime(localtime(&tt))); 
      }
    }
    I'm expecting one line of output every one second, because I detect when time() changes. Problem is that I get multiple lines, at random times, with the same time() value. Sometimes, asctime() will actually go backwards and then forward.

    (I added the call to gettimeofday() to try to get a handle on what was going on.) Typical output...

    1243116146 343 Sat May 23 18:02:26 2009
    1243116146 66844 Sat May 23 18:02:25 2009
    1243116146 66855 Sat May 23 18:02:26 2009
    1243116146 90870 Sat May 23 18:02:25 2009
    1243116146 90879 Sat May 23 18:02:26 2009
    1243116146 124106 Sat May 23 18:02:25 2009
    1243116146 124116 Sat May 23 18:02:26 2009
    1243116146 135259 Sat May 23 18:02:25 2009
    1243116146 135270 Sat May 23 18:02:26 2009
    1243116147 342 Sat May 23 18:02:27 2009
    1243116147 191585 Sat May 23 18:02:26 2009
    1243116147 191593 Sat May 23 18:02:27 2009
    1243116148 342 Sat May 23 18:02:28 2009
    1243116149 342 Sat May 23 18:02:29 2009
    1243116149 190849 Sat May 23 18:02:28 2009
    1243116149 190859 Sat May 23 18:02:29 2009
    1243116149 250847 Sat May 23 18:02:28 2009
    1243116149 250856 Sat May 23 18:02:29 2009

    Where each line with the same time() value is printed at the same time.

    In the original (larger) program, the core issue was the snippet...

    Code:
      for (;;) {
        while (tt==time(NULL)); // wait until next second - burn CPU time
        tt = time(NULL);        // update last value
        // do something once per second
      }
    This alternate program works perfectly...

    Code:
    /* ttime2.c */
    #include <stdlib.h>
    #include <stdio.h>
    #include <time.h>
    #include <sys/time.h>
    
    int main() {
      time_t tt;
      struct timeval tv;
      struct timezone tz;
      for (;;) {
        for (;;) {
          gettimeofday(&tv, &tz);
          if (tv.tv_sec != tt) {
            tt = tv.tv_sec;
            break;
          }
        } 
        printf("%10d %6d %s", tv.tv_sec, tv.tv_usec, asctime(localtime(&tt))); 
      }
    }
    Output...
    1243116363 241413 Sat May 23 18:06:03 2009
    1243116364 0 Sat May 23 18:06:04 2009
    1243116365 0 Sat May 23 18:06:05 2009
    1243116366 0 Sat May 23 18:06:06 2009
    1243116367 0 Sat May 23 18:06:07 2009
    1243116368 0 Sat May 23 18:06:08 2009
    1243116369 0 Sat May 23 18:06:09 2009
    1243116370 0 Sat May 23 18:06:10 2009
    1243116371 0 Sat May 23 18:06:11 2009
    1243116372 0 Sat May 23 18:06:12 2009

    What bothers me is that, behind the scenes, time() and gettimeofday() should have the same behavior for the integer part, and worse, the program depends on a time_t changing - which it appears to not - yet the program detects that and outputs a line.

    I thought time_t was defined as an arithmetic type representing the number of seconds since the epoch. That sounds integral to me.

    Even more interesting is that I get stable results on other systems. Even more and more interesting is that in the actual (larger) program that I incorporating this into, I get different results when I move things around. That sounds like memory damage or uninitialized memory, but I can't find it.

    Is there something wrong with my system, or with my implementation?

    I have been over this for several weeks now, and I just can't see it.

    Thanks for very much.
    Alex
    Last edited by asbuntu; May 24th, 2009 at 12:00 AM. Reason: fix code display with Code tags

  2. #2
    Join Date
    Aug 2008
    Beans
    31

    Re: Inconsistency in time(NULL)

    FYI - In case anyone wonders why I don't just use the working alternate, its because I'm bothered by what looks like strange behavior in time(NULL) or (more probably) a bug in my own code.

  3. #3
    Join Date
    Sep 2006
    Beans
    11

    Re: Inconsistency in time(NULL)

    If I remember correctly there are some optimisations in the kernel for time(NULL), so is doesn't always look at the clock but rather uses some estimative calculation that returns value close to true clock second but is much faster then looking for the exact real time.
    And time has code so it reads the real time in between to correct it self.

    So what probably happens is that this estimate value is returned some of the times and the real value some times with might leave you with estimated switching sec before the real time and then getting corrected causing multiple printouts.

  4. #4
    Join Date
    Aug 2008
    Beans
    31

    Re: Inconsistency in time(NULL)

    I thought about that as well, but the inconsistency of the inconsistent results made me change my mind.

    Originally this was to have been a simple demo showing the difference in performance between different platforms, such as virtual vs real. The core loop, `while (tt == time(NULL)));` would have contained some code, a counter at its simplest, that I would report once each second. The original version was ..

    Code:
    #include <stdlib.h>
    #include <stdio.h>
    #include <time.h>
    #include <sys/time.h>
    
    int main() {
      time_t tt; 
      int loops;
      for (;;) {
        for (loops=0, tt=time(NULL); tt==time(NULL); loops++);
      printf("%d %s", loops, asctime(localtime(&tt)));
      }
    }
    Now the problem has evolved into finding out why the platform, compiler, library or program is not doing what I expected.

    The idea of internal optimizations is interesting, but does that explain how asctime() is returning results that appear to jump backwards in time?

    The core concern, however, is that i break out of my inner loop when the time_t value of time(NULL) changes. It changes, I break out of the loop, but then I break out of the loop again and again without time_t changing, and that is mystifying me? Thanks.

    Alex

  5. #5
    Join Date
    Aug 2008
    Beans
    31

    Re: Inconsistency in time(NULL) - gcc global optimizations ??

    I was talking to a friend, who is a main-stream physicist working with supercomputers. He said something about "global optimizations" in gcc that might account for the behavior I'm experiencing. I'm not quite sure I agree, because one of the steps I used was to make sure all optimizations were turned off.

    To make matters worse, the program is not acting up right now, and I certainly did not recompile it. Odd???

    Anyway, does anyone know about this topic of "global optimizations" with gcc, or have any insight into the problem at hand? What about the possibility of a kernel bug that got fixed when I updated the system? Thank you.

  6. #6
    Join Date
    Aug 2007
    Beans
    949

    Re: Inconsistency in time(NULL)

    Maybe you should turn optimizations off (gcc -O0, that's "minus oh zero"), and see if that helps.

    And look into these functions:
    http://linux.die.net/man/3/clock_gettime

    Which may not do the so-called "optimizations" which are screwing you up.

  7. #7
    Join Date
    Aug 2008
    Beans
    31

    Re: Inconsistency in time(NULL)

    Quote Originally Posted by soltanis View Post
    Maybe you should turn optimizations off (gcc -O0, that's "minus oh zero"), and see if that helps.
    Been there. Done that. No help.

    And look into these functions:
    http://linux.die.net/man/3/clock_gettime

    Which may not do the so-called "optimizations" which are screwing you up.
    Problem there is that time_t time(&time_t) is a very well defined base library function that should work exactly the same everywhere.

    Yes, I can solve (and have solved) this issue using other calls, such as GetSystemTime, but the real issue is that I'm trying to find out why a basic system call is operating inconsistently.

    I am not so egotistic that I consider that my code to be perfect. Far from it. I have done what I think is a reasonable job of looking at all the possibilities. I even treated the time_t value as opaque, as it should be, and did not attempt to do anything with it, not even comparison, without using defined conversion routines. I broke out each of the steps in the primary loop into single action steps, thinking I had a sequence problem. Nothing helped.

    One poster noted that the OS might be rounding things. Well, if that's true, I would still expect consistent results. The case where the result went backwards and then forward was most mystifying, as is the primary issue where I break out of the primary loops multiple times with the same value.

    The biggest hint of something odd is that, in my original program, if I move things around, the results change. That is a classic sign that something is not being initialized or that something is overrunning memory, but I just can not seem to find it.

    Right now I have two systems that seem to work and one that does not.

    My reason for pushing on this is that I consider the most likely explanation to be that I did something wrong, and if a find a "solution" that masks the issue, then I run the risk of having the problem pop up at the worst possible time, such as during the execution of a production, mission critical process.

    Thank you. Is this compiler? OS? Me? Any other ideas?

  8. #8
    Join Date
    Aug 2007
    Beans
    949

    Re: Inconsistency in time(NULL)

    It is probably the system in this case. Though it is true that all systems have to reasonably implement the time() call, there is a lot of flexibility in the accuracy of the time (indeed, ANSI C warns that the resolution of time() may vary from system to system). It's likely that Linux devs, thinking (perhaps not incorrectly) that time() is only used for timestamping files/packets and that other functions will be used for time-critical tasks, implemented this shortcut.

    You're just going to have to use a different function in this case. If you are that concerned about portability, wrap the OS-dependent call in an inline function and change just that function when you port to a different system.

    Have you tried lint or valgrind against your code? I assume you've already run the compiler with all warnings turned on and it didn't tell you anything.

  9. #9
    Join Date
    Aug 2008
    Beans
    31

    Re: Inconsistency in time(NULL)

    Quote Originally Posted by soltanis View Post
    You're just going to have to use a different function in this case. If you are that concerned about portability, wrap the OS-dependent call in an inline function and change just that function when you port to a different system.
    I thought time_t time(&time_t) was portable???


    Besides, whenI say I have three systems, I'm talking about three ubuntu systems; one real, two virtual. I'm trying to compare performance between native mode and virtual mode. I'm not trying to compare, for instance, ubuntu against Windows.

    Have you tried lint or valgrind against your code? I assume you've already run the compiler with all warnings turned on and it didn't tell you anything.
    I have not tried lint or valgrind. I will look at them.

    Yes, I tried all warnings, even up to pedantic, strict ANSI, etc.

    Thank you.

  10. #10
    Join Date
    Aug 2007
    Beans
    949

    Re: Inconsistency in time(NULL)

    time returns the current calendar time or -1 if the time is not available. If tp is not NULL, the return value is also assigned to *tp.
    Either your code has a bug, or time() isn't meant to be used for implementing timers.
    Last edited by soltanis; June 14th, 2009 at 04:59 AM.

Page 1 of 3 123 LastLast

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •