And how would you expect a POE program (or any other program in this respect) to know how much time your computer 'loses' ?
I wouldn't want it to know about lost time. That's not the concern.
As far as I can see it, it is possible for software to make the system clock loose time. When the PC boots the OS reads the time from the CMOS clock. But from now on, as I see it (tell me if I'm wrong) the CMOS clock is not polled but time is instead kept in the OS and updated using some kind of interrupt scheme. So, this is a (partly ISR) routine that's called regularly.
Now, a software can somehow prevent the servicable periodicity of that clock-updating routine by very small amounts, and it could accumulate over time, resulting in a system clock that's a bit behind. Of course, next time the PC is rebooted, the time is read from the CMOS clock and everything's fine again. That is, if the CMOS clock was not automatically updated from the system clock at shutdown.
A spreadsheet software won't do that kind of interference. A game could (look at some Windows games). Or a software that schedules tasks close to the hardware interface.
Hence, my question about POE on a mostly embedded platform (i.e. no NTP access): has experienced POE developers seen any degradation in system-keeping time when POE was active 24/24 over long periods of time ?
| [reply] |
a software can somehow prevent the servicable periodicity of that clock-updating routine by very small amounts,...resulting in a system clock that's a bit behind.... the time is read from the CMOS clock and everything's fine again... A game could (look at some Windows games).
This situation did manifest itself with some games under Windows'95/98 (maybe ME, though I found no references to that), but they are 16-bit, essentially DOS-based, with little or no distinction between user-mode and kernel-mode code.
On anything later than that (NT/2K/2K3/XP etc.), this is only likely to occur via a badly written device driver that uses something like a CriticalSection to prevent the kernel from responding to interrupts. It is conceivable that some extreme games/graphics cards might do this, deliberately sacrificing clock accuracy to gain a little redraw performance at very high resolutions, but it should be rare, and probably documented.
It is also possible that device drivers for specialist hardware (laboratory or very high speed communications, equipment) might also deliberately make this trade, but again, you would probably be aware of the possibility, if you had such devices and drivers.
It is unlikely, maybe impossible, that anything written to run exclusively in user-mode, like perl and POE could have such an effect.
So unless you are intending this to run under 95/98, on a system that games are frequently played, or will have non-standard hardware and device drivers, you're probably safe from this particular problem.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Hence, my question about POE on a mostly embedded platform (i.e. no NTP access): has experienced POE developers seen any degradation in system-keeping time when POE was active 24/24 over long periods of time ?
No.
As for your concerns, I don't know about Windows, but usually a O.S. Kernel has control about anything that happens on that machine, hence it shouldn't have any issues about keeping up with the time passing. AFAIK the clock is kept in sync with the CPU ticking. But I'm sure not all kernels out there do that.
| [reply] |