On Tue, 14 Feb 2017 10:31:30 -0500, you wrote: >On 14/02/2017 7:26 AM, Bob Camp wrote: > >> A direct port might be a +/- 100 ns sort of thing most of the time and a >> +/-10 us >> thing every so often under some OSs. Most desktop operating systems are not >> designed to prioritize random pin interrupts. A dirt cheap MCU coded with a >> few >> (hundred) lines of assembly code may be a better option than a typical >> desktop. >> Complicating this further is the degree to which some OSs can be directly or >> indirectly optimized. Install *this* package and it all goes nuts. Install >> that package >> and not much happens . >> >> Bob > >Hence, wouldn't Best Practice be boxes loaded with only the bare OS and >software for the time-related tasks? >As in: >- a dedicated machine/box for unencumbered acceptance of PPS, and >- for systems with a business need, a dedicated NTP server/box >disciplined by the PPS source (with dedicated communication), while >maintaining internet NTP sources as backup for when the PPS source fails? >Is there a better way? >Other considerations? > >Michael
When I was doing this many years ago with PC hardware the big problem was not the OS or load on the OS but the x86 processor's SMM (system management mode). Some motherboards and BIOS revisions were completely unusable. It was always fun to use a low level I/O port to monitor interrupt latency with an oscilloscope; with some practice it was possible to identify the various peaks in the histogram at a glance. Eventually I gave up running real time tasks on PC hardware and moved everything to dedicated hardware in one form or another. _______________________________________________ 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.
