[MUD-Dev] The Lag monster...

[Amanda Walker]

On Nov 6, 2004, at 7:06 PM, Harlan Beverly wrote:

> I'm a gamer, obviously.  I for one hate LAG more than anything
> else.  When playing U.O., Everquest, Galaxies, Asherons, and the
> rest it was the only thing that frust actually made me throw my
> mouse.

> The burning need is Lag.

> The question is, how do I solve it?

> There are three ideas on our table: One way is to squeeze a little
> out of the client side host processing.  We can do that, but it's
> a marginal improvement at best.

> Another way is to reduce network traffic: we can do that with
> compression and possible active filtering of unnecessary messages
> (both inbound and outbound).

> A final way is to improve server performance.  We can do that.

> Any other ideas?

OK, let's look at lag.  Lag seems like a network problem, and
occasionally it is, but usually it's not.  The particular aspect
you're focussing on (the network stack and NIC hardware) isn't the
source of lag in any game of which I am aware, and so trying to
improve things by doing a game-specific network card strikes me as
being a little like looking for your keys under the streetlight
because the light is better there.

Lag can be caused by many sources, but based on my own experience
with distributed simulations, there are a few major ones.  Consumer
gaming pros may have some additional factors they've encountered,
which I'd be very interested in hearing about as well.

  - Graphics bottlenecks, particularly geometry and texture
  management.  Video cards with more texture memory help some here,
  but for a large virtual world, even the biggest chunk of VRAM you
  can buy is just going to be a cache.  One reasons that FPSs and
  single-player games feel so fast, even when playing over a
  network, is that all the geometry and textures are preloaded.
  Rendering a small, static game level puts a lot less load on the
  video card than an open-ended virtual world.

  - Simulation bottlenecks.  A virtual world is, in effect, a
  discrete event simulation system.  If it is written poorly, a lot
  of things have to happen in "lockstep" in order to update the
  state of the world, which causes the entire world "update loop" to
  slow down as more things are happening (more players, more
  scripts, more timed actions and effects, even triggers, etc.).
  The only solution to this is to rewrite the simulation so that the
  interlocks happen on a more fine-grained basis.  Doing so allows
  you to "scale out" by throwing more processing power at the
  problem via clustering or distributed simulation techniques

  - Area of influence management.  The more data the simulation has
  to consider in order to figure out what's going on around a
  particular player (actions of other players and mobs, for example,
  or dynamic terrain), the more CPU horsepower it takes to tell the
  client what to render, and the greater the network traffic
  required to send updates to the client.  This is starting to at
  least get close to the network stack, but the stack is still not
  the bottleneck: the lag is still occurring either in the server
  processing or in the sheer amount of data that needs to get across
  a fixed capacity network link at the client end.  Broadband client
  connections help, but they only help, they don't solve the
  problem.  In the long run, I think that current MMORPGs are really
  beginning to hit some of the limits of "everything knows where
  everything else is every moment of the time" as a simulation
  technique.  There's a point when things get crowded that you no
  longer need to see every single player in perfect detail.  You
  need to see those right around you, and a crowd around them
  (SpeedHumanoid, anyone?).  The problem here isn't the network,
  it's the simulation algorithms.  When everyone has to know what
  everyone else is doing, the number of updates per second required
  to maintain a given performance level goes up at the server
  exponentially with the number of players, and at the client
  linearly with the number of players in the area of influence or
  interest of that client.

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