i'll submit a bug to clarify this.
this number is a smoothed (averaged) estimate of the round-trip time, in milliseconds, to the peer and back. instantaneous measurements are smoothed via a low-pass filter similar to the one TCP uses to reduce sampling noise.
i'm surprised we didn't make it in seconds. that's unfortunate.
lower numbers are better. most likely, with numbers like 0-2, you are measuring to a peer on the same LAN or same computer.
Thanks that's very good to know.
Is it reliable? For example, can I use SRTT to determine if I should boot users with sluggish connections from a game?
Is it determined once when the NS is created? Or do I need to keep checking to keep it current?
Are there other ways to determine latency?
For example, dataReliable sounds like it might be useful, but is this just TCP (FP10.0) vs. UDP (FP10.1) for ns.send()?
the smoothed round trip time is updated whenever data is transmitted/received with a peer. note that the round trip time can change *as a result* of using a link. specifically, the more you send to a peer (or receive from it), the higher the round trip is likely to be, as a result of queueing in the network. the SRTT is computed from real measurements taken during packet exchanges, so is as reliable as it gets.
the smoothed round trip time is a measurement of the network-level delay between the two endpoints. it doesn't measure the application-layer latency, which will depend on local queueing (especially if you're trying to send more data than fits in the available bandwidth) and how heavily loaded your computer is (particularly how heavily loaded the ActionScript interpreter in your Flash Player is). the only reasonable way to measure the application-layer latency is to do it manually in ActionScript periodically, for example by defining your own "ping" and "ping reply" methods to use with NetStream.send(). that'll tell you the real end-to-end delay all the way through to your application. if you have a delay-sensitive game, presumably you're exchanging game commands or data often, so you could piggy-back this measurement on top of that instead of defining separate messages.