In article <[EMAIL PROTECTED]>, Unruh <[EMAIL PROTECTED]> wrote:
> I hope you mean 4 or 10usec, not msec. No. I mean milli-seconds, i.e. 1/HZ for HZ = 100 and 250. I've personally had lost clock interrupts due to a disk driver, on Linux, at HZ=100, but that was an obsolete high speed interface, on a relatively slow machine. People regularly get lost ticks on Linux at HZ=1000, when using IDE's in non-DMA mode and I also believe they get them at HZ=250. I believe there have been reports at HZ=100. Windows users also report lost interrupts, although I'm not 100% sure whether that applies with the normal HZ=~64 rate or with the, higher, multimedia rate, which might be instigated by other software, although ntpd now tends to instigate it itself, to avoid glitches when the rate changes. One of the problems is that modern operating system kernels tend to be written in high level languages, so coders don't cycle count their interrupt routines and proper use of priority interrupts can be difficult. Short interrupt routines tend not to re-enable higher priorities at all, although those won't have the sort of latency given above. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
