[e2e] 150ms - tolerable latency for quakeIII

[Joe Touch]

Craig Partridge wrote:
> 
> In message <200105232344.f4NNiHJ477194 at pachyderm.pa.dec.com>, Jim Gettys writes
> :
> 
> >The actual latency where you can't percieve it isn't "real time" is down
> >in the 30ms range, where of course the speed of light on great circle
> >routes in glass is in fact a major issue.
> 
> Interesting.  That number sounds a touch too low to me.  My recollections
> from when I tried to collect data in this area is that people can't react
> quite that fast (30 ms).  What I do recall is that there are studies
> that suggest that as people become very talented at high intensity
> interactive activities (jet fighter pilots being well studied) that
> they anticipate, and that combined with the fast reflexes of being
> (a) young and (b) high on adrenaline they start to get close to these
> numbers.
> 
> Grenville's number of 150ms matches exactly the one way delay values from
> Bell Labs in the late 1960s (studying interactive voice delay).

This all depends on the design of the system. The Bell Labs numbers are
for voice, where the system does no anticipative modelling (the speaker 
on your end doesn't really 'guess ahead'.

The latency tolerable in a system depends on how much the endpoint
behavior
varies, and how much of that variance is unpredictable. In 150ms, how
much
is "allowed" to occur in Quake? If a virtual player is driving a car,
it only depends how quickly it can change direction or velocity;
otherwise,
its location can be predicted and modelled by the other ends.

Many of these systems work with a bit of fuzz - players locations on
respective endpoints vary, but not enough to matter much for the playing
of the game.

While I'm not surprised things breakdown in both systems around 150ms
(it might be a design point, since that's a reasonable latency for
Internet packets right now), it may only be a function of the 'spatial
resolution' of the game.

Joe