> > i took a quick look at the runtime·nanotime, and it looks like it's being > > used for gettimeofday, which shouldn't be super performance sensitive. > > I'm on thin ice here, but I seem to remember that the crucial issue > was the resolution (nanosecond) and the expectation that Plan 9 would > have to match (for portability purposes) the quality available on > other operating system.
the resolution of the original was already 1ns, the precision and accuracy were somewhat less, as they would be on any os/hw combination i am aware of. > Curiously, I'm pretty certain that it was the issue of an fd that > remained open (something to do with caching the /dev/time fd, if I > remember right) that caused some tests to fall apart, probably because > a test for leaking fds actually needed to cache the time of day for > time out purposes. well close the fd then. it's not exceptionally expensive. > Two birds with one stone? On the one hand you gain accuracy and on > the other you actually successfully complete the tests. i would be very surprised if there were any gain in accuracy. the accuracy is going to be dominated by the most inaccurate term, and that's likely going to be timesync, and on the order of milliseconds. - erik
