Re: Recommended method of getting timestamps?

[Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>]

On Fri, 06 Sep 2013 10:33:58 +0400
Dmitry Vyal <dmitryvyal-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

> Hello Patrick,
> 
> I guess gettimeofday is too heavy if all you need is an abstract 
> timestamp not related to any particular calendar. I think you should 
> look at rte_rdtsc()? It returns a current value of CPU tick counter. So 
> it's very cheap (just a few clocks) and has a great resolution (a 
> fraction of nanosecond).
> 
> Regards,
> Dmitry
> 
> > I have a need to keep a timestamp on a piece of global data.  When then timestamp grows too old I want to refresh that data.  Is it safe to use, gettimeofday()?
> >
> > I thought about using an alarm, but I need to set an alarm from inside the alarm callback which doesn't look like it will work due to the spinlock on the alarm list.
> >
> > And since this is inside the driver I am working on, setting up a timer is not simple.
> >
> > So, I figure to timestamp the data, wait until I need to access it, check the timestamp and refresh if it is too old.
> >
> > Thoughts?  Suggestions?
> >
> > Thanks,
> >
> > Patrick
> >
> > Coming to you from deep inside Fortress Mahan
> 


DPDK has both HPET and TSC timers.

HPET is slower to access non-cached, but has advantage of being same on all cores
and unaffected by power management etc. TSC is faster but can vary in frequency
on some processors. It is also not guaranteed sync'd on some systems with multiple
sockets. See rte_rdtsc and rte_get_hpet_cycles.


The latest DPDK 1.4.1 just released by Intel has common code rte_get_timer_cycles()
to try and make decision at runtime.