Date: Mon, 8 Apr 1996 20:04:40 +1000 From: Bruce Evans <bde@zeta.org.au> To: louie@TransSys.COM, terry@lambert.org Cc: hackers@FreeBSD.org, jkh@time.cdrom.com, msmith@atrad.adelaide.edu.au, roell@blah.a.isar.de, roell@xinside.com Subject: Re: The F_SETOWN problem.. Message-ID: <199604081004.UAA25433@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>... >What a SIGIO based scheme does is interrupt whatever computation is >going on, read the packet from the socket, timestamp it, and put it >into a queue to be processed at some later time. Once you've noted >the arrive time, the time criticality is gone, and you can process it >at your leisure. This doesn't help much if there are `M' higher priority hoggish interrupt handlers that run before the packet's interrupt handler, and `N' other hog processes in the kernel or in user code that run before the SIGIO is delivered. >From what I can see, there are four alternatives to the SIGIO scheme: >... >- OS support for timestamps. I prototyped this in the original ntp3.4 I think this is essential, not an alternative. You still have to worry about higher priority hoggish interrupt handlers. >... >Response time isn't really the problem so much as precision in marking >an event, such as packet arrival. If you pay reasonable care to all >this, you can get the phase (that is, offset) of the local clock to >within single digits of milliseconds over a somewhat reasonable >quality network path, like an local ethernet. Heck, you can even tell >the temperature of the room your computer is in by calibrating the >frequency offset of the computer's clock based on the effect the >temperature has on the crystal oscillator. >Of course, some of us are really weird this way. That how we end up >with PLL models of the computer's clock in the kernel. Some of us wouldn't settle for an offset of 7 digits of nanoseconds :-). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604081004.UAA25433>