latency of connection monitoring

johnpoz

look in the game.. What is the FQDN of it - how do you connect to it? Look in pfsense for the connection to the port you use int he state table, etc.

Nthly

the xbox does not tell me where i am connected to unfortunately, i have to use PfSense for it, and i am not sure i know how....
Everything in Xbox is handled behind the hood. I just launch the game and the multplayer part is activated by default. I select matchmaking and the box handles the deal... but i fear that at times i may be connected quite far away, and that impacts a bit how the game plays.

johnpoz

So do you know what port(s) the game uses? Pretty sure you could look it up for firewall for the game... Then look in your state table for destination IPs going to those port(s)

Nthly

Sure,
TCP: 53, 80, 3074
UDP: 53, 88, 500, 3074, 3075, 3544, 4500

johnpoz

Yeah some of those are BS.. 53 and 88..

But ok look for some sates in your state table for say 3074 while playing the game..

Nthly

Here are some,

185.34.107.128:3074 outgoing
184.155.109.165:3074 incoming
99.45.180.232:3074 incoming

Plus these
172.16.1.10:3074 -> 13.89.46.200:3544
13.89.46.201:3544 -> 172.16.1.10:3074

Quite a few states have around 10 packets or just over it. some states have kbps.

johnpoz

Great then ping those - what is the latency..

Grimson

Like most console games it's likely using p2p for multiplayer, which means one of the players is also the host. So latency will always vary, based on who is hosting the match and how their network holds up/is used. So if your connection is fine there is not much more you can do.

johnpoz

^ exactly!

Harvy66

@johnpoz said in latency of connection monitoring:

.02 to .04 ms??

WTF dude are you running? Never seen even lan ping times that low..

0.00003 seconds... Come on...

Are you pinging the boxes own IP? That is not really a test of network latency..
That is pfsense pinging itself.. Sure ok if that was high then something major wrong.. But that doesn't tell you how long it takes to get from pfsense to where your going and back ;)

To PFSense

C:\Utilities\hrping>hrping -q -t -c 2 -s 0 192.168.1.1
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 192.168.1.2; using ICMP echo-request, ID=2c37
Pinging 192.168.1.1 [192.168.1.1]
with 32 bytes data (60 bytes IP):

[Aborting...]

Packets: sent=32251, rcvd=32251, error=0, lost=0 (0.0% loss) in 1.444008 sec
RTTs in ms: min/avg/max/dev: 0.001 / 0.072 / 1.346 / 0.015
Bandwidth in kbytes/sec: sent=1340.061, rcvd=1340.061

Min of 0.001ms

To the first hop in my ISP

C:\Utilities\hrping>hrping -q -t -c 2 -s 0 x.x.x.x
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 192.168.1.2; using ICMP echo-request, ID=ac40
Pinging x.x.x.x [x.x.x.x]
with 32 bytes data (60 bytes IP):

[Aborting...]

Packets: sent=1181, rcvd=1179, error=0, lost=2 (0.1% loss) in 2.157322 sec
RTTs in ms: min/avg/max/dev: 0.156 / 0.256 / 1.425 / 0.144
Bandwidth in kbytes/sec: sent=32.846, rcvd=32.790

min 0.156ms

I assume the actual latency is lower, but I see packetloss from the host CPU of the core router not able to keep up.

You have to do ping floods to get really low measured latency because of CPU context switching. If you send one packet and block waiting, the kernel switching back to the thread takes a really long time relative to 1gb frame switching latency.

Like this 154us standard ping

C:\Utilities\hrping>hrping 192.168.1.1
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 192.168.1.2; using ICMP echo-request, ID=202e
Pinging 192.168.1.1 [192.168.1.1]
with 32 bytes data (60 bytes IP):

From 192.168.1.1: bytes=60 seq=0001 TTL=64 ID=4234 time=0.282ms
From 192.168.1.1: bytes=60 seq=0002 TTL=64 ID=4280 time=0.202ms
From 192.168.1.1: bytes=60 seq=0003 TTL=64 ID=8788 time=0.154ms
From 192.168.1.1: bytes=60 seq=0004 TTL=64 ID=bd93 time=0.167ms

Packets: sent=4, rcvd=4, error=0, lost=0 (0.0% loss) in 1.501189 sec
RTTs in ms: min/avg/max/dev: 0.154 / 0.201 / 0.282 / 0.049
Bandwidth in kbytes/sec: sent=0.159, rcvd=0.159

Just look at this ping to localhost. It's nearly the same as targeting my gateway

C:\Utilities\hrping>hrping -q -t -c 2 -s 0 localhost
This is hrPING v5.07.1148 by cFos Software GmbH -- http://www.cfos.de

Source address is 127.0.0.1; using ICMP echo-request, ID=1c51
Pinging localhost [127.0.0.1]
with 32 bytes data (60 bytes IP):

[Aborting...]

Packets: sent=1591, rcvd=1589, error=0, lost=0 (0.0% loss) in 0.055184 sec
RTTs in ms: min/avg/max/dev: 0.001 / 0.030 / 0.468 / 0.018
Bandwidth in kbytes/sec: sent=1729.849, rcvd=1727.674

PFSense: RTTs in ms: min/avg/max/dev: 0.001 / 0.072 / 1.346 / 0.015
Localhost: RTTs in ms: min/avg/max/dev: 0.001 / 0.030 / 0.468 / 0.018

From what I can google, a context switch on a modern CPU is about 5us. Then you mix in the CPU trying to sleep and all that fun, you're left reading 200us.

Nthly

@grimson Definitely. I am convinced that any latency will be out of my hands for more than the simple reason that it is part of the internet and that depends on the game provider (netcode and latency compensation model), but also because i do not really have the know how for it.
All i wish to know is when i am affected by higher latency so that i would leave a "bad" lobby for, possibly, a better one.

Nthly

@johnpoz said in latency of connection monitoring:

Great then ping those - what is the latency..

sorry for the few hours hiatus. I did ping the above, however packets may be dropped as no ping back is received. I heard most game providers do that, probably to lessen the load on servers that i assume may be running at close to full capacity, and, in a conspiracy theory view.... to hide the fact that servers used may be in a different region or may not be as good as players expect them to be.. LOL.
The first reason much more likely.

On PC, the game seems to run better and faster, plus ping is readily available and can be added as an overlay on a corner of the screen, but this is a whole different world.