3 ms·

And so does my Fedora install (let's not blame Redmond unnecessarily). My Android phone is even worse - it drifts by about 5-10s a day. Not a nightmare but it'

And so does my Fedora install (let's not blame Redmond unnecessarily). My Android phone is even worse - it drifts by about 5-10s a day. Not a nightmare but it's still a lot more than my (probably unrealistic) expectations of 21st century hardware.

freehunter 13y ago
My car also has a drifting clock without a dynamic CPU, losing two minutes every three months. It also doesn't have the ability to sync with NTP so it can't correct itself. Apparently clocks are hard.
- harrytuttle 13y ago
  Clocks are easy. Even accurate clocks are easy. However, accurate clocks are expensive which is where the problem is
  - deleted 13y ago
    [deleted]
dspillett 13y ago
> And so does my Fedora install (let's not blame Redmond unnecessarily). It isn't particularly an OS probably at all at the root: it is a hardware problem. The RTCs in PC have historically not been terribly reliable so OSes tend to ignore them where at all possible. The probably here is probably the same as seen inside VMs: the OS is trying to count timer interrupts and other such references to gauge the passage of time, but with CPUs changing their speeds constantly this in itself becomes difficult to make accurate. Windows' default behaviour of occasionally checking an external time reference (IIRC it checks approximately three times per day if your machine is on 24 hours) is often inadequate IMO though. Much better would be to use proper (relatively constant) NTP checking and clock skewing, though that imposes an extra infrastructure load.
dz0ny 13y ago
Yep this is know problem on Android, relaying on system time for synchronizing is bad idea. One such example http://opensignal.com/reports/timestamps/ http://opensignal.com/reports/timestamps/
ape4 13y ago
I'd think it would be good for either OS to update the RTC occasionally. So when it does reboot the RTC is sort of accurate.
qb45 13y ago
Here Redmond is blamed for not providing any API to access the physical RTC chip and for switching old APIs to use CPU cycle counter even on RTC-equipped systems. You can still run hwclock on your Fedora box and get genuine RTC readout if you need it.
- cnvogel 13y ago
  hwclock will only give you 1second resolution, because the RTC chip can't do better. But querying the RTC directly is dog slow by todays standards, it's accessed via 8-bit port IO where one access eats up thousands of cpu cycles on a modern chip. The really old way of timekeeping was to basically advance the system time by a constant amount, in an interrupt routine which might have been triggered by the ancient timer chip, and interpolation done between those ticks using the cpu TSCs. And actually hwclock accesses /dev/rtc* which is just an arbitrary character devices (which the kernel indeed can use to initialize its notion of time on boot up), it's never accessed with the standard syscalls gettimeofday() or clock_gettime(). So while I really like MS bashing from time to time, in this case it's probably not too negligent of them, there might even be a standard way of informing the OS kernel about a change in TSC speed?

freehunter 13y ago

My car also has a drifting clock without a dynamic CPU, losing two minutes every three months. It also doesn't have the ability to sync with NTP so it can't correct itself. Apparently clocks are hard.

harrytuttle 13y ago
Clocks are easy. Even accurate clocks are easy. However, accurate clocks are expensive which is where the problem is
- deleted 13y ago
  [deleted]

dspillett 13y ago

> And so does my Fedora install (let's not blame Redmond unnecessarily). It isn't particularly an OS probably at all at the root: it is a hardware problem. The RTCs in PC have historically not been terribly reliable so OSes tend to ignore them where at all possible. The probably here is probably the same as seen inside VMs: the OS is trying to count timer interrupts and other such references to gauge the passage of time, but with CPUs changing their speeds constantly this in itself becomes difficult to make accurate. Windows' default behaviour of occasionally checking an external time reference (IIRC it checks approximately three times per day if your machine is on 24 hours) is often inadequate IMO though. Much better would be to use proper (relatively constant) NTP checking and clock skewing, though that imposes an extra infrastructure load.

dz0ny 13y ago

Yep this is know problem on Android, relaying on system time for synchronizing is bad idea. One such example http://opensignal.com/reports/timestamps/ http://opensignal.com/reports/timestamps/

ape4 13y ago

I'd think it would be good for either OS to update the RTC occasionally. So when it does reboot the RTC is sort of accurate.

qb45 13y ago

Here Redmond is blamed for not providing any API to access the physical RTC chip and for switching old APIs to use CPU cycle counter even on RTC-equipped systems. You can still run hwclock on your Fedora box and get genuine RTC readout if you need it.

cnvogel 13y ago
hwclock will only give you 1second resolution, because the RTC chip can't do better. But querying the RTC directly is dog slow by todays standards, it's accessed via 8-bit port IO where one access eats up thousands of cpu cycles on a modern chip. The really old way of timekeeping was to basically advance the system time by a constant amount, in an interrupt routine which might have been triggered by the ancient timer chip, and interpolation done between those ticks using the cpu TSCs. And actually hwclock accesses /dev/rtc* which is just an arbitrary character devices (which the kernel indeed can use to initialize its notion of time on boot up), it's never accessed with the standard syscalls gettimeofday() or clock_gettime(). So while I really like MS bashing from time to time, in this case it's probably not too negligent of them, there might even be a standard way of informing the OS kernel about a change in TSC speed?