[MUD-Dev] The Lag monster...

[Amanda Walker]

On Nov 11, 2004, at 4:55 PM, Harlan Beverly wrote:

> By your own admission, in some cases Data Transfer is one of the
> bottlenecks.  (such as when you were on a bad broadband
> service... and no doubt especially for modem players).  So for
> these players, data compression, grooming, etc. would indeed
> improve their apparent laggieness.  (the question would be to what
> extend?)

Another question is "how much of this has already been done before
the data hits the networking card?"  Every MMO of which I'm aware
already does a lot of data compression, filtering, and queue
management just to allow it to work over slow connections at all.
If you get data that's already compressed within an inch of its
life, running an additional compression step over it isn't going to
make it any smaller, and will add some additional latency (thus
adding to lag rather than helping).

> What would happen to MMORPGs if you COULD TRUST THE CLIENT?  For
> example, all players of a game must have a special NIC card (which
> I will gladly sell).  This NIC card has preloaded firmware which
> is Digitally Signed (and cannot be modified without the creators
> digital signature)...

You still have the same problem.

Let me talk a little about what I do in my day job.  I design and
implement networks (software and hardware) for military simulations
that are used for test and evaluation of new military hardware (to
make sure it does what the supplier says it does before sending it
out into the field).  Generally there's a mixture of live and
virtual players, ranging from a few hundred to tens of thousands.
The boxes we use are tamper resistant, NSA-certified, and if you
open one up without being authorized, it zeroes itself out and you
get to explain to people with guns why you opened it.

So we can trust our clients.  The clients do trusted calculations,
and can even talk among themselves to resolve encounters, etc.
(BTW, none of this is secret--there's a fair amount of info on this
stuff out on the net--look for terms like "DIS", "HLA", "TENA",
"CTIA", or "distributed simulation").

Lag is still a big problem.  We have enough bandwidth, enough
processing power, and we don't rely on round trips to a big server
in the sky, but lag (which we call by the highbrow term "guaranteed
upper bound on communications latency") remains our single biggest
technical issue.

> This NIC card (with a PowerPC + Digitally Signed Firmware), could
> perform certain interpolation/extrapolation/ and even certain
> Server functions... (Not sure what), that could help distribute
> the processing load away from the Server computer.

> What effect would this have on Game performance, apparent lag,
> etc?

Based on real world experience with something very similar, I can
safely say "very little."  It can help scalability, since it means
you don't need to build a big server farm to do all the
calculations, but it doesn't help lag.  The two things that help lag
the most are:

  - Simulation methodology that takes lag into account (see my
  previous remarks about simulations that do calculations in
  lockstep).  Less tightly coupled different parts of the simulation
  are, the more they can proceed in parallel without waiting for
  each other.  This is a huge win.

  - Prediction, as long as its accurate.  For example, an aircraft
  doesn't turn on a dime.  Instead of sending its position every
  10th of a second, you can get better accuracy with much less data
  by sending the position, velocity, and acceleration data every
  second and running it through a Kalman filter.  This is also far
  more efficient than trying to run a general purpose compression
  algorithm over the raw position information.  The more you can
  *model*, the less data you have to send.  Now, granted, this is
  easier when you can trust the client, but it's a good mindset to
  get into.

Amanda Walker
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev