[coyotos-dev] coyotos.sleep, sleepTill, the epoch

[Jonathan S. Shapiro]

On Tue, 2007-02-13 at 02:41 +0100, Valerio Bellizzomi wrote:
> On 12/02/2007, at 9.49, Jonathan S. Shapiro wrote:
> >You don't want a tick counter because you don't actually ask for time of
> >day 4,000 times per second. What you want is a free-running interval
> >counter that can be queried by the ToD implementation at need.
> 
> I am interested to know the time resolution for use in sampling
> applications that grab data from some external source via a PCI card. 4000
> times per second is really much much more than what I expect to use.

Yes. This makes sense.

Here is what I think about this:

1. If you can specify a time granularity that you need, we can schedule
that (within the limits of the hardware).

2. For most applications this is not needed at all if the free-running
tick counter is "published" to the time page on every interrupt.

3. The exception is polling, but notice that polling turns into
scheduling the preemption clock, which published the tick value.


When you measure that PCI card, chances are that you just took an
interrupt from it and the value in the tick page will have been updated.
This may not be true if the device has mastering DMA, but for that kind
of thing there is a heisenberg problem. If you wanted the time of actual
packet arrival, and the device did a bus-mastering DMA to deliver it,
then the device is the only one that can supply the time. Either it does
or it doesn't. Failing that, the best time you can get is the time that
the interrupt arrived, and the "update time page on interrupt" strategy
gives you that.


shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100