getting nanoseconds in python

[Skaperen]

current versions of Linux are able to provide the current time to processes at the full resolution the hardware is capable of, down to at least nanoseconds.  it has been able to do this for years.  doing the command date +%N a few times can show this.

how would you do this in Python (without all the overhead of running the date command)? suppose you are implementing the date command in Python.  how would you d it?

[heiner55]

Maybe this helps:

import time
print("Times")
print("%42.21f" % time.time())
print("%42.21f" % time.clock())
print("%42.21f" % time.monotonic())
print("%42.21f" % time.perf_counter())
print("%42.21f" % time.process_time())

print("Resolution in sec")
print("%.21f" % time.get_clock_info('time').resolution)
print("%.21f" % time.get_clock_info('clock').resolution)
print("%.21f" % time.get_clock_info('monotonic').resolution)
print("%.21f" % time.get_clock_info('perf_counter').resolution)
print("%.21f" % time.get_clock_info('process_time').resolution)

Output (Windows 7):

Output:
Times
          1509080995.988283634185791015625
                   0.000000933012936690874
               10299.888000000000829459168
                   0.000125490239984922498
                   0.015600099999999998690

Resolution in sec
0.015600099999999998690
0.000000466506468345437
0.015600099999999998690
0.000000466506468345437
0.000000100000000000000

[Skaperen]

that looks like something to play around with.

---

oh... and i need to do this in both python2 and python3.

[sparkz_alot]

I know this is a long ago and far away thread, but I ran across this information recently. That being, the 'time' function will have nanosecond capability with Python 3.7 https://www.python.org/dev/peps/pep-0564/. I'm not sure if it will be in the next maintenance release of Python 2, however they do offer examples of how nanoseconds 'used' to be handled, so you might find some inspiration there.

[Skaperen]

time.time() is not getting all the way to nanosecond resolution, but it is getting better than microsecond. so methods that work at microsecond resolution are losers ... they are losing some resolution. so the big question i have is whether linux is actually delivering true time at a higher resolution or is delivering fake time by "appending" process id number and other things to the time it has, which may be more or less than what this shows. other things may include random bits, or a numeric sequences, or processor/core ids, to be sure time values are always unique even if the hardware does not ensure it. the ibm mainframe architecture includes a non-privileged cpu instruction to get the time as a 64 bit value with a resolution of 1/4096 of a microsecond, so the os can't fake it other than the initial value it loads.

so is a python float a 53-bit (stored in 8 bytes) or a 64-bit (stored in 10 bytes) hardware float on amd-64 ?

Output:
lt1/forums /home/forums 1> py3
Python 3.5.2 (default, Nov 23 2017, 16:37:01) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from time import time as secs
>>> for n in range(30):
...     f=secs()
...     x=int(f*2.0**64)+2**128
...     print(hex(x))
... 
0x1000000005a503954aaa1d40000000000
0x1000000005a503954aaa3700000000000
0x1000000005a503954aaa3cc0000000000
0x1000000005a503954aaa4100000000000
0x1000000005a503954aaa4540000000000
0x1000000005a503954aaa4940000000000
0x1000000005a503954aaa4d80000000000
0x1000000005a503954aaa51c0000000000
0x1000000005a503954aaa55c0000000000
0x1000000005a503954aaa5a40000000000
0x1000000005a503954aaa5ec0000000000
0x1000000005a503954aaa6300000000000
0x1000000005a503954aaa6740000000000
0x1000000005a503954aaa6b80000000000
0x1000000005a503954aaa6fc0000000000
0x1000000005a503954aaa73c0000000000
0x1000000005a503954aaa77c0000000000
0x1000000005a503954aaa7c80000000000
0x1000000005a503954aaa8080000000000
0x1000000005a503954aaa8500000000000
0x1000000005a503954aaa8900000000000
0x1000000005a503954aaa8e40000000000
0x1000000005a503954aaa9280000000000
0x1000000005a503954aaa96c0000000000
0x1000000005a503954aaa9ac0000000000
0x1000000005a503954aaa9ec0000000000
0x1000000005a503954aaaa300000000000
0x1000000005a503954aaaa740000000000
0x1000000005a503954aaaab40000000000
0x1000000005a503954aaaaf80000000000
>>> 
lt1/forums /home/forums 2>

[Larz60+]

time module has a resolution of 1 millisecond.
this has to do with the crystal frequency of the computer clock.
the crystal is what's known as a 'watch' crystal because that is what is was originally
designed for and still used today. It has a frequency of 32.768 khz. This is 2 to the 15th,
and can produce a precise 1 second period by the use of a 15 stage binary counter.

This makes sense for several reasons, probably the best is that there are over 1.2 billion
watches produced each year which makes this crystal very cost effective.
Another is that the power consumed by the clock circuitry is extremely low because of the small
number of components used in the circuit. This is important on keeping the (cmos memory) battery drain low when
the computer is not turned on.

So, 1000 hertz = 1ms resolution. all other divisions are based on this.

[Skaperen]

can you try the code i showed to see if your system has a clock that is so limited?

---

it looks like time.time() has 20 bits of fraction, so a resolution of 1/1048576 (0.00000095367431640625) of a second. that is more than a microsecond (not much more) but finer bits will be produced if the division is // 1000000 instead of // 1048576

[Gribouillis]

Concerning python floats, this doc page is really worth reading. Python floats are usually IEEE754 floating points numbers on 64 bits, which means 1 sign bit, 11 exponent bits and 52 mantissa bits. The precision is 53 bits because the for most numbers, the IEEE754 format doesn't store the first non zero bit of the number.

Notice that time.time() returns the number of seconds since the epoch (1/1/1970), which means that as of now, 31 bits (or perhaps 30 bits) are needed to store the integer part of it and it remains only 21 bits (22?) for the fractions of a second.

[Skaperen]

thanks. now i don't need to run a float test to how big it is. in Pike, there is a build-time option to define which C-type (double or long double) to use. the distributed binary, i believe, uses just double and i have done builds with long double. i have never built Python, but am curious if this can be done.