Question Default gateway latency high

[Rayy14]

Hi, I'm getting about 1ms latency to my default gateway (RT-AX88U) with spikes sometimes up to 10ms but usually around 2-4ms with my client being the only device connected. I was wondering if it was possible to reduce this as 1ms with occasional spikes seems quite high via ethernet.

C:\Users\TechFast Australia\Downloads\hrping-v507>hrping 192.168.50.1
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 192.168.50.231; using ICMP echo-request, ID=6813
Pinging 192.168.50.1 [192.168.50.1]
with 32 bytes data (60 bytes IP):

setsockopt IP_HDRINCL failed: Error 10013: An attempt was made to access a socket in a way forbidden by its access permissions.
From 192.168.50.1: bytes=60 seq=0001 TTL=64 ID=bdc2 time=3.055ms
From 192.168.50.1: bytes=60 seq=0002 TTL=64 ID=be2a time=0.886ms
From 192.168.50.1: bytes=60 seq=0003 TTL=64 ID=bf06 time=0.832ms
From 192.168.50.1: bytes=60 seq=0004 TTL=64 ID=bf7d time=0.875ms

Packets: sent=4, rcvd=4, error=0, lost=0 (0.0% loss) in 1.511457 sec
RTTs in ms: min/avg/max/dev: 0.832 / 1.412 / 3.055 / 0.948
Bandwidth in kbytes/sec: sent=0.158, rcvd=0.158

 

[bill001g]

It is likely a measurement error. It is very hard to accurately measure stuff that is that small.

What I would do is use the -t options and leave it run.

The one you have in the post shows only the first ping and high and the reset are under 1ms.

The very first ping can be higher for a number of things like it has to update the arp table or some other overhead with getting the command started the first time.

It tends to be other processes in your pc that are causing the window that is running the ping to be delayed a bit. You would need to make sure nothing else is running on the machine to completely avoid this issue. This though is kinda a fake test since real traffic will be running where there is much more cpu load on the machine.

In the end it all doesn't matter. You are not going to be able to change the time it takes for the signals in your brain to reach your fingers and this is well over 200ms for most people so a few extra ms here and there is nothing compared to that.

 

[Rayy14]

It's not always the first ping, and I tried pinging 1.1.1.1 connected directly to my fibre box and via the router and it was consistently about 1-2ms higher. If anything I just want to stop the spikes because they do get quite annoying while gaming.

C:\Users\TechFast Australia\Downloads\hrping-v507>hrping -n 100 192.168.50.1
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 192.168.50.231; using ICMP echo-request, ID=4070
Pinging 192.168.50.1 [192.168.50.1]
with 32 bytes data (60 bytes IP):

