lkml.org 
[lkml]   [2003]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Fast timestamps
David S. Miller wrote:
> On Wed, 26 Nov 2003 15:41:52 -0800
> Ben Greear <greearb@candelatech.com> 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@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>


--
Ben Greear <greearb@candelatech.com>
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.045 / U:1.656 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site