If you have looked at the Viewer Statistics (Ctrl-Shift-1), you have likely looked at PING. The term comes from the use of echo location in submarines and other marine uses. The active echo locators make a distinctive PING sound as the send a sound wave out. Electronics hear the echos coming back and create picture for human use.
When testing network connections we use a ping. It is actually a command to send a network data packet to a remote location and request a packet be sent back. The travel time tells us how well the connection is working.
What most people likely don’t think about is whether the Viewer’s PING is the same as the PING our operating system generates. For your information it isn’t.
I noticed some time ago that PING in viewer stats will often hit 5,000ms and up. I’ve seen it going over 10k. I wondered what was wrong with the communications channel. I did some testing using the information provided by the viewer in Help->About… The URL and IP address of the server your avatar is in is there.
Using the URL you can test your DNS lookup speed and packet travel time. Using the IP address you can eliminate the DNS time and get just the network travel time.
You will find that the viewer and your OS pings will give you different answers. There is a reason for that. This Friday I heard the reason for that difference. The information came in a discussion of whether one could trust the stats and where they come from. It is not as completely simple as saying the viewer gets the ‘Viewer Stats’ from the server. But, that is the simple, short story.
In response to my pointing out that when Physics FPS slows PING in the Viewer Stats goes up and pings from outside the viewer give different results Andrew replied:
What is happening there is that the incoming packets are processed in the main simulator loop. So if the physics engine is causing the main simulator loop to run slow, then network packets pile up and wait and their ping replies come back after a delay (after the physics frame is done). That is, the responder to the ping messages is not running on a separate thread.
I think there is a similar dependency of ping on the *viewer* fps.
If you ping the server from a terminal command line you’ll get a hardware accelerated response, which should be closer to the real network travel time between server and client.
Siana Gearz confirmed: “Andrew, yes, ping is dependent on viewer frame rate. Because it’s a processing roundtrip time of sorts and messages are only processed once a frame.”
Andrew Linden: “Yes, and that ping time is relevant to the UDP circuit code — it’s the effective ping it would want to use for delay interpolation (if it did any).”
PING Summary
So, when testing your connection, the Viewer Stats are not really representative of your connection. Those stats are much more a composite of all the factors affecting Second Life Performance. They are a measure of how things are working ‘process-wise’ for the SL Experience. They are much more for Lindens dealing with SL problems and the viewer and server calculating interpolation factors than they are for home users trying to figure out their performance problems.
If you are testing your connection, see my: Troubleshoot Your #SL Connection. I need to add this information into that article… someday. But, the article does get into how to tell if the delays are on the server side or your side.
Interesting. In OpenSimulator, ping response is not tied to scene processing so a slow physics/scene loop would not have precisely the same effect, though it could still lead to a greater delay than one would expect if the simulator CPU is heavily overtaxed.
Also, a very high volume of other UDP messages could theoretically slow down the ping packet response.
I’ll take your word for that. 🙂