setsockopt IP_HDRINCL failed: Error 10013: An attempt was made to access a socket in a way forbidden by its access permissions.
From 192.168.50.1: bytes=60 seq=0001 TTL=64 ID=f5ef time=0.785ms
From 192.168.50.1: bytes=60 seq=0002 TTL=64 ID=f713 time=0.765ms
From 192.168.50.1: bytes=60 seq=0003 TTL=64 ID=f7cc time=0.941ms
From 192.168.50.1: bytes=60 seq=0004 TTL=64 ID=f7e2 time=1.425ms
From 192.168.50.1: bytes=60 seq=0005 TTL=64 ID=f829 time=0.760ms
From 192.168.50.1: bytes=60 seq=0006 TTL=64 ID=f903 time=0.758ms
From 192.168.50.1: bytes=60 seq=0007 TTL=64 ID=fa62 time=0.713ms
From 192.168.50.1: bytes=60 seq=0008 TTL=64 ID=fb1b time=0.757ms
From 192.168.50.1: bytes=60 seq=0009 TTL=64 ID=fc63 time=0.769ms
From 192.168.50.1: bytes=60 seq=000a TTL=64 ID=fdf4 time=0.894ms
From 192.168.50.1: bytes=60 seq=000b TTL=64 ID=ff55 time=1.048ms
From 192.168.50.1: bytes=60 seq=000c TTL=64 ID=002f time=0.787ms
From 192.168.50.1: bytes=60 seq=000d TTL=64 ID=00ec time=0.882ms
From 192.168.50.1: bytes=60 seq=000e TTL=64 ID=020d time=0.809ms
From 192.168.50.1: bytes=60 seq=000f TTL=64 ID=0305 time=0.807ms
From 192.168.50.1: bytes=60 seq=0010 TTL=64 ID=0427 time=0.760ms
From 192.168.50.1: bytes=60 seq=0011 TTL=64 ID=0600 time=0.901ms
From 192.168.50.1: bytes=60 seq=0012 TTL=64 ID=060b time=0.836ms
From 192.168.50.1: bytes=60 seq=0013 TTL=64 ID=0768 time=0.735ms
From 192.168.50.1: bytes=60 seq=0014 TTL=64 ID=08ba time=0.799ms
From 192.168.50.1: bytes=60 seq=0015 TTL=64 ID=099a time=1.782ms
From 192.168.50.1: bytes=60 seq=0016 TTL=64 ID=0b50 time=0.935ms
From 192.168.50.1: bytes=60 seq=0017 TTL=64 ID=0ba5 time=0.714ms
From 192.168.50.1: bytes=60 seq=0018 TTL=64 ID=0c91 time=0.849ms
From 192.168.50.1: bytes=60 seq=0019 TTL=64 ID=0e57 time=0.800ms
From 192.168.50.1: bytes=60 seq=001a TTL=64 ID=0f84 time=0.873ms
From 192.168.50.1: bytes=60 seq=001b TTL=64 ID=1039 time=0.900ms
From 192.168.50.1: bytes=60 seq=001c TTL=64 ID=11c7 time=1.110ms
From 192.168.50.1: bytes=60 seq=001d TTL=64 ID=13a3 time=0.792ms
From 192.168.50.1: bytes=60 seq=001e TTL=64 ID=14ea time=0.841ms
From 192.168.50.1: bytes=60 seq=001f TTL=64 ID=165a time=0.715ms
From 192.168.50.1: bytes=60 seq=0020 TTL=64 ID=16b1 time=1.029ms
From 192.168.50.1: bytes=60 seq=0021 TTL=64 ID=16fa time=0.878ms
From 192.168.50.1: bytes=60 seq=0022 TTL=64 ID=173b time=0.733ms
From 192.168.50.1: bytes=60 seq=0023 TTL=64 ID=185f time=0.700ms
From 192.168.50.1: bytes=60 seq=0024 TTL=64 ID=1a5a time=0.838ms
From 192.168.50.1: bytes=60 seq=0025 TTL=64 ID=1bd2 time=0.656ms
From 192.168.50.1: bytes=60 seq=0026 TTL=64 ID=1cb3 time=0.849ms
From 192.168.50.1: bytes=60 seq=0027 TTL=64 ID=1d76 time=0.779ms
From 192.168.50.1: bytes=60 seq=0028 TTL=64 ID=1e94 time=0.793ms
From 192.168.50.1: bytes=60 seq=0029 TTL=64 ID=1ea8 time=0.753ms
From 192.168.50.1: bytes=60 seq=002a TTL=64 ID=2055 time=0.821ms
From 192.168.50.1: bytes=60 seq=002b TTL=64 ID=20e1 time=0.788ms
From 192.168.50.1: bytes=60 seq=002c TTL=64 ID=2188 time=0.766ms
From 192.168.50.1: bytes=60 seq=002d TTL=64 ID=21a7 time=0.783ms
From 192.168.50.1: bytes=60 seq=002e TTL=64 ID=2221 time=0.754ms
From 192.168.50.1: bytes=60 seq=002f TTL=64 ID=2271 time=0.912ms
From 192.168.50.1: bytes=60 seq=0030 TTL=64 ID=2365 time=0.760ms
From 192.168.50.1: bytes=60 seq=0031 TTL=64 ID=254b time=0.725ms
From 192.168.50.1: bytes=60 seq=0032 TTL=64 ID=268e time=0.875ms
From 192.168.50.1: bytes=60 seq=0033 TTL=64 ID=26be time=0.667ms
From 192.168.50.1: bytes=60 seq=0034 TTL=64 ID=279f time=1.212ms
From 192.168.50.1: bytes=60 seq=0035 TTL=64 ID=280d time=0.891ms
From 192.168.50.1: bytes=60 seq=0036 TTL=64 ID=281c time=0.687ms
From 192.168.50.1: bytes=60 seq=0037 TTL=64 ID=2852 time=0.752ms
From 192.168.50.1: bytes=60 seq=0038 TTL=64 ID=29f5 time=0.854ms
From 192.168.50.1: bytes=60 seq=0039 TTL=64 ID=2b7d time=0.709ms
From 192.168.50.1: bytes=60 seq=003a TTL=64 ID=2c88 time=0.922ms
From 192.168.50.1: bytes=60 seq=003b TTL=64 ID=2d03 time=0.823ms
From 192.168.50.1: bytes=60 seq=003c TTL=64 ID=2d0b time=1.141ms
From 192.168.50.1: bytes=60 seq=003d TTL=64 ID=2e9f time=0.694ms
From 192.168.50.1: bytes=60 seq=003e TTL=64 ID=307d time=0.873ms
From 192.168.50.1: bytes=60 seq=003f TTL=64 ID=31fe time=0.757ms
From 192.168.50.1: bytes=60 seq=0040 TTL=64 ID=3364 time=0.801ms
From 192.168.50.1: bytes=60 seq=0041 TTL=64 ID=3452 time=0.756ms
From 192.168.50.1: bytes=60 seq=0042 TTL=64 ID=358c time=0.808ms
From 192.168.50.1: bytes=60 seq=0043 TTL=64 ID=3677 time=0.767ms
From 192.168.50.1: bytes=60 seq=0044 TTL=64 ID=386e time=0.865ms
From 192.168.50.1: bytes=60 seq=0045 TTL=64 ID=38c4 time=0.735ms
From 192.168.50.1: bytes=60 seq=0046 TTL=64 ID=3a6e time=0.877ms
From 192.168.50.1: bytes=60 seq=0047 TTL=64 ID=3bbc time=0.862ms
From 192.168.50.1: bytes=60 seq=0048 TTL=64 ID=3bd5 time=0.869ms
From 192.168.50.1: bytes=60 seq=0049 TTL=64 ID=3ca0 time=0.822ms
From 192.168.50.1: bytes=60 seq=004a TTL=64 ID=3d93 time=0.803ms
From 192.168.50.1: bytes=60 seq=004b TTL=64 ID=3f05 time=0.786ms
From 192.168.50.1: bytes=60 seq=004c TTL=64 ID=4065 time=0.741ms
From 192.168.50.1: bytes=60 seq=004d TTL=64 ID=411e time=2.014ms
From 192.168.50.1: bytes=60 seq=004e TTL=64 ID=4269 time=0.922ms
From 192.168.50.1: bytes=60 seq=004f TTL=64 ID=42f0 time=0.795ms
From 192.168.50.1: bytes=60 seq=0050 TTL=64 ID=44ab time=1.385ms
From 192.168.50.1: bytes=60 seq=0051 TTL=64 ID=4583 time=0.730ms
From 192.168.50.1: bytes=60 seq=0052 TTL=64 ID=460e time=0.802ms
From 192.168.50.1: bytes=60 seq=0053 TTL=64 ID=477c time=0.766ms
From 192.168.50.1: bytes=60 seq=0054 TTL=64 ID=48b2 time=0.867ms
From 192.168.50.1: bytes=60 seq=0055 TTL=64 ID=48d7 time=0.802ms
From 192.168.50.1: bytes=60 seq=0056 TTL=64 ID=48db time=0.878ms
From 192.168.50.1: bytes=60 seq=0057 TTL=64 ID=49bc time=10.768ms
From 192.168.50.1: bytes=60 seq=0058 TTL=64 ID=49c8 time=0.806ms
From 192.168.50.1: bytes=60 seq=0059 TTL=64 ID=4bb8 time=0.759ms
From 192.168.50.1: bytes=60 seq=005a TTL=64 ID=4d5f time=0.801ms
From 192.168.50.1: bytes=60 seq=005b TTL=64 ID=4e06 time=0.766ms
From 192.168.50.1: bytes=60 seq=005c TTL=64 ID=4f96 time=0.864ms
From 192.168.50.1: bytes=60 seq=005d TTL=64 ID=50e4 time=0.947ms
From 192.168.50.1: bytes=60 seq=005e TTL=64 ID=5143 time=0.790ms
From 192.168.50.1: bytes=60 seq=005f TTL=64 ID=5183 time=1.284ms
From 192.168.50.1: bytes=60 seq=0060 TTL=64 ID=51ce time=0.964ms
From 192.168.50.1: bytes=60 seq=0061 TTL=64 ID=52a1 time=0.908ms
From 192.168.50.1: bytes=60 seq=0062 TTL=64 ID=53b7 time=0.777ms
From 192.168.50.1: bytes=60 seq=0063 TTL=64 ID=558b time=0.760ms
From 192.168.50.1: bytes=60 seq=0064 TTL=64 ID=5647 time=0.847ms

