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

[Valerio Bellizzomi]

On 13/02/2007, at 8.32, Jonathan S. Shapiro wrote:

>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).

It is too early, I am at first stages in specification of the application.

>
>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.

I need to look at what cards are available and decide.


val