[crossfire] Bandwith ussage too high?

[Mitch Obrian]

The obvious easy things basically anything cylical)
are the ones to do first (cylical ones: oceans, etc).
Then second may be monsters and then spells. That's as
far as we should go IMHO (any futher would reveal
things we don't want the client to know about the
map). Spells do cause lag because they have to animate
fast while propagating, the bandwith might beable to
be cut in 1/2 on that one (the animation the client
allready knows (if he saw that spell before) but the
propagation must still be sent). 

Another area where, when looking at the CF datastream,
that ate bandwith were the verbose movement commands
and the map1a command. Rednaxela suggested that these
could be made into 3 or 4 bit commands (rather then
the multi byte commands they are now).

This would decrease lag happily :D.

--- Mark Wedel <
     mwedel at sonic.net
     > wrote:

>
      Mitch Obrian wrote:
     >
      > I think it would be best to not do that. We do not
     >
      > want to leak information to the client that he
     >
      cannot
     >
      > see, nor do we want to tell him what is connected.
     >
      > 
     >
      > I think the best would be to specify what is
     >
      cosmetic
     >
      > animations (ex: monster animations, water, spell
     >
      > animations (fire etc) (these eat bandwith), etc)
     >
      and
     >
      > keep the funcitonal ones as is (doors, gates,
     >
      > triggers, spikes). Most of the bandwith hit is on
     >
      the
     >
      > spell, water, etc animations. 
     >
     
     >
        I agree.  The bandwidth of the gate moving is
     >
      pretty trivial - something like 
     >
      4 bytes/tick or the like (8 ticks/second, so 32
     >
      bytes per second).
     >
     
     >
        Granted, may be several gates/doors moving, but
     >
      still.
     >
     
     >
        Has anyone actually done analysis on actual
     >
      bandwidth usage, or is all this 
     >
      just WAGs?
     >
     
     >
        Bandwidth for the map is 2 bytes for the space
     >
      (coordinates).  1 byte for 
     >
      darkness.  2 bytes for the 3 faces.
     >
     
     >
        Worst case situation is a space is 9 bytes.  625
     >
      spaces (25x25) - 5625 
     >
      bytes/tick.  8 ticks/sec - 45000.  So worse case,
     >
      which would pretty much never 
     >
      be seen, is 45 k/sec - non trivial.  But maybe it
     >
      also depends on what we 
     >
      require.  But I'd also say that isn't a case your
     >
      likely to see very often.  I'd 
     >
      estimate more realistic usage is closer to
     >
      10-20k/sec, even in really bad cases 
     >
      (highly unlikely you'd ever get a case where there
     >
      are objects on all three 
     >
      layers, and all of those objects are also animated).
     >
     
     >
        I think that can be brought down.  But one has to
     >
      be careful on how much work 
     >
      is spent to optimize this.  Conveying that a space
     >
      should use an animation is 
     >
      likely to actually use more initial bandwith, with
     >
      savings down the road.  But 
     >
      for something like a gate, it may actually not be
     >
      much a win - and almost 
     >
      certainly not for the complexity added.
     >
     
     >
        I can certainly see that the case of oceans can be
     >
      a fairly big user - maybe 
     >
      of half the map of ocean spaces - 300 * (2 + 2) * 8
     >
      = 9600 bytes/sec.
     >
     
     >
        I'd much rather go for the easy cases like letting
     >
      client animate oceans and 
     >
      other things we don't care about.  IF that doesn't
     >
      get enough savings, worry 
     >
      about trying to optimize the more complex cases.
     >
     
     >
        But all that said, one has to figure out what hte
     >
      goal is.  Its going to take 
     >
      some bandwidth no matter what you do - you can't
     >
      optimize it to zero.  Is it 
     >
      worth it to write a lot of code and add a lot of
     >
      complexity to saving 500 
     >
      bytes/second?  My thought would be no - if anything,
     >
      as time passes, bandwidth 
     >
      will become more available and cheaper.
     >
     
     >
     
     >
      _______________________________________________
     >
      crossfire mailing list
     >
      
      crossfire at metalforge.org
      
     >
     
     
     http://mailman.metalforge.org/mailman/listinfo/crossfire
     
>
     
     


		
__________________________________ 
Yahoo! Music Unlimited 
Access over 1 million songs. Try it free.
     http://music.yahoo.com/unlimited/