Packets: sent=100, rcvd=100, error=0, lost=0 (0.0% loss) in 49.515676 sec
RTTs in ms: min/avg/max/dev: 0.656 / 0.959 / 10.768 / 1.005
Bandwidth in kbytes/sec: sent=0.121, rcvd=0.121

 

[bill001g]

You can not detect a 10ms delay. Generally you have to over 100ms to be able to see anything and that is only in games that have a very high tick rate.

There is nothing you can do about this. It is either some other process on your machine causing it or maybe a packet from another device in your house was talking to the router at that exact instant so yours was delayed.
You will note that your average is still very very good.

The type that cause issues for a game are very large spikes like 100s of ms. The also tend to be 2 or 3 packets in a row. These tend to be caused by some overloaded connection in the path in the ISP.

If you were getting packet loss that is very different and a indicator of either a defective cable or maybe some issue with a port.

 

[Rayy14]

That's incorrect, when it spikes it's very very noticeable in game even when it's by 10. And again I'm the only client connected so it wouldn't be another device.

 

[kerberos_20]

try different ethernet cable, avoid using copper clad aluminium

 

[Rayy14]

I ordered a CAT6 cable that's full copper (not CCA), hopefully that fixes it. I don't think my existing one is CCA but it is CAT5e which shouldn't make a difference anyways.

 

