• number of open http connections
• bitrate over http (overall, and per-connection average)
• average duration of http connection (ignoring event poll which is 30s every time)
• some sort of latency calculation for http connections, if such a thing even makes sense. Might be the same as the average duration.
• we need to include http traffic in the overall bandwidth stat
• we also should include http packet loss, if we can, in the packet loss stat
• we should have a 'Messages in'/'Messages out' stat to supplant the packets in/out stat, since now we send messages over http that aren't recorded in the packets stat

Basically every network-related stat needs to be augmented/added to/rethought because the viewer is using http a lot more now. The udp stats are still relevant, but they don't tell the whole story.

Any other ideas? (BTW let's not turn this into 'redesign the stats bar')

Network traffic between your viewer and SL is far below average. This indicates that there is a problem with your computer or your network connection. Click here for details. (and this takes you to the detailed stats).

or

Network traffic between your viewer and SL is slow, but is about average, which indicates a problem with SL itself. We are already aware of it, and apologize for the inconvenience.

I think the key thought here is to tell people how they are faring compared to everyone else. if it is slow, but they know everyone else is slow, they might not get so excited.

I would like to register a vote against this, though it seems to be too late now.

I would also like to note that the HTTP bandwidth does seem to (at this time) be included in the bandwidth calculations, assuming texture downloads are done over HTTP, since the total bandwidth seems to approximate the sum of the different kinds of traffic on the detailed network stats section... including textures.

On the matter of http bandwidth, currently we do not use it for texture downloads. The bytewise proportion of traffic sent over http is small, so I believe the discrepancy is likewise small at this moment.

I don't have an objection to the lag meter per se... it's not very useful, but it doesn't hurt anything. I do have an objection to the idea that the lag meter is an adequate replacement for the network meters in the menu bar that have been replaced by the search box.

The search box is a double hit, because it also takes up space on the title/menu bar... which is kind of cramped to begin with.

I've created an issue on that already: VWR-3809.

Anyway, linking to VWR-3364. Not really network related, but if any work is done, that one should be considered (as-is or for what it intends) or closed if no longer relevant.