> 2. I read in a book ("TCP/IP Illustrated" which surely referes to
> an older version of linux kernel)
Actually, the above book covers BSD networking code. A very
different animal than the linux code, I am sure.
> that the tcp_time_stamp is practically an integer number which
> counts "ticks" of 500msec and, as a consequence, it is updated
> every 500 msec... is it possible?
Under BSD that is true. I think linux has a finer-grained clock.
> how could i have a good evaluation of RTT if i can estimate only
> ticks of such a big interval?
TCP does not try to obtain a "good evaluation of RTT". TCP attempts
to determine an appropriate **retransmission timeout** (RTO), which
is a much different problem. See the following paper for an
evaluation of the impact of clock granularity (among other things)
on the standard RTO algorithm:
Mark Allman, Vern Paxson. On Estimating End-to-End Network Path
Properties. ACM SIGCOMM, September 1999, Cambridge, MA.
http://roland.grc.nasa.gov/~mallman/papers/estimation.ps
(The conclusion from the paper is that finer-grained timers provide
better RTO performance when used in conjunction with a fairly
healthy lower bound on the RTO.)
RFC 2988 outlines the standard RTO algorithm.
allman
--- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
This archive was generated by hypermail 2b29 : Wed May 30 2001 - 10:57:55 EDT