Re: Problem with frame time stamping
From: Antoine Zen-Ruffinen
Date: Tue Nov 13 2007 - 09:46:17 EST
ok, I now understood where my error was. It was a mismatch between my
old kernel headers and my new kernel that I am running !!!! Pretty
Tank's you for your time, you learn me some stuff, I appreciate it.
2007/11/13, Eric Dumazet <dada1@xxxxxxxxxxxxx>:
> Antoine Zen-Ruffinen a écrit :
> > THIS is what I did at the beginning. But is seem me to be some thing
> > wrong. So I put a static value in skb->tstamp instead of
> > ktime_get_real() for debug purpose. And I was still becoming the
> > amount of second, microsecond since 1970. We are back to my initial
> > mail ! The value of skb->tsamp doesn't seems to be returned by
> > ioctl().
> OK Antoine.
> Yes, 'struct timeval' is as you discovered, ie relative to *something*,
> a given event in the past. (in your case, CLOCK_REALTIME Epoch : January
> 1th 1970)
> It is even documented (man gettimeofday)
> The gettimeofday() function shall obtain the current time,
> expressed as seconds and microseconds since the Epoch, and store it in the
> timeval structure pointed to by tp.
> For timespec STAMPNS, see clock_gettime() description.
> clock_gettime(CLOCK_REALTIME, &ts);
> If in your driver you stick in tstamp.tv64 a value like 0x00010002, then
> the result of ioctl(SIOCGSTAMP) will be :
> tv.tv_sec = 0 (so yes, January 1th 1970)
> tv.tv_usec = 65 (because 0x10002/1000 = 65)
> Not counting the fact that .tv64 should not be directly set, unless for
> 0 value, because it is not portable.
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html