|
|
|
Of course, I gave the ms values just for the calculation, hover would show for example:
Sim load: +4 ms <- meaning it is running and 26ms per frame I expanded that with the possible cause, based on comment by Nulflux Negulesco on http://blog.secondlife.com/2007/11/26/second-life-1185-viewer-release-candidate-rc2-is-now-available/ I was thinking of log curves too. Ping is a good candidate, the rest... I don't know. Well, a couple of debug options would do it, ranges, linear or logarithmic. We get it in the first look and get some feedback, then we decide on defaults for the masses. Now, that would be an unobtrusive and widely usable lag meter:
Separate packet loss? 5 of them would be a lot, but could be done as well. If not, then I'd definitely lower the threshold which I mentioned in the description, 1% maybe? No packet loss at all in the lag meter, though... And if you want to precisely tune your bandwitdth, you can use the statistics window. Packet loss is there and you can expand it to show the bar as well. You don't need it that often I think. Of course the lag meter can stay there for a while, but I will definitely never open it again. Tried, but doesn't work for an experienced user. On the other hand the inexperienced ones just complain that the suggestions are false. If this is not implemented, then the statistics window needs some serious redesign. The start would be as described in Of course I meant VWR-3364, which I obviously forgot to link back then. Argent, where is your vote?!
I get bursts of packet loss all the time on DSL, so packet loss spiking to 5 or 10 packets per second is not something I worry about, but higher than that and I know I need to deal with it. I can't use the stats window for this because it's just something that happens all the time (thank you southwestern bell).
Which is why you haven't seen my vote yet. I'd rather keep the existing meters unchanged than go to the proposal you've got there as it is. If you want to fiddle with the statistics window, by the way, I believe the XML is in the skins subdirectory. Good point with the bursts. Some spike tolerance mechanism should indeed be devised. Shouldn't be too hard. It would be used with packet loss and also I think the lag meter could benefit from it. By default the spike filters would be on, and one could disable them in debug settings if one would really want the feedback on each and every cough.
Additional feedback on packet loss would be appreciated here. This is definitely the one I know least about. Mine is usually pretty low, but I never 'overclocked' the bandwidth since I always want to have some available for other work (like jira, lol). So I assumed you want the threshold lower than suggested 5%. Anyway, I really don't see a problem if we get more debug settings to configure the parameters as we want. The popular ones would then make it into a setting or into a filtered list of debug settings in preferences. Which would not be called debug settings of course but ..... ummm ..... Customizations. Thanks for the tip on the xml, will look into it The "spike filter" I use is a powerful neural net that ships with every Homo Sap 1.0.
I would rather rely on that than a design that requires LL to write a bunch of code that's pretty low priority for them. Especially since "just bring the old meters back" is already getting a boatload of pushback from LL, and THAT code is already written, I think we went too deep into this packet loss thing. There will always be a parameter that is in an unusual state for someone, ping, FPS, anything. OK, packet loss indication is a digital state in my design, that does make it different. But on the other hand, the lag meter is all digital (ok, three-state) and does not cover the packet loss at all. Debug settings should solve most of it. Not out of the box, but for those who want it. And having an option in Preferences to switch between the search box and the meters should satisfy almost everyone. OK, except for those who would want both, lol. Which could be done after all, if there is enough space.
Anyway, a spike filter (nothing fancy really) would be of use for the lag meter anyway (see also my comments on VWR-2796. It's probably more needed there than here. But could be reused once implemented. Some coding definitely, but while I know many developers are probably busy with various future features, others with bugs, I suppose there could be UI developers that have nothing to do with it and could contribute a lot to the overall satisfaction. Unless LL want the opensource community to develop those and incorporate them when they're proven... Where did you see this pushback you are talking about? I didn't notice it, is it on the web, jira, or was it somewhere else? "But on the other hand, the lag meter is all digital (ok, three-state) and does not cover the packet loss at all. "
The lag meter is not what I'm comparing it to. "Where did you see this pushback you are talking about?" They are simply ignoring all the feedback they're getting and going ahead with the search box. Yes, I understand you're not comparing it to the lag meter. I mentioned it because I have a feeling that the packet loss thing is moving out of the picture. And was wondering why. I linked VWR-1701 which might bring some insight. But I can't say at this point if this is deliberately, accidentally or temporarily. Would need to understand the future and relevance of the packet loss metric to be able to continue working on any design regarding the packet loss.
As for the pusback, the two things seem to be tied, but are not necessarily. If the marketing demans that the search box stays, so it will be (though I fear it might be a sign that SL creativity will be killed by RL marketing). So, if the search box stays (it will fit great with the Dazzle look, I am sure of it), the mini lag meter will probably need to move into the rez area. The obvious choice woud be to make the lag meter minimize to a mini version. BTW, lol, nice bug, move the lag meter to the upper right corner, minimize it and move the minimized bar to the upper right corner. If I click the restore window button, it often restores and minimizes again. The minimize and restore buttons are in the same place so the other gets the click again, lol. But not always.
I'm not sure what you mean by "the packet-loss thing is moving out of the picture". Changes in packet loss indicate that either there is a spike in other traffic - probably locally, but possibly at LL or elsewhere on the Internet, or there is a reduction in the reliability of the network between LL and here. I can't TELL you exactly what patterns of packet loss are relevant, because the pattern matching that goes on in any neural net is difficult to reverse-engineer, so all I can say is that it works for me.
Thanks for your suggestions and the discussion – I haven't had a chance to read all of this, but I'm importing this because we're making changes and this should be considered – we're not ignoring feedback! Also see my latest comment in
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
Bandwidth meters to be expanded into a mini lag meter
Add three bars to the two that are already there, leave them alone. Packet loss needs to remain separate from bandwidth.
Client frame rate: log curve... 1 FPS for a full bar, 5 FPS for a half bar, 25 FPS empty.
Server frame rate: log curve... 1 FPS for a full bar, 6.something FPS for a half bar, 45 FPS empty.
Ping: 200ms for an empty bar, 1000 ms for half a bar, 5000 ms for a full bar.
I'd be happy with two bars of my choice, if clicking on them toggles the critical bars from ctrl-shift-1: Client FPS, server FPS, Server ping, Packet loss, and bandwidth.
(hell, I'd be happy just to get the stupid search box outta there)