Why does windows2000 ping have a resolution of 10ms?
Duncan
n*10 ms i.e
Pinging 158.152.1.222 with 32 bytes of data:
Reply from 158.152.1.222: bytes=32 time=50ms TTL=254
Reply from 158.152.1.222: bytes=32 time=40ms TTL=254
Reply from 158.152.1.222: bytes=32 time=40ms TTL=254
Reply from 158.152.1.222: bytes=32 time=40ms TTL=254
Looking at other peoples trace routes in winnt it seems this is common
but no one seems to ask why. Is windows adding some latency or is it
just that its ping timing is inaccurate?
--
Duncan
Bob Cousins
>From here, using 2000 and XP, pinging localhost, other LAN machines,
>default gateway, and hosts on the Net, all produce pings with various
>times that are not n*10.
Thats funny, all the ping times I have ever seen from many NT and 2000
boxes have been in 10ms granularity. I assumed this was because the
resolution of the Windows Timer function is 10ms. I wonder what is
different about your systems?
--
Bob Cousins.
Please remove $NOSPAM$ to reply.
Bob Cousins
>All I can think of is it's fixed in XP, and maybe one of the service
>packs for 2000?
Hmm, thats odd, my other W2K system does use 1ms timer. Both are
supposed to be SP2. Perhaps it depends on the hardware or kernel used.
Looking on the Knowledge Base, there are quite a few bugs on ping, so
it may have been fixed in some revision. Ping also had the classic
49.7 day failure.
John Devereux
<bob@$NOSPAM$lintilla.demon.co.uk> wrote:
>Nick Webster wrote:
>
>Looking on the Knowledge Base, there are quite a few bugs on ping, so
>it may have been fixed in some revision. Ping also had the classic
>49.7 day failure.
Pings should not take that long, even with Demon...
--
John Devereux
Nigel Kendrick
> Nick Webster wrote:
>
>>From here, using 2000 and XP, pinging localhost, other LAN machines,
>
>>default gateway, and hosts on the Net, all produce pings with various
>>times that are not n*10.
>>
>
> Thats funny, all the ping times I have ever seen from many NT and 2000
> boxes have been in 10ms granularity. I assumed this was because the
> resolution of the Windows Timer function is 10ms. I wonder what is
> different about your systems?
>
NIC drivers?
NK
Nigel Kendrick
> On Wed, 06 Mar 2002 11:51:50 +0000, Bob Cousins
> <bob@$NOSPAM$lintilla.demon.co.uk> wrote:
>
>
>>Nick Webster wrote:
>>
>>Looking on the Knowledge Base, there are quite a few bugs on ping, so
>>it may have been fixed in some revision. Ping also had the classic
>>49.7 day failure.
>>
>
> Pings should not take that long, even with Demon...
>
>
"...unless they're via Demon..." shurely!?
NK
Duncan
>
>NIC drivers?
Mines a D-link DFE-530TX and I get the 10ms granularity. Maybe someone
with 1ms can tell us with what NIC?
--
Duncan
Bob Cousins
I can't imagine why the NIC would make a difference, surely the ping
application is responsible for the timing?
Simon
> Duncan wrote:
>>Nigel Kendrick <""@nkendrick.?> wrote
>>>
>>>NIC drivers?
>>
>>Mines a D-link DFE-530TX and I get the 10ms granularity. Maybe someone
>>with 1ms can tell us with what NIC?
>
> I can't imagine why the NIC would make a difference, surely the ping
> application is responsible for the timing?
My results seem to suggest that the ping application isn't responsible for the
timing. My results go from ping times accurate to 1 decimal place in
netkit-base-0.10 to almost accurate to 10ms in netkit-base-0.17 (apart from
the first ping):
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
A 3com 905b on Linux 2.4.17 using ping from netkit-base-0.10:
64 bytes from 158.152.1.222: icmp_seq=0 ttl=254 time=150.9 ms
64 bytes from 158.152.1.222: icmp_seq=1 ttl=254 time=151.5 ms
64 bytes from 158.152.1.222: icmp_seq=2 ttl=254 time=151.3 ms
A 3com 3C574-TX on FreeBSD 4.3, looks to be using ping version 1.52.2.2:
64 bytes from 158.152.1.222: icmp_seq=0 ttl=254 time=178.932 ms
64 bytes from 158.152.1.222: icmp_seq=1 ttl=254 time=186.622 ms
64 bytes from 158.152.1.222: icmp_seq=2 ttl=254 time=156.533 ms
--
Simon <si...@sis-domain.demon.co.uk> **** PGP: 099977D0
"We demand rigidly defined areas of doubt and uncertainty."
- Douglas Adams
Simon
> 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...
Bob Cousins
>* Simon <use...@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.
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.
Simon
>>* Simon <use...@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).
Duncan
>A 3Com 3C905C-TX gives 1ms granularity here, while a RealTek(?) gives n*
>10.
I just installed a 3C905C-TX-M (driver reports 3C905C-TX so I assume its
the same as yours) and despite updating driver I still get 10ms.
Is your 1ms in the same machine that got 10ms?
Anyone else getting 1ms?
--
Duncan
Will Dean
news:9XOVUIAq...@little.demon.co.uk...
>
> Anyone else getting 1ms?
The default system timer tick on NT/2K/XP machines is generally 10ms on
single-processor x86, and 15ms on multiprocessor machines.
However, it's open to any application on the system to speed this up to as
fast as 1ms, by making a specific API call. Because there is of course
only one system timer, this change will affect all applications which are
running, quite possibly including ping.
I suspect that people are seeing a difference because of something
completely unrelated running on their system which has happened to speed up
the timer.
Changes in XP mean the the ping timing is not dependant on this clock,
instead it uses either the higher resolution of the counts _between_ the
timer tick - these are at roughly 800ns on single-processor machines, or the
processor clock, which is obviously _very_ high resolution nowadays.
If you can find something (of the VC variety) to compile it, the following
code might make a difference to your system:
#include <windows.h>
#include <mmsystem.h>
#pragma comment(lib, "winmm.lib")
int main()
{
timeBeginPeriod(1);
Sleep(INFINITE);
return 0;
}
If you want me to compile if for you, email me separately.
Cheers,
Will
Duncan
>The default system timer tick on NT/2K/XP machines is generally 10ms on
>single-processor x86, and 15ms on multiprocessor machines.
>
>However, it's open to any application on the system to speed this up to as
>fast as 1ms, by making a specific API call. Because there is of course
>only one system timer, this change will affect all applications which are
>running, quite possibly including ping.
>
>If you can find something (of the VC variety) to compile it, the following
>code might make a difference to your system:
>
Thanks for that Will. I tried it but still getting 10ms in ping.
Anyone else got any ideas?
--
Duncan