Bug 11432
Summary: | tick clock too slow by 0.5% | ||
---|---|---|---|
Product: | Timers | Reporter: | Oliver Hamann (olha) |
Component: | Other | Assignee: | john stultz (john.stultz) |
Status: | REJECTED WILL_NOT_FIX | ||
Severity: | high | ||
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.26.3 | Subsystem: | |
Regression: | --- | Bisected commit-id: |
Description
Oliver Hamann
2008-08-26 08:32:31 UTC
I'm not sure I'm fully understanding how you're making use of the times() interface. Could you clarify this a bit? time() returns the number of seconds since the Epoch. times() returns a tms struct that provides the amount of cpu time the process has consumed. Thus if the process sleeps, blocks, or is preempted, it won't consume any cpu time. Further on SMP systems, the cpu time for a process with threads can grow faster then time(), since two threads can consume cpu time on different processors in parallel. Thus the return values of the two functions are not strictly linked. Also If you want finer resolution time then just seconds, consider gettimeofday() or clock_gettime(). I use the return value of the times function, not the results in the tms struct. That return value is from a continuous clock which never stops or jumps, and which has no defined start point. It is measured in clock ticks. The number of ticks per second can be get with sysconf(_SC_CLK_TCK) (mostly this results 100). That clock is widely used in many applications for all kind of delta-time measurements, because unlike the time and gettimeofday functions, it does not jump when the system clock is adjusted. clock_gettime requires librt and is not so portable. Yes, using gettimeofday in the stopwatch is the solution which I prepared for Eagle Mode 0.72.0. 0.5% is unfortunately within the sort of timer clock error range found on some hardware and if your hardware can't count time accurately you need to look at xntpd either to lock time externally or to slew continually to compensate |