tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: GSoC 2011 project proposal [packet timestamping]



On 03/28/11 23:30, Dennis Ferguson wrote:
On 28 Mar 2011, at 11:54 , Frank Kardel wrote:
On 03/28/11 19:52, Matt Thomas wrote:
On Mar 28, 2011, at 10:08 AM, Joerg Sonnenberger wrote:


On Mon, Mar 28, 2011 at 07:52:52PM +0400, Dmitry Cherkassov wrote:

     2. Design and implement SIOCSHTSTAMP ioctl support in one ore more
drivers;

What speaks against having the timestamping done as part of the normal
ifq operations?

I think timestamp should be a capability (like jumbogram).  If the
driver doesn't support it, it could be generically done in if_input
but with a small loss of accuracy.

Also, what happens on cpus/systems with out a highly accurate clock?

I agree with the notion that it should be a capability.
The PTP capable interfaces do the time stamping at PHY
level using a local counter of the interface and that
should be transparently supported.
....
This suggests that what should be carried in from the interface with packets is
the rawest form of tick-stamp in whatever form it is available (i.e. system 
clock
tick-stamps if done in software, or NIC-specific tick-stamps if done in 
hardware).
Only when it finally arrives at a socket whose listener actually cares to have a
time-of-day stamp should it go to the trouble of doing the math (and figuring 
out what
math needs to be done in the case of NIC tick-stamps) to produce the time of 
day.  Any
tick-stamps which aren't wanted by the socket the packet arrived at can be fed 
(in raw
form) to the pool /dev/random feeds from, providing a significant improvement 
in that
as well.

This would require that the current clock code separate the taking of a 
tick-stamp
from the math to turn it into a time of day, and that it be capable of turning a
tick-stamp taken "some time ago" (for a reasonable definition of that) into the
same time of day that it would have arrived at had it done the conversion 
immediately.

For the ntpd interleave protocol Dave Mills called for
timestamping the start and the end of specific packets.
So this should be controllable/supportable too.
Also modern interfaces use interrupt moderation, thus
software only time stamping will not work too well with
these interfaces.
Certainly, though it is safe to say that in the absence of NIC
timestamp support taking tick-stamps in the driver software is
still much superior to the alternative of taking them in the user-space
application.

Dennis Ferguson
I agree very much with what you say performancewise. Actually the timecounter
code is not too far from what you want. tc_delta() is the ticks passed since
the last windup/synchronisation. What we need to maintain is the relationship
between the cycle delta, the related time scale and the windup effects.
Those counters usually wrap after a short time the seldom last much longer than
a second - so when picking a cycle counter we may have to copy some state in
order to recreate the time scale long after the cycle time stamp was taken.
Also we need to take into account the effects of the frequency correction (NTP)
that may be in effect over the time. It may thus not be too easy to recreate
the time scale if the "some time ago" gets too long. How would we handle that
before the tick stamp becomes worthless?

Frank


Home | Main Index | Thread Index | Old Index