Speed of TCPObject
by Thomas Bang · in Torque Game Engine · 11/25/2009 (7:40 am) · 15 replies
I have a TCPServer, a TCPClient and a TCPProxy.
The TCPClient connects to a TCPServer and after that, the TCPClient is sending a short text (length 32) to the TCPProxy and the TCPProxy is sending the same text back to the TCPClient. I use that to measure the time between sending and receiving the text.
The order:
1. Start time measurement.
2. Send text from TCPClient to TCPProxy.
3. Send text back from TCPProxy to TCPClient.
4. Stop time measurement.
In my LAN i get a time difference of a little bit about 15 ms.
BUT: When i use the normal ping-tool from windows xp i get a time difference of less than 1 ms.
Any ideas?
The TCPClient connects to a TCPServer and after that, the TCPClient is sending a short text (length 32) to the TCPProxy and the TCPProxy is sending the same text back to the TCPClient. I use that to measure the time between sending and receiving the text.
The order:
1. Start time measurement.
2. Send text from TCPClient to TCPProxy.
3. Send text back from TCPProxy to TCPClient.
4. Stop time measurement.
In my LAN i get a time difference of a little bit about 15 ms.
BUT: When i use the normal ping-tool from windows xp i get a time difference of less than 1 ms.
Any ideas?
#2
Instead to use TCPObject to measure the ping, i tried it also with GameConnection. It works, but there is a problem: I have a loaded mission as the background of the mainmenu. So i cant connect twice.
I talked to another guy and he told me, that the difference can be, when i start the time measurement in frame 1 and the sending of the text in frame 2.
11/25/2009 (8:37 am)
Uh, i guess it is not a good idea to change the networking code. Instead to use TCPObject to measure the ping, i tried it also with GameConnection. It works, but there is a problem: I have a loaded mission as the background of the mainmenu. So i cant connect twice.
I talked to another guy and he told me, that the difference can be, when i start the time measurement in frame 1 and the sending of the text in frame 2.
#3
Adding a network hop is likely to balloon the numbers much furhter.
I'm not sure what you are trying to measure/acheive, but this comparing Torque's response time via it's (broken) TCPObject vs. a regular ICMP ping is apples to oranges.
11/27/2009 (2:15 am)
ICMP vs. a real round-trip with actual payloads is likely to be substantially different.Adding a network hop is likely to balloon the numbers much furhter.
I'm not sure what you are trying to measure/acheive, but this comparing Torque's response time via it's (broken) TCPObject vs. a regular ICMP ping is apples to oranges.
#4
My own masterserver!!!
I want to measure the ping between two PC's. I am able to get a regular ping but in this case i can not detect if the game is running or not on the ping'ed PC.
With this in mind i tried to use TCPObject. The first PC sends a special string to the second PC. The second PC receives the string and sends the same String back to the first PC. This way i can ensure that the game is running.
But there is a problem: TCPObject works in my LAN. But not over the internet.
11/27/2009 (3:18 am)
Quote:
I'm not sure what you are trying to measure/acheive, ...
My own masterserver!!!
I want to measure the ping between two PC's. I am able to get a regular ping but in this case i can not detect if the game is running or not on the ping'ed PC.
With this in mind i tried to use TCPObject. The first PC sends a special string to the second PC. The second PC receives the string and sends the same String back to the first PC. This way i can ensure that the game is running.
But there is a problem: TCPObject works in my LAN. But not over the internet.
#5
11/27/2009 (6:39 am)
TCP will always be slower than ICMP and UDP. You should do your game ping with UDP. Don't ask me how to do that though :) 
#6
11/27/2009 (6:40 am)
You have to take into account the time required for the DNS resolution, connection... and then you will see it can be very different between a LAN test and an internet test.
#7
11/27/2009 (6:42 am)
I dont get a connection over the internet. Only in the LAN. But i dont know why. 
#8
11/27/2009 (6:56 am)
as an experiment maybe try using the ip address instead of hostname ? or maybe you already are.
#9
11/27/2009 (6:59 am)
I am working always with IP's. So i dont need DNS.
#10
Now i have to modify my masterserver. I thought about to send a heartbeat only one time to the masterserver.
OK, not a problem.
11/27/2009 (7:24 am)
Before i forget: I wrote a function which uses ICMP to ping another PC. It works very well. I get the same milliseconds like the normal ping-tool from Windows XP. Everything seems to be fine. Now i have to modify my masterserver. I thought about to send a heartbeat only one time to the masterserver.
OK, not a problem.
#11
11/27/2009 (10:24 am)
Regarding round trip time: keep in mind unless you're running this test from a separate thread, the response time will be limited by Torque's framerate. You said you're running a mission as a background? Then you're probably not getting hundreds of frames per second. If your framerate is a (fairly reasonable) 60 fps, you cannot expect a ping lower than 16ms. Because there will be a 16ms delay between sending on one frame cycle and receiving on the next.
#12
In the final version i will move the ping-functions into a separate thread. Should not be a problem.
In the meantime i got another problem: The firewalls of some hosts block ping requests (ICMP).
OK, time to summarize:
- get the ping with GameConnection or with TCPObject is not a good idea
(the results are not very accurate)
- now i have a ping-function with ICMP
(the results are equal to the results of the ping-tool in Windows)
- the working ping-function will be multithreaded
(the results are independent from the framerate of the game)
- some hosts do not respond to ping-requests (ICMP)
(if this is the case, the ping-value of the list from the masterserver will be blank for this host)
11/27/2009 (10:52 am)
Scott, that makes sense. In the final version i will move the ping-functions into a separate thread. Should not be a problem.
In the meantime i got another problem: The firewalls of some hosts block ping requests (ICMP).
OK, time to summarize:
- get the ping with GameConnection or with TCPObject is not a good idea
(the results are not very accurate)
- now i have a ping-function with ICMP
(the results are equal to the results of the ping-tool in Windows)
- the working ping-function will be multithreaded
(the results are independent from the framerate of the game)
- some hosts do not respond to ping-requests (ICMP)
(if this is the case, the ping-value of the list from the masterserver will be blank for this host)
#13
Technically, if you're just looking to evaluate the performance of a particular network connection then yes, testing round trip times from a GameConnection isn't going to give accurate results because of the overhead inherent in running the test from within a game app.
However, if you're testing pings to display on a game server list, that's a different story. Testing round trip times through GameConnection or a TCPObject will actually give you results more accurately reflecting what the user will experience once they are connected; precisely because the same game application overhead will apply in both cases.
11/27/2009 (11:16 am)
Quote:get the ping with GameConnection or with TCPObject is not a good idea (the results are not very accurate)
Technically, if you're just looking to evaluate the performance of a particular network connection then yes, testing round trip times from a GameConnection isn't going to give accurate results because of the overhead inherent in running the test from within a game app.
However, if you're testing pings to display on a game server list, that's a different story. Testing round trip times through GameConnection or a TCPObject will actually give you results more accurately reflecting what the user will experience once they are connected; precisely because the same game application overhead will apply in both cases.
#14
You are right. The overhead of the game itself is a different story because nobody knows how much objects are networked. But that is the task of the LagIcon. I didn't tried the setLagIcon-function but i guess i can implement my own solution. A conceivable scenario could be to use CommandToClient and CommandToServer. Should be possible to calculate a different ping with these two functions.
Ping:
< 100 ms (green Icon)
> 100 ms and < 200 ms (yellow Icon)
> 200 ms (red Icon)
Something like that.
But it makes no sense to measure the ping with GameConnection/TCPObject before a mission is loaded.
11/27/2009 (11:28 am)
The pings of the list (from the masterserver) are only a clue to get some info about the general network connection. You are right. The overhead of the game itself is a different story because nobody knows how much objects are networked. But that is the task of the LagIcon. I didn't tried the setLagIcon-function but i guess i can implement my own solution. A conceivable scenario could be to use CommandToClient and CommandToServer. Should be possible to calculate a different ping with these two functions.
Ping:
< 100 ms (green Icon)
> 100 ms and < 200 ms (yellow Icon)
> 200 ms (red Icon)
Something like that.
But it makes no sense to measure the ping with GameConnection/TCPObject before a mission is loaded.
#15
Else you have a scenario where Joe sees MyServer with a ping time of 25 ms. Joe says "wow, 25 ms!" and joins the server, where he sees a ping of at least 44 ms, even when the game is quiet with minimal ghost activity. What happened of course is that Joe had a framerate of around 60 fps at best. Thus adding a minimum of 16 ms to his ping in-game. Additionally, the increased size of the game packets added another 3 ms mandatory delay. Of course, Joe does not know why his ping is higher in game, and simply concludes that he cannot trust the ping times shown in the server list.
Granted, the level of ghost activity will still cause an unpredictable increase in ping times due to the increase in data being sent. There is no way to predict the effects of that. Furthermore, fluctuations in framerate during gameplay will also affect the ping. So no, you'll never get the Server List ping to perfectly match what you'll see in-game. Nevertheless, why start with an unnaturally low ping which we know we will never ever see in-game even under the best of conditions?
11/27/2009 (12:14 pm)
Sure it does. Because that way some framerate delay is already factored in; as well as any additional delay from the increased size of the game vs ping packets. Else you have a scenario where Joe sees MyServer with a ping time of 25 ms. Joe says "wow, 25 ms!" and joins the server, where he sees a ping of at least 44 ms, even when the game is quiet with minimal ghost activity. What happened of course is that Joe had a framerate of around 60 fps at best. Thus adding a minimum of 16 ms to his ping in-game. Additionally, the increased size of the game packets added another 3 ms mandatory delay. Of course, Joe does not know why his ping is higher in game, and simply concludes that he cannot trust the ping times shown in the server list.
Granted, the level of ghost activity will still cause an unpredictable increase in ping times due to the increase in data being sent. There is no way to predict the effects of that. Furthermore, fluctuations in framerate during gameplay will also affect the ping. So no, you'll never get the Server List ping to perfectly match what you'll see in-game. Nevertheless, why start with an unnaturally low ping which we know we will never ever see in-game even under the best of conditions?
Associate Phillip O'Shea
Violent Tulip