4 ms·

This bit makes me wonder about the entropy of the nanosecond clock, for adding entropy to an PRNG: > Given scheduling jitter and so forth, it's not clear what

by yid 13y ago

This bit makes me wonder about the entropy of the nanosecond clock, for adding entropy to an PRNG: > Given scheduling jitter and so forth, it's not clear what it means to get a timestamp with nanosecond resolution from the operating system. It probably takes thousands, if not millions, of instructions between the time the timestamp is retrieved and the time your program looks at it

ars 13y ago
You don't have nanosecond entropy, but you do have microsecond entropy. Plus if it really does tick off in nanoseconds you'll get some random nanosecond number, which you can't use for scheduling, but will be good to feed to the PRNG.
jacquesm 13y ago
I can definitely see some uses here as long as between calls they are monotonically increasing and ordering from two sets of system calls is correct (so a call that started earlier will get an earlier timestamp as a result of the call). The difference would be along the lines of lag vs precision. Measuring time in a non-hard-realtime operating system is a hairy proposition in the best of cases, after all you don't know how long your thread slept right after completing the system call but before your application got to do useful work. Usually this is only microseconds but it isn't rare at all to see this value have extremely high upper limits (100's of milliseconds or more...). This depends a lot on how many cores you have and the quality of the device drivers as well as which scheduler you run.
MichaelSalib 13y ago
Note that some clock reads that appear to go through a file system actually don't on some architectures. On x86-64, there's a special page that's mapped read only for all processes. This page includes time data that is updated by the kernel. When you call the glibc syscall wrapper to get the time, it doesn't actually invoke a syscall; instead, it just reads the correct bit of data from that page. I don't know if that applies to nanosecond resolution clocks though....
- enriquepablo 13y ago
  That would be the _COARSE clocks the article mentions... It would obviously not have nanosecond resolution - for that it would have to be updated by the kernel every nanosecond.
nwmcsween 13y ago
Most operating systems create a vdso with user space accessable operations such as getting time, etc

by yid 13y ago

ars 13y ago

You don't have nanosecond entropy, but you do have microsecond entropy. Plus if it really does tick off in nanoseconds you'll get some random nanosecond number, which you can't use for scheduling, but will be good to feed to the PRNG.

jacquesm 13y ago

I can definitely see some uses here as long as between calls they are monotonically increasing and ordering from two sets of system calls is correct (so a call that started earlier will get an earlier timestamp as a result of the call). The difference would be along the lines of lag vs precision. Measuring time in a non-hard-realtime operating system is a hairy proposition in the best of cases, after all you don't know how long your thread slept right after completing the system call but before your application got to do useful work. Usually this is only microseconds but it isn't rare at all to see this value have extremely high upper limits (100's of milliseconds or more...). This depends a lot on how many cores you have and the quality of the device drivers as well as which scheduler you run.

MichaelSalib 13y ago

Note that some clock reads that appear to go through a file system actually don't on some architectures. On x86-64, there's a special page that's mapped read only for all processes. This page includes time data that is updated by the kernel. When you call the glibc syscall wrapper to get the time, it doesn't actually invoke a syscall; instead, it just reads the correct bit of data from that page. I don't know if that applies to nanosecond resolution clocks though....

enriquepablo 13y ago
That would be the _COARSE clocks the article mentions... It would obviously not have nanosecond resolution - for that it would have to be updated by the kernel every nanosecond.

nwmcsween 13y ago

Most operating systems create a vdso with user space accessable operations such as getting time, etc