Skaperen
June 24th, 2019, 06:30 AM
system calls like gettimeofday() can report an apparent resolution of one nanosecond. that would be like incrementing at a rate of 1 GHz. in reality PC hardware has no clock operating at such a rate. it could be done; the hardware technology exists. in the mean time the time reported by Linux increments at a much slower rate.
a big problem exists with this. the time can be substantially behind when the time is gotten. i notice this happening with a couple of clock programs, such as "dclock". the effect is that it "misses" some seconds when the display is set to show seconds. these programs get the time of when the clock last incremented, which can be in the previous one second period. clocks only updating every minute might even be a whole minute off. i've seen 15:22:59 stay for 2 seconds then jump to 15:23:01. if that had been a one minute clock it might show 15:22 for the duration of 15:23 and look like a pretty serious bug. i've seen a cron job think it was running on the previous day and really screw up (my workaround is those that need to know the time have a "sleep 1" before they ask for the time, or if they just need the date they don't get scheduled right at 00:00).
a program like a clock could do better by keeping (and using) it's own time value, incrementing it as needed, and calculating how long to sleep until that time is to arrive. it could come out looking like it is ahead, so even this is not a perfect solution. but it has done better when i have tried it.
a big problem exists with this. the time can be substantially behind when the time is gotten. i notice this happening with a couple of clock programs, such as "dclock". the effect is that it "misses" some seconds when the display is set to show seconds. these programs get the time of when the clock last incremented, which can be in the previous one second period. clocks only updating every minute might even be a whole minute off. i've seen 15:22:59 stay for 2 seconds then jump to 15:23:01. if that had been a one minute clock it might show 15:22 for the duration of 15:23 and look like a pretty serious bug. i've seen a cron job think it was running on the previous day and really screw up (my workaround is those that need to know the time have a "sleep 1" before they ask for the time, or if they just need the date they don't get scheduled right at 00:00).
a program like a clock could do better by keeping (and using) it's own time value, incrementing it as needed, and calculating how long to sleep until that time is to arrive. it could come out looking like it is ahead, so even this is not a perfect solution. but it has done better when i have tried it.