-------- Interrupts are no longer hardware phenomena, but bus transactions which must lay claim to one or more busses, send a formatted message which is received by some kind of "interrupt prioritizer" which again, may or may not send another message on another kind of bus to the instruction sequencer in one or more CPU cores.
Both of these message transmissions will very likely involve clock-domain-crossings. The good news is the per-interrupt overhead is lower, thanks to interrupts being 'gently woven into' the instruction stream, instead of hitting it with a sledgehammer. But the latency and jitter is literally all over the place... Fortunately a lot of "counter-module" hardware can be used to hardware-timestamp signals, even if the design does not exactly support it. For instance, the code I wrote for the Soekris 4501 uses two hardware counters: The first one, free-running, is the "timecounter" which the system clock is based on. The second one starts counting at the same rate as the first when the PPS signal comes in. By the time the CPU comes around to read both counters, it subtracts the second from the first, to figure out what time the hardware signal happened. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | 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 -- time-nuts@lists.febo.com -- To unsubscribe send an email to time-nuts-le...@lists.febo.com To unsubscribe, go to and follow the instructions there.
