In message <[email protected]>, Chuck Harris writes: >I don't believe that will be happening in a message passing microkernel >(like minix) anytime soon... unless you build all of the timekeeping >software into the kernel, and then you are in the process of becoming >a monolithic kernel ;-)
Well, this brings us into a philosophical area. If a piece of code calls a function to figure out what time it is, the tacit assumption is that the function takes zero time to execute and returns the timestamp of the time where it didn't take any time. In practice, the call will always occupy some duration of time, and the timestamp returned represents some instant during that interval. Depending on the function called, and the CPU hardware we execute it on, the timestamp returned may have more or less jitter relative to the call instruction and the first instrucation executed upon return. I call this jitter the "software-jitter" because it has nothing to do with the time keeping hardware, it is jitter introduced because we operate in software. In addition to the software jitte, we have whatever jitter the function runs into, trying to actually produce the timestamp: Bus contentions, hardware locking, page faults etc. etc. On the other side, if a piece of hardware yanks a signal line to record a timestamp, we can reasonably expect the timestamp will be the exact time of the signals reception +/-1 count on whatever hardware counter is used to keep track of time. These observations hold in general, even for the case where you have no operating system of any kind. If you look at this prism with your MACH-coloured glasses, what you see is that the access to the timekeeping hardware counter is likely to be restricted to one semi-priviledged process. Otherwise, why bother with microkernels in the first place ? It follows that all software calls to get a timestamp consequently becomes IPC calls. And we have 30 years experience telling us, that IPC calls are even more smeared out over time than direct calls and therefore the software jitter becomes worse. But other than that, and that is bad enough because of the scheduling latency/jitter typically present, there are no ill effects from running on a microkernel. If you feed your PPS signal in and do hardware timestamps like we FreeBSD's timecounters allows you to, for instance on the Soekris net4501[1], then your basic clock can be precise, but your microkernel will only allow your software to read fuzzy timestamps from it. If you hook the PPS signal to an interrupt line, and timestamp it in software, then your basic clock can never be precise, because your PPS timestamps are fuzzed by the microkernel. Poul-Henning [1] This is why I say that FreeBSD is a generation ahead, I have yet to see any other operating system support PPS-API on hardware captured signals. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [email protected] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