[kanewolf]

I ordered a CAT6 cable that's full copper (not CCA), hopefully that fixes it. I don't think my existing one is CCA but it is CAT5e which shouldn't make a difference anyways.

First the error you are getting about socekt options is because you aren't running hrping as admin. That is listed in the system requirements page -- https://www.cfos.de/en/ping/ping.htm
I don't know if that will mess with the timing.

 

[Rayy14]

First the error you are getting about socekt options is because you aren't running hrping as admin. That is listed in the system requirements page -- https://www.cfos.de/en/ping/ping.htm
I don't know if that will mess with the timing.

Ah ok that's good to know.

C:\Users\TechFast Australia\Downloads\hrping-v507>hrping -n 100 192.168.50.1
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 192.168.50.231; using ICMP echo-request, ID=f07e
Pinging 192.168.50.1 [192.168.50.1]
with 32 bytes data (60 bytes IP):

From 192.168.50.1: bytes=60 seq=0001 TTL=64 ID=e017 time=1.564ms
From 192.168.50.1: bytes=60 seq=0002 TTL=64 ID=e20f time=1.428ms
From 192.168.50.1: bytes=60 seq=0003 TTL=64 ID=e37e time=2.399ms
From 192.168.50.1: bytes=60 seq=0004 TTL=64 ID=e3da time=1.136ms
From 192.168.50.1: bytes=60 seq=0005 TTL=64 ID=e48e time=1.638ms
From 192.168.50.1: bytes=60 seq=0006 TTL=64 ID=e571 time=1.037ms
From 192.168.50.1: bytes=60 seq=0007 TTL=64 ID=e6ba time=1.353ms
From 192.168.50.1: bytes=60 seq=0008 TTL=64 ID=e753 time=1.614ms
From 192.168.50.1: bytes=60 seq=0009 TTL=64 ID=e942 time=1.488ms
From 192.168.50.1: bytes=60 seq=000a TTL=64 ID=ea33 time=0.909ms
From 192.168.50.1: bytes=60 seq=000b TTL=64 ID=ea79 time=0.802ms
From 192.168.50.1: bytes=60 seq=000c TTL=64 ID=ea81 time=0.970ms
From 192.168.50.1: bytes=60 seq=000d TTL=64 ID=eac9 time=1.063ms
From 192.168.50.1: bytes=60 seq=000e TTL=64 ID=ec6e time=0.936ms
From 192.168.50.1: bytes=60 seq=000f TTL=64 ID=edf9 time=1.592ms
From 192.168.50.1: bytes=60 seq=0010 TTL=64 ID=ee0e time=9.552ms
From 192.168.50.1: bytes=60 seq=0011 TTL=64 ID=efbc time=1.417ms
From 192.168.50.1: bytes=60 seq=0012 TTL=64 ID=efd8 time=3.624ms
From 192.168.50.1: bytes=60 seq=0013 TTL=64 ID=f160 time=1.419ms
From 192.168.50.1: bytes=60 seq=0014 TTL=64 ID=f325 time=1.055ms
From 192.168.50.1: bytes=60 seq=0015 TTL=64 ID=f357 time=1.532ms
From 192.168.50.1: bytes=60 seq=0016 TTL=64 ID=f52d time=11.199ms
From 192.168.50.1: bytes=60 seq=0017 TTL=64 ID=f62e time=1.372ms
From 192.168.50.1: bytes=60 seq=0018 TTL=64 ID=f71a time=1.084ms
From 192.168.50.1: bytes=60 seq=0019 TTL=64 ID=f8c3 time=1.803ms
From 192.168.50.1: bytes=60 seq=001a TTL=64 ID=fa0e time=1.381ms
From 192.168.50.1: bytes=60 seq=001b TTL=64 ID=fb9b time=0.991ms
From 192.168.50.1: bytes=60 seq=001c TTL=64 ID=fcb4 time=1.088ms
From 192.168.50.1: bytes=60 seq=001d TTL=64 ID=fe75 time=0.924ms
From 192.168.50.1: bytes=60 seq=001e TTL=64 ID=fe81 time=1.199ms
From 192.168.50.1: bytes=60 seq=001f TTL=64 ID=fed6 time=1.710ms
From 192.168.50.1: bytes=60 seq=0020 TTL=64 ID=0090 time=1.120ms
From 192.168.50.1: bytes=60 seq=0021 TTL=64 ID=00e7 time=1.495ms
From 192.168.50.1: bytes=60 seq=0022 TTL=64 ID=013e time=0.903ms
From 192.168.50.1: bytes=60 seq=0023 TTL=64 ID=021f time=1.517ms
From 192.168.50.1: bytes=60 seq=0024 TTL=64 ID=0220 time=1.389ms
From 192.168.50.1: bytes=60 seq=0025 TTL=64 ID=022b time=1.456ms
From 192.168.50.1: bytes=60 seq=0026 TTL=64 ID=02b8 time=1.017ms
From 192.168.50.1: bytes=60 seq=0027 TTL=64 ID=048e time=1.435ms
From 192.168.50.1: bytes=60 seq=0028 TTL=64 ID=0575 time=1.128ms
From 192.168.50.1: bytes=60 seq=0029 TTL=64 ID=05ae time=0.898ms
From 192.168.50.1: bytes=60 seq=002a TTL=64 ID=061b time=1.118ms
From 192.168.50.1: bytes=60 seq=002b TTL=64 ID=0706 time=1.517ms
From 192.168.50.1: bytes=60 seq=002c TTL=64 ID=0899 time=1.124ms
From 192.168.50.1: bytes=60 seq=002d TTL=64 ID=08b7 time=1.413ms
From 192.168.50.1: bytes=60 seq=002e TTL=64 ID=090a time=1.357ms
From 192.168.50.1: bytes=60 seq=002f TTL=64 ID=0a34 time=0.946ms
From 192.168.50.1: bytes=60 seq=0030 TTL=64 ID=0b1a time=1.200ms
From 192.168.50.1: bytes=60 seq=0031 TTL=64 ID=0b29 time=1.513ms
From 192.168.50.1: bytes=60 seq=0032 TTL=64 ID=0c58 time=2.049ms
From 192.168.50.1: bytes=60 seq=0033 TTL=64 ID=0d7c time=1.522ms
From 192.168.50.1: bytes=60 seq=0034 TTL=64 ID=0e31 time=1.074ms
From 192.168.50.1: bytes=60 seq=0035 TTL=64 ID=0ef8 time=1.431ms
From 192.168.50.1: bytes=60 seq=0036 TTL=64 ID=0f4b time=1.033ms
From 192.168.50.1: bytes=60 seq=0037 TTL=64 ID=1000 time=1.502ms
From 192.168.50.1: bytes=60 seq=0038 TTL=64 ID=1158 time=1.343ms
From 192.168.50.1: bytes=60 seq=0039 TTL=64 ID=12e3 time=1.339ms
From 192.168.50.1: bytes=60 seq=003a TTL=64 ID=12f1 time=1.181ms
From 192.168.50.1: bytes=60 seq=003b TTL=64 ID=1468 time=1.450ms
From 192.168.50.1: bytes=60 seq=003c TTL=64 ID=146e time=1.260ms
From 192.168.50.1: bytes=60 seq=003d TTL=64 ID=15c1 time=1.589ms
From 192.168.50.1: bytes=60 seq=003e TTL=64 ID=1767 time=1.121ms
From 192.168.50.1: bytes=60 seq=003f TTL=64 ID=1845 time=1.728ms
From 192.168.50.1: bytes=60 seq=0040 TTL=64 ID=18ec time=1.089ms
From 192.168.50.1: bytes=60 seq=0041 TTL=64 ID=1a35 time=1.236ms
From 192.168.50.1: bytes=60 seq=0042 TTL=64 ID=1a9e time=1.386ms
From 192.168.50.1: bytes=60 seq=0043 TTL=64 ID=1aac time=1.008ms
From 192.168.50.1: bytes=60 seq=0044 TTL=64 ID=1b44 time=1.684ms
From 192.168.50.1: bytes=60 seq=0045 TTL=64 ID=1c4e time=1.513ms
From 192.168.50.1: bytes=60 seq=0046 TTL=64 ID=1cda time=0.847ms
From 192.168.50.1: bytes=60 seq=0047 TTL=64 ID=1ce1 time=1.039ms
From 192.168.50.1: bytes=60 seq=0048 TTL=64 ID=1d2a time=0.987ms
From 192.168.50.1: bytes=60 seq=0049 TTL=64 ID=1dec time=1.400ms
From 192.168.50.1: bytes=60 seq=004a TTL=64 ID=1e10 time=1.028ms
From 192.168.50.1: bytes=60 seq=004b TTL=64 ID=1ff6 time=1.540ms
From 192.168.50.1: bytes=60 seq=004c TTL=64 ID=20e7 time=1.414ms
From 192.168.50.1: bytes=60 seq=004d TTL=64 ID=2193 time=1.271ms
From 192.168.50.1: bytes=60 seq=004e TTL=64 ID=237e time=0.908ms
From 192.168.50.1: bytes=60 seq=004f TTL=64 ID=240c time=1.383ms
From 192.168.50.1: bytes=60 seq=0050 TTL=64 ID=246f time=1.067ms
From 192.168.50.1: bytes=60 seq=0051 TTL=64 ID=24a0 time=1.585ms
From 192.168.50.1: bytes=60 seq=0052 TTL=64 ID=25a7 time=1.712ms
From 192.168.50.1: bytes=60 seq=0053 TTL=64 ID=25df time=1.414ms
From 192.168.50.1: bytes=60 seq=0054 TTL=64 ID=2791 time=3.525ms
From 192.168.50.1: bytes=60 seq=0055 TTL=64 ID=283e time=4.254ms
From 192.168.50.1: bytes=60 seq=0056 TTL=64 ID=29f0 time=1.473ms
From 192.168.50.1: bytes=60 seq=0057 TTL=64 ID=2b18 time=0.791ms
From 192.168.50.1: bytes=60 seq=0058 TTL=64 ID=2b38 time=0.998ms
From 192.168.50.1: bytes=60 seq=0059 TTL=64 ID=2bc7 time=1.452ms
From 192.168.50.1: bytes=60 seq=005a TTL=64 ID=2d5c time=1.315ms
From 192.168.50.1: bytes=60 seq=005b TTL=64 ID=2e2e time=1.449ms
From 192.168.50.1: bytes=60 seq=005c TTL=64 ID=2fef time=1.203ms
From 192.168.50.1: bytes=60 seq=005d TTL=64 ID=31b9 time=1.617ms
From 192.168.50.1: bytes=60 seq=005e TTL=64 ID=3227 time=2.343ms
From 192.168.50.1: bytes=60 seq=005f TTL=64 ID=334e time=1.717ms
From 192.168.50.1: bytes=60 seq=0060 TTL=64 ID=33ac time=5.213ms
From 192.168.50.1: bytes=60 seq=0061 TTL=64 ID=33ff time=1.342ms
From 192.168.50.1: bytes=60 seq=0062 TTL=64 ID=3417 time=1.009ms
From 192.168.50.1: bytes=60 seq=0063 TTL=64 ID=3589 time=1.936ms
From 192.168.50.1: bytes=60 seq=0064 TTL=64 ID=36db time=1.080ms

