lag (latency) detection

I'm wondering if there's a way for a script to detect when a given user is lagging.

I'm talking about actual lag, that is network latency, not just poor sim or client performance... Which are entirely different things. (Just most people don't seem to understand the difference... Which is odd since the word "lag" means to trail behind, and thus isn't even appropriate to the performance issues. neh...)

Anyway... I'm not really expecting to be able to get the user's ping time, (though LL if you're paying attention llgetagentping could be useful), but some indication of a lagging user could be useful to me.

I suppose you could always do some sort of reaction time test that requires the user to respond to something, and time it. But that will be prone to user error. I might still use it, but is there another way?

There's no info that you can obtain or query via script calls that gives you an indication if a particular client is "lagging", no matter what type of lag you are talking about. Like you said, you can generate the info yourself using some crude, manual method, but it is far from foolproof.

What is it you are doing that requires that info? Maybe there's another solution that doesn't need that kind of info.

The techical term here is network latency, or more specifically, round-trip transmission time. ("Latency" technically applies to processing delays in packet relaying equipment, rather than transmission time due to the speed of the signal through the cable, but the latter is significant in trans- or inter-continental traffic. Nevertheless, the term is often used for total round-trip delays.)

Lag isn't a technical term, but in SL, it's commonly used to mean latency due to all factors, including network latency, simulator latency, and client latency. It's an extremely useful and appropriate term. A rather rare case, where the popular word is well chosen because it addresses the symptom rather than assuming a cause.

I'm surprised you're only interested in network latency. In practice, the most significant latency for a scripted object is usually the server-side script processing latency. Client latency is usually only significant on slow machines or when the client has the view range set too far (especially just after teleporting).

Server side latency affects the performance of the script, but what I'm interested in looking at is measuring the performance of the user that's interacting with the script. Or rather their ability to interact in a timely manner.

Mainly this is something I'm thinking about for games. Online games are usually able to use all sorts of tricks in their netcode to deal with timing issues to make them as transparent as possible to the user, but we don't have many of those same options in LSL. Still, some timing critical interaction should still be possible most of the time for most connections. But, a lag spike could always trash it if you can't detect it.

I'm mostly going to avoid timing critical stuff, but I have some ideas I might experiment with.

As for lag, yeah it is normally an appropriate term. But I still think it somewhat inappropriately used when it is applied to areas of performance not temporally relevant. In other words, the #1 pet peev of mine where "lag" is concerned is bad frame rates. A bad frame rate by it-self, is not lag. The frames are still usually displayed all at the approximate appropriate times, you're just getting fewer of them than usual. That to me isn't lag and calling it lag confuses things to call it lag.

i will be flamed, i'm sure, but i must speak. i mount this soapbox only because it's so time-consuming AND CONFUSING to wade through the forum postings trying to figure out what is meant as opposed to what is said.

people throw around the word "lag" in the most inappropriate ways. there are many types of "lag" - and therefore many causes. to effectively discuss lag, you must set a context.

your interaction with the SL service is affected by a myriad of factors: network throughput, client computer load, client computer configuration (amount of memory, processor speed, hard drive speed, video subsystem, dedicated video memory, SL client settings, etc.), current SL location/environment, overall sim occupancy, etc. some of these factors do not change from [log on] session to session, others change from moment to moment.

"lag" is a synchronization issue which can be affected by system performance; in and of itself, "lag" is not "poor performance." a perfect example of lag is an audio track that's slightly out-of-sync with its video. nearly always, when an in-world resident complains of "lag," what's really at issue is system performance or responsiveness - or the lack thereof.

grammatically (and technically), you cannot have a "laggy" script; you can have a poorly-designed or written script that is inefficient and performs poorly. you can also have a poorly-designed script that can affect in-world performance and responsiveness - for you and for others. let's consider lists as an example; you avoid heavy use of lists because it creates a poor-performing script, NOT because it causes lag.

so, performance killers ... many have spoken about them under the guise of "lag" - sensors, listeners, lists, llFrand(), etc. what no one really speaks about is texture use. using a lot of textures will ALWAYS have a severe impact on client performance. this is forgivable to a great degree (and must be tolerated) as people like to use fancy images for walls, floors, buildings, etc. however, the improper use of textures has no such excuse: a texture resolution in excess of the needs for the "dressed" prim. why would you throw a 512x512 texture onto a 0.5x0.5x0.5 prim? (and i won't even talk about the flex-prim hair-do's so many seem to have.)

and one final word before i go and brace myself for the flames ...
"latency" is a term borrowed by IT and its ilk. latency is the delay between any action and its expected consequence. if you define "action" as "send message" and "consequence" as "receive message," then latency is the measurement of the one-way time delay within the context of communications. however, the colloquial use of the term implies the "lay observer;" therefore latency is most commonly spoken of as "complete round-trip" time --- send-receive-process-send-receive.

i'll now click "submit reply." the web site will announce "your message has been posted" we'll see what the latency is between that action and the flames i get.

Latency so far of 2 years, save 1 day, Nava... now that's lag! grin...