And how would you expect a POE program (or any other program in this respect) to know how much time your computer 'loses' ?
You need a synchronization method, whether a NTP server to sync with, or you know precisely that after X seconds spent, the delay is x seconds and you adjust the time yourself.
| [reply] |
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] |
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] |
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] |
I'm not sure I understand your question. Running an application using POE (or indeed any other perl module) shouldn't affect the accuracy of your PC's clock. That depends largely on the hardware in the computer (which is generally pretty inaccurate from what I remember).
If your problem is that you want this application to generate logs with an accurate timestamp, then the ONLY way to do this is to have the PC's clock synchronised with a remote source that is more accurate. NTP is ONE way to do this. You could, of course, invent your own alternative to NTP (Microsoft did this with their "domain time service") - however you're unlikely to get anywhere near the accuracy of NTP by rolling your own (as Microsoft demonstrated).
| [reply] |