Packets: sent=100, rcvd=100, error=0, lost=0 (0.0% loss) in 49.512012 sec
RTTs in ms: min/avg/max/dev: 0.791 / 1.616 / 11.199 / 1.412
Bandwidth in kbytes/sec: sent=0.121, rcvd=0.121

 

[bill001g]

What happens if you use a normal ping command rather than that program. The ping command in windows is a very simple program and is not affected as much by cpu load etc.

I just noticed that this is same company that makes CFOSspeed. Hopefully you did not install that software or anything similar that comes on many motherboards. There is a lot of overhead in this software because all data must pass through it and it can cause random delays.
The stuff that comes bundled with motherboards has many names but anything that claims it can reduce the latency you need to uninstall. Asus tends to be the biggest offender, I think they call it lanfirst or something now. They change the name now and then.

 

[Rayy14]

What happens if you use a normal ping command rather than that program. The ping command in windows is a very simple program and is not affected as much by cpu load etc.

I just noticed that this is same company that makes CFOSspeed. Hopefully you did not install that software or anything similar that comes on many motherboards. There is a lot of overhead in this software because all data must pass through it and it can cause random delays.
The stuff that comes bundled with motherboards has many names but anything that claims it can reduce the latency you need to uninstall. Asus tends to be the biggest offender, I think they call it lanfirst or something now. They change the name now and then.

