| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <47FE36EE.7020307@nortel.com> Date: Thu, 10 Apr 2008 09:49:02 -0600 From: "Chris Friesen" <cfriesen@...tel.com> To: Jack Harvard <jack.harvard@...glemail.com> CC: linux-kernel@...r.kernel.org Subject: Re: gettimeofday() resolution in Linux? Jack Harvard wrote: > 1. Linux's time resolution is 10ms, as defined by HZ=100. As others have said, this is not the time resolution, but the tick time. In other words, this is the smallest amount of sleep that you can normally ask for, but you can obtain a timestamp with much more accuracy. > 2. gettimeofday() can get time in microseconds, but I'm not sure about > the accuracy of the time finer than 10ms. Barring bugs, it should be accurate to microseconds. > Sometimes gettimeofday( ) > can even give me microseconds results rolled backwards in time, which > I suspect could be caused by its accuracy. My question here is "how > accurate is the time from gettimeofday()" This is due to bugs. There was a recent thread called "gettimeofday() jumping into the future" which just fixed a problem in this area, and there have been other such issues in the past. In particular, I think AMD multicore systems don't sync the TSC on the cores. Usually it's possible to force the system to use something other than the TSC for timestamping. This is generally somewhat slower but less likely to be buggy. Chris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists