title: How is the microsecond time of linux gettimeofday() obtained and what is its accuracy?
body: <p>Wall clock time is usually provided by the systems RTC. This mostly only provides times down to the millisecond range and typically has a granularity of 10-20 miliseconds. However the resolution/granularity of <a href="http://linux.die.net/man/2/gettimeofday" rel="nofollow noreferrer">gettimeofday()</a> is often <a href="https://stackoverflow.com/a/4776133/1504523">reported </a> to be in the few microseconds range. I assume the microsecond granularity must be taken from a different source.</p>
  
  <p><strong>How is the microsecond resolution/granularity of gettimeofday() accomplished?</strong></p>
  
  <p>When the part down to the millisecond is taken from the RTC and the mircoseconds are taken from a different hardware, a problem with phasing of the two sources arises. The two sources have to be <code>synchronized</code> somehow.</p>
  
  <p><strong>How is the synchronization/phasing between these two sources accomplished?</strong></p>
  
  <p><strong>Edit:</strong> From what I've read in links provided by amdn, particulary the following <a href="http://software.intel.com/en-us/articles/best-timing-function-for-measuring-ipp-api-timing/" rel="nofollow noreferrer">Intel</a> link, I would add a question here: </p>
  
  <p><strong>Does <code>gettimeofday()</code> provide resolution/granularity in the microsecond regime at all?</strong> </p>
  
  <hr>
  
  <p><strong>Edit 2: Summarizing the amdns <a href="https://stackoverflow.com/a/13231654/1504523">answer</a> with some more results of reading:</strong> </p>
  
  <p>Linux only uses the realtime clock (RTC) at boot time
  to synchronize with a higher resolution counter, i.g. the Timestampcounter (TSC). After the boot <code>gettimeofday()</code> returns a time which is entirely based on the TSC value and the frequency of this counter. The initial value for the TSC <code>frequency</code> is corrected/calibrated by means of comparing the system time to an external time source. The adjustment is done/configured by the <a href="http://linux.die.net/man/2/adjtimex" rel="nofollow noreferrer">adjtimex()</a> function. The kernel operates a phase locked loop to ensure that the time results are monotonic and consistent. </p>
  
  <p>This way it can be stated that <code>gettimeofday()</code> has microsecond resolution. Taking into account that more modern Timestampcounter are running in the GHz regime, the obtainable resolution could be in the nanosecond regime. Therefore this meaningfull comment </p>
  
  <pre><code>/**
  407  * do_gettimeofday - Returns the time of day in a timeval
  408  * @tv:         pointer to the timeval to be set
  409  *
  410  * NOTE: Users should be converted to using getnstimeofday()
  411  */
  </code></pre>
  
  <p>can be found in <a href="http://lxr.free-electrons.com/source/kernel/time/timekeeping.c" rel="nofollow noreferrer">Linux/kernel/time/timekeeping.c</a>. This suggest that there will possibly
  be an even higher resolution function available at a later point in time. Right now <code>getnstimeofday()</code> is only available in kernel space.</p>
  
  <p>However, looking through all the code involved to get this about right, shows quite a few comments about uncertainties. It may be possible to obtain microsecond resolution. The function <code>gettimeofday()</code> may even show a granularity in the microsecond regime. <strong>But:</strong> There are severe daubts about its accuracy because the <em><code>drift</code></em> of the TSC frequency cannot be accurately corrected for. Also the complexity of the code dealing with this matter inside Linux is a hint to believe that it's in fact too difficult to get it right. This is particulary but not solely caused by the huge number of hardware platforms Linux is supposed to run on.</p>
  
  <p><strong>Result:</strong> <code>gettimeofday()</code> returns monotonic time with microsecond granularity but the time it provides is almost never is phase to <code>one microsecond</code> with any other time source. </p>