I didn't install anything but hrping, and my motherboard doesn't come with anything like that. I double-checked my installed programs and don't see any bloatware.

C:\Users\TechFast Australia>ping -n 20 192.168.50.1

Pinging 192.168.50.1 with 32 bytes of data:
Reply from 192.168.50.1: bytes=32 time<1ms TTL=64
Reply from 192.168.50.1: bytes=32 time=1ms TTL=64
Reply from 192.168.50.1: bytes=32 time<1ms TTL=64
Reply from 192.168.50.1: bytes=32 time=1ms TTL=64
Reply from 192.168.50.1: bytes=32 time=1ms TTL=64
Reply from 192.168.50.1: bytes=32 time<1ms TTL=64
Reply from 192.168.50.1: bytes=32 time<1ms TTL=64
Reply from 192.168.50.1: bytes=32 time=1ms TTL=64
Reply from 192.168.50.1: bytes=32 time<1ms TTL=64
Reply from 192.168.50.1: bytes=32 time=1ms TTL=64
Reply from 192.168.50.1: bytes=32 time<1ms TTL=64
Reply from 192.168.50.1: bytes=32 time<1ms TTL=64
Reply from 192.168.50.1: bytes=32 time=11ms TTL=64
Reply from 192.168.50.1: bytes=32 time<1ms TTL=64
Reply from 192.168.50.1: bytes=32 time=1ms TTL=64
Reply from 192.168.50.1: bytes=32 time<1ms TTL=64
Reply from 192.168.50.1: bytes=32 time=1ms TTL=64
Reply from 192.168.50.1: bytes=32 time<1ms TTL=64
Reply from 192.168.50.1: bytes=32 time=1ms TTL=64
Reply from 192.168.50.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.50.1:
Packets: Sent = 20, Received = 20, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 11ms, Average = 0ms

 

