Accurate time measurement in Linux

Question

I am collecting data from different sources and would like to get the time as accurate as possible. Besides timeit , time . monotonic , time.time , is there something like a "realtime" method for Linux?

(I know, it depends from the operating system (open suse) and a multitasking/multiuser system will hardly be as accurate as a realtime system but to some extend i would like to take measure time as accurate as possible on a normal Linux system.)

example with time.time method. If i use this method in a loop where i install a sleep for 4 seconds (starting at second 8) , the measuments are:

absolute                distance to next measurement
8.040261268615723       0.01363372802734375     
12.053894996643066      0.012626409530639648    
16.066521406173706      0.020114421844482422    
20.08663582801819           

where i have a certain start time and an execution time for the loop which is about 20ms because the distance from one measurent to the next is about 0.02 second.

Addendum: the time measurement for time.monotonic is nearly the same as the above (time.time).

Code piece for the loop:

seconds = 4
MAX = 11

     for i in range (1,MAX+1):
        sleep (seconds)                                    # 
        mt1.tick()                                          # take time stamp
        Ergebnis.append(mt1.elapsed_time)                   # get absolute time
        Differenz.append(mt1.elapsed_time - i*Sekunden)     # get elapsed time difference (compared to ideal time)

Answer 1

I have made some measurements and searched threw answers about timing questions and came to some sort of (for me) important conclusions. Many, high voted answers, mentioned that the selection of adequate timing functions would provide best response times, for example time.monotonic (oder monotonic_ns) or timeit.default_timer() (because there, the python interpreter would choose the most adequate and accurate measurement) or time.time(). First i will show the test situation for clarification. But this is not as important as the base question, which timing method would generate the most accurate time. I only show it for a better understanding and because there was a question for it.

I made tests with three timing methods, time.monotonic(), timeit.default_timer() and time.time(). While timeit.default_timer() seamed to be the most accurate timer, the difference to the others where not that impressive for me. Then i though about multiuser/multiprocessing and priorities of processes and the scheduling in a multiuser-system. The scheduler in open suse is distributing process time just like any other multiuser system and the scheduling depends on the priority of the process. I looked at my default process priority, it is by default 19. I changed the priority as an parameter and made my tests again and the response time is indeed depending on the process priority and it seems as if there is a hard limes, it is on my system "0": it seems that all processes about process priority "0" are scheduled on an slow lane. In contrast, all process with an lower(higher) priority than 0 are getting processor time faster. In the loop above i avoided system calls which would slow the process down, i collected the data to calculate the results behind the loop. The data is showing that the absolute delay 1) depends on the process priority and 2) that the absolute delay of the different methods differ significantly only at process priorities above 0. Under 0 it seems regardless which method i choose. The absolute delay for processing one loop is more than 20ms above process priority of 0 and around 4ms beneath that priority. The rise of the slope is due to the repeated processing of the loop and the summation of every pass.

With this result i can roughly estimate the timings for my measurements and, in my case, when the measurement time is significant above some seconds (in my case about 30) the accuracy of about 4 ms is more than sufficient. More than that, because it seems that the response time beneath process priority 0 is predictable (and not as stochastic as above 0) i can calculate the delay into my measurements because the response time seems linear (and correlate) to the number of instructions.