🚀 go-pugleaf

* Bob Cousins <bob@$nospam$lintilla.demon.co.uk> wrote:
> Simon wrote:
>>* Simon <usenet@sis-domain.demon.co.uk> wrote:
>>> An Intel EtherExpress Pro 100 on Linux 2.4.5 using ping from 
>>> netkit-base-0.17:
>>> 
>>> 64 octets from 158.152.1.222: icmp_seq=0 ttl=255 time=155.4 ms
>>> 64 octets from 158.152.1.222: icmp_seq=1 ttl=255 time=140.0 ms
>>> 64 octets from 158.152.1.222: icmp_seq=2 ttl=255 time=150.0 ms
>>> ...results carry on accurate to 10ms until the ping is stopped
>>
>>To follow up my own post, this is over the PPP stack (using pppd 2.4.1) and
>>not the NIC.  Must acquire more caffeine...
> 
> Ooops..
> 
> Actually, I am fairly certain the ping application calculates the time
> interval, but it is possible the NIC driver affects the resolution,
> for example depending on how interrupts get handled and how the
> request queues are managed.

Looking at the ping source code, it looks as though the application uses the
system timer to calculate the reply times.  From this, I think the most
likely causes might be either interrupts or drivers.

> Linux source code is obviously freely available, if you look at the
> source to ping you will see it uses the system timer. The Unix socket
> interface does not carry timestamps of packets. Winsock derives from
> the Unix socket API, so is similar.

This agrees with my knowledge of the TCP & IP protocols.  If I can get my head
around the PPP and/or serial port drivers in the kernel, I'll see if those
would affect the timing in any way (the Linux box with more accurate timing
is running a newer version of the kernel).


-- 
 Simon <simon@sis-domain.demon.co.uk> **** PGP: 099977D0
"We demand rigidly defined areas of doubt and uncertainty."
                  - Douglas Adams