[bill001g]

That is very strange.

What this implies is there is some issue with the router delaying the response for some reason. It could although unlikely be that the pc is receiving the data but leaving it sit in the data buffer until the process running the ping is allowed to run.

What you can do is load wireshark and put in a filter to capture only ICMP. This has a very detailed timestamp and you can tell exactly when the packet leaves the machine and when the response comes back. There are tools to generate a report showing the latency between packets so you don't have to do it by hand.

Since this capture is done just before the data is sent to the ethernet port and as soon as it arrives in the ethernet port it should hide any delays caused by the computer. Any delays you see will be the router. If for example you were to configure the firewall to drop ping traffic from the router wireshark will still see it because it intercepts well before any software gets to see the data. So something like the ping command having some issue will also be hidden.

If the delay is being caused by the router I don't know what you do, buy a different router maybe or upgrade firmware. It is not uncommon for a router to be configured to treat ICMP/ping as low priority and if it has anything better to do it will delay responding to the ping. This is extremely common on a commercial router because ping can be used as a denial of service attack. Home routers may have this feature or there is something else that is delaying the data.

If something like wireshark does not see it then it is some software in your machine. You can verify it by booting a linux USB stick. This runs completely from the USB and does not damage your windows install. Something simple like a ping command will not be affected by the OS running from a USB device. This though just proves it is something in windows it does not tell you what.

Again you are going to a huge effort to find a tiny variation that only happens every 10-15 seconds.

 

[kanewolf]

That is very strange.

What this implies is there is some issue with the router delaying the response for some reason. It could although unlikely be that the pc is receiving the data but leaving it sit in the data buffer until the process running the ping is allowed to run.

What you can do is load wireshark and put in a filter to capture only ICMP. This has a very detailed timestamp and you can tell exactly when the packet leaves the machine and when the response comes back. There are tools to generate a report showing the latency between packets so you don't have to do it by hand.

Since this capture is done just before the data is sent to the ethernet port and as soon as it arrives in the ethernet port it should hide any delays caused by the computer. Any delays you see will be the router. If for example you were to configure the firewall to drop ping traffic from the router wireshark will still see it because it intercepts well before any software gets to see the data. So something like the ping command having some issue will also be hidden.

If the delay is being caused by the router I don't know what you do, buy a different router maybe or upgrade firmware. It is not uncommon for a router to be configured to treat ICMP/ping as low priority and if it has anything better to do it will delay responding to the ping. This is extremely common on a commercial router because ping can be used as a denial of service attack. Home routers may have this feature or there is something else that is delaying the data.

If something like wireshark does not see it then it is some software in your machine. You can verify it by booting a linux USB stick. This runs completely from the USB and does not damage your windows install. Something simple like a ping command will not be affected by the OS running from a USB device. This though just proves it is something in windows it does not tell you what.

Again you are going to a huge effort to find a tiny variation that only happens every 10-15 seconds.

I would do a factory reset on the router, and set a minimal config. Just set admin password, SSID and WIFI password. Itis possible thst some setting is causing this. Factory reset should eliminate that posdibility. Do the factory reset then retest.

 

[Rayy14]

Just got a new ethernet cable, same results and now for some reason my stable pings are significantly higher too

C:\Users\TechFast Australia>ping 192.168.50.1

Pinging 192.168.50.1 with 32 bytes of data:
Reply from 192.168.50.1: bytes=32 time=5ms TTL=64
Reply from 192.168.50.1: bytes=32 time=4ms TTL=64
Reply from 192.168.50.1: bytes=32 time=3ms TTL=64
Reply from 192.168.50.1: bytes=32 time=15ms TTL=64

Tried with my old ethernet cable as well with the same results.

C:\Users\TechFast Australia>ping 192.168.50.1

Pinging 192.168.50.1 with 32 bytes of data:
Reply from 192.168.50.1: bytes=32 time=3ms TTL=64
Reply from 192.168.50.1: bytes=32 time=3ms TTL=64
Reply from 192.168.50.1: bytes=32 time=19ms TTL=64
Reply from 192.168.50.1: bytes=32 time=3ms TTL=64

Factory resetting causes same results, so does reverting back to stock firmware instead of Merlin. I'll try Wiresharking it once I have a bit more time.

Again you are going to a huge effort to find a tiny variation that only happens every 10-15 seconds.

It causes the physics based game I play to compensate for the lag spike by increasing the buffer, making the game lag quite a lot until i reset the input buffer which requires me to pause an online game. This happening every 15 seconds is quite frequent.

 

[bill001g]

A bad cable does not delay traffic it just drops it unlike wifi that tries to do error correction which causes delay. A ethernet cable has no place to store the data it always transmit data at one fixed speed which is some fraction of the speed of light.

This is either going to be the PC or the router causing this.

Maybe try booting the pc into linux by booting a USB image. These are designed to run completely from the usb stick. The ping command under linux is slightly different that windows, it takes different option but a simple ping 192.168.50.1 with no options is the same as using the -t on windows.

You could also try a different ethernet connected pc if you have one. Try to ping the router ip from this pc. If you get similar results you start to suspect the router is causing this.\
Really any other ethernet connected device that will respond to ping will help to test to. The traffic going between the lan ports is passing a simple switch in the router which will not delay traffic even if the cpu in the router is busy.