From owner-freebsd-hackers Mon Apr 8 03:08:40 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA17075 for hackers-outgoing; Mon, 8 Apr 1996 03:08:40 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA17069 for ; Mon, 8 Apr 1996 03:08:30 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id UAA25433; Mon, 8 Apr 1996 20:04:40 +1000 Date: Mon, 8 Apr 1996 20:04:40 +1000 From: Bruce Evans Message-Id: <199604081004.UAA25433@godzilla.zeta.org.au> To: louie@TransSys.COM, terry@lambert.org Subject: Re: The F_SETOWN problem.. Cc: hackers@FreeBSD.org, jkh@time.cdrom.com, msmith@atrad.adelaide.edu.au, roell@blah.a.isar.de, roell@xinside.com Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >... >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