> 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
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.
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.