If you have ever pressed Ctrl-Shift-1 to reveal the Viewer Statistics panel and wondered what all the stuff means, there is a good explanation of the items in the panel over at the Firestorm Viewer Wiki. See: Firestorm Viewer Statistics. Almost the same information is available in the SL Wiki: Viewer help: Statistics.

Network Transfer Rate Comparison

I think on both sites they have simplified the text for the less techy users. I think that is a bad idea, as the people looking for explanations of how the items in the panel work are likely tech savvy.

The first four items listed on the pages are the source of a lot of confusion; FPS, Bandwidth, Lost Packets, and Ping. So, I’ll provide a bit more information.

FPS is pretty straight forward. This is the number of times per second the viewer can render the scene.

It is sort of the overall measure of how well things are going. Everything else in the panel is about what may be degrading this number.

The Lindens consider 10 FPS to be acceptable. Many machines can render far more. However, the simulators can only provide updates for 45 FPS. FPS rates above 45 have an advantage for combat games where the increased FPS provide more opportunities for key presses to be sent to the server. Otherwise higher FPS rates don’t do much for the user side.

Bandwidth is the most misunderstood item in the panel, IMO. Bandwidth is a measure of how much data is being moved through the viewer’s network connection. But, the viewer is not measuring your overall data transfer. It is measuring something unique to the SL viewer-server connection.

The Linden made viewer now labels the bandwidth measure in the stats panel as: UDP Data Received. UDP data updates where the avatar is, how it is moving, the animations playing, and other changes to the render scene.

More and more of the data moving to your viewer is NOT via UDP but via TCP/HTTP. And more things will transfer via HTTP in the future. The Lindens are working on moving animation and sounds download to HTTP and CDN.

So, has this ‘bandwidth’ number been revised? I’m not sure.

You can see in the image above the data moving on my connection is a bit confusing. Starting on the left, my system panel (white background) is showing 446Kbps moving through the connection. The Linden Stats panel (black) shows 521KB/s for KBps, I think that is mislabeled and should be Kb/s (Kbps). And the ASUS meter (transparent background) reading form the motherboard shows 46.7K… which must be KBps.

The system and ASUS meters are similar. The viewer shows more. I can only speculate on why and none of my speculation makes sense…

The difference in the ‘B’ and ‘b’ is a factor of 8 or 10, meaning b ÷ (8 or 10) = B. The 8 or 10 depends on how precise one is being and what exactly is being talked about. In data size or storage 8 is used. In data transfer 10 is used because packet traffic control bits are included, IMO mostly to inflate transfer rates for advertising purposes.

Packet Loss is about the packets of data moving from the server to the viewer that got lost.

Packets are packages of data. The hardware the Internet runs on handles about 1,500 bytes of data per packet. The max limit for the HTTP protocol is 65,535 bytes per packet. Some hardware cannot handle packets at max size and ‘theoretically’ split the packets to something they can handle. There are some observations of ‘average packet’ size passing across the net saying 576 bytes is average…

Think of each packet as a train moving down the rails. To improve everyone’s performance, shorter trains are used so they can get past each other quickly without colliding. Packets that collide are wrecked and must be resent, degrading performance.

UDP packets have no tracking information per the protocol specification and lost packets cannot be detected. So, this viewer parameter is likely telling you how many HTTP packets are being lost, which are resent and you eventually get them. The data isn’t lost, just delayed because a packet or more got lost.

As the Lab switched to moving textures via HTTP the number cache corruptions dropped drastically. Now clearing the main cache is a no-no. It used to be the second step in troubleshooting, restart viewer, still broke, clear cache. Not these days.

The value is a good measure of the quality of your Internet connection. A zero percent loss is ideal. A 1 to 3% loss is usually not noticeable. As loss increases over 3±% things degrade. On faster connections you can tolerate high losses.

PING, in the viewer, is a measure of the time it takes for your viewer to communicate with the server and get an answer back. Ping from Windows is a measure of network performance, how long it takes a packet to travel from the network card in your computer to the ‘remote servers’ network card and back.

So, the viewer ping and the operating system ping are very different things. It doesn’t show in the image, but my ASUS ping, Windows ping, and the viewer ping are different. ASUS and Windows tend to match. The viewer ping is always slower, often considerably slower. System ping is often 10ms when the viewer ping is showing 90ms ping.

The viewer ping goes through the roof when the SL simulator overloads and slows down. Having talked with the Lindens about this at various times they acknowledge that viewer ping is more of a system communication performance measure rather than a measure of network performance.

Summary

Hopefully you now know a bit more about the Viewer’s Stats Panel. But, is there anything there that can help you?

I think FPS, Packet Loss, Simulator Time Dilation and Sim FPS are the most useful. Time Dilation and Sim FPS tell you how the region is performing. Sim FPS drops because there is more for the server to do than it can get done in 22ms (the time for one frame at 45 FPS). Time Dilation tells us how overloaded the system is by indicating its performance, 1 = 100% performance (45 FPS), 0.5 =50% performance or 44ms/frame (22 Sim FPS).

Degraded server performance can increase packet loss, ping, and degrade viewer FPS. Good Sim FPS and Time Dilation of 1.0 (>0.9) along with high packet loss (>3%) or long ping (>300ms) indicates a network issue. Otherwise, the probability changes to the SL server being the likely problem.

With some knowledge the stats panel can give you handy troubleshooting clues.