Re: Fast timestamps

[Ben Greear]

David S. Miller wrote:
> On Wed, 26 Nov 2003 15:41:52 -0800
> Ben Greear <greearb@xxxxxxxxxxxxxxx> wrote:
>
>
> > I'll try to write up a patch that uses the TSC and lazy conversion
> > to timeval as soon as I get the rx-all and rx-fcs code happily
> > into the kernel....
> >
> > Assuming TSC is very fast and the conversion is accurate enough, I think
> > this can give good results....
>
>
> I'm amazed that you will be able to write a fast_timestamp
> implementation without even seeing the API I had specified
> to the various arch maintainers :-)

Well, I would only aim at x86, with generic code for the
rest of the architectures.  The truth is, I'm sure others would
be better/faster at it than me, but we keep discussing it, and it
never gets done, so unless someone beats me to it, I'll take a stab
at it...  Might be after Christmas though, busy December coming up!

I agree with your approach below.  One thing I was thinking about:
is it possible that two threads ask for the timestamp of a single skb
concurrently?  If so, we may need a lock if we want to cache the conversion
to gettimeofday units....  Of course, the case where multiple readers want
the timestamp for a single skb may be too rare to warrant caching...

Ben

> ====================
>
> But at the base I say we need three things:
>
> 1) Some kind of fast_timestamp_t, the property is that this stores
>    enough information at time "T" such that at time "T + something"
>    the fast_timestamp_t can be converted what the timeval was back at
>    time "T".
>
>    For networking, make skb->stamp into this type.
>
> 2) store_fast_timestamp(fast_timestamp_t *)
>
>    For networking, change do_gettimeofday(&skb->stamp) into
>    store_fast_timestamp(&skb->stamp)
>
> 3) fast_timestamp_to_timeval(arch_timestamp_t *, struct timeval *)
>
>    For networking, change things that read the skb->stamp value
>    into calls to fast_timestamp_to_timeval().
>
> It is defined that the timeval given by fast_timestamp_to_timeval()
> needs to be the same thing that do_gettimeofday() would have recorded
> at the time store_fast_timestamp() was called.
>
> Here is the default generic implementation that would go into
> asm-generic/faststamp.h:
>
> 1) fast_timestamp_t is struct timeval
> 2) store_fast_timestamp() is gettimeofday()
> 3) fast_timestamp_to_timeval() merely copies the fast_timestamp_t
>    into the passed in timeval.
>
> And here is how an example implementation could work on sparc64:
>
> 1) fast_timestamp_t is a u64
>
> 2) store_fast_timestamp() reads the cpu cycle counter
>
> 3) fast_timestamp_to_timeval() records the difference between the
>    current cpu cycle counter and the one recorded, it takes a sample
>    of the current xtime value and adjusts it accordingly to account
>    for the cpu cycle counter difference.
>
> This only works because sparc64's cpu cycle counters are synchronized
> across all cpus, they increase monotonically, and are guarenteed not
> to overflow for at least 10 years.
>
> Alpha, for example, cannot do it this way because it's cpu cycle counter
> register overflows too quickly to be useful.
>
> Platforms with inter-cpu TSC synchronization issues will have some
> troubles doing the same trick too, because one must handle properly
> the case where the fast timestamp is converted to a timeval on a different
> cpu on which the fast timestamp was recorded.
>
> Regardless, we could put the infrastructure in there now and arch folks
> can work on implementations.  The generic implementation code, which is
> what everyone will end up with at first, will cancel out to what we have
> currently.
>
> This is a pretty powerful idea that could be applied to other places,
> not just the networking.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc  http://www.candelatech.com


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/