Greetings Dave,
On 12/12/2007, David Miller <davem@davemloft.net> wrote:
OK. Thanks for the background.
I thought that a TSC read was fairly cheap. Any messing around to
interpret it could be the responsibility of any task which actually
needs a high-resolution timestamp, couldn't it? If TSC is disabled,
then the timestamp field could be set to "invalid".
Overkill for Reno and Cubic, but useful for Vegas, LP, veno, Illinois
and YeAH which are all in the kernel. They currently use "high
resolution" timestamps which are effectively quantized to the
scheduler resolution because of the way timestamping is done --
reading a high-resolution time source when a task is scheduled.
Oh... :(
That problem should certainly be fixed as well -- I wasn't suggesting
this as an alternative. Will fixing it fix the problem of those TCP
modules suffering from CPU load from other sources?
(I'm Cc'ing this to Darryl Veitch who has often wanted driver-level
time-stamping for achieving high-resolution synchronization between
hosts.)
Cheers,
Lachlan
--
Lachlan Andrew Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820 Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html