[CF List] CF 0.95.6 Client discards commands under "load" - feature, not bug

[Frank McKenney]

** Reply to message from Mark Wedel <
     
     mwedel at scruznet.com
     
     > on Thu, 29 Jun
2000 21:09:05 -0700

>
     
      Good document.
     
     
Thanks, Mark.

>
     
      Note that connection speed is not all that relevant.  The bandwidth it
     
     >
     
      takes to > send the commands to the server is minimal (maybe 30-40
     
     >
     
      bytes/command?  > presuming a minimal usuable speed is probably 3
     
     >
     
      K/second, tht is a lot of > commands).
     
     
Agreed, the uplink speed is likely to be one of the lesser constraints
in most situations.  A 33KB uplink (call it 3K bytes/sec) would give the
client 100 commands/sec...  but, of course, a reasonably fast client
_could_ exceed this when hit with a stream of "macro" commands (10
keystrokes with a 10:1 leveraging runs you right up to the limit).

>
     
      ...  And unless the command results
     
     >
     
      in lots of output (map redraws or the > like), the incoming bandwidth
     
     >
     
      should not be much of a factor.
     
     
Agreed, in most cases (caveat added for the inevitable aficionado who is
going to set up a 1200 Baud dial-in link so his friends can play on his
Linux server (;-)).

We still have the incoming bandwidth (from the server) to consider.
Acknowledging that that there will likely be a _flood_ of bits outbound
from the server when the character moves into a new map, are there any
other situations which might generate copious server output?

>
     
      Likewise, server speed only really comes in to play if the cpu on the
     
     >
     
      server > systems gets maxed out.  Possible on slow systems, but on 
     
     >
     
      fast systems, this is > fairly unlikely.
     
     
Ah.  Here we get to one of the critical points of my own ignorance.  In
the past I have often objected to the phrase "latest version" on the
basis that it was ambiguous and often time-constrained.  "Fast" and
"slow" have the same problem here:  (a) I don't have the experience to
offer an opinion on what hardware might be considered "fast" or slow for
CF 0.95.6 (except that a 32 Mb 486DX4-100 seems a little on the slow
side (;-)), and (b) over time the Crossfire code, connection data rates
and latency, and The Available Hardware will continue to change.

Would some of the lurkers out there care to offer some examples of
"slow", "acceptable", "really snappy", and "probably unplayably slow"
hardware, specifically with respect to Crossfire 0.95.6?

>
     
       Client speed is relevant, but similarly, really only if the cpu gets
     
     maxed
>
     
      out.  One thing of major importance is the key repeat speed of the
     
     client.

Yes.  I thought I had covered that part of it when I described the
effects of "leveraging" commands.  If this was unclear (and it
apparently was), maybe there is a better way of saying it.  Or were you
attempting to address some aspect that _I_ missed?  (The complexities
and subtleties of human-human communication make Client-Server protocols
look simple in comparison!  (;-))

>
     
       Most servers use the 120 ms tick time (roughly 8/second).  A player
     
     with speed
>
     
      1.0 gets one action per tick.  A player with 0.5 speed get 1 action
     
     every other
>
     
      tick.
     
     >
     
     
     >
     
       If you have your window size set to say 40, and your character speed
     
     is 0.5,
>
     
      that is 80 ticks (or roughly 10 seconds) it will take for the server
     
     to process
>
     
      all those buffered commands.
     
     
Yup.  Anyone care to offer odds that Crossfire users can be convinced
_not_ to try to squeeze as much action as possible out of _every_
keystroke?  <Vbg!>
 
>
     
       One thing that could be nice is to have commands that get sent no
     
     matter what
>
     
      the windowing looks like.  So for example, if the window is full
     
     (client will
>
     
      send no more commands) yet the player invokes the word of recall
     
     spell, it would
>
     
      still send that.  Ideal solution would be for this to be set on a
     
     player by
>
     
      player basis.
     
     >
     
     
     >
     
       Ie, have some config file (or gui popup) with the list of commands
     
     and let the
>
     
      player set which ones are 'always send' commands, and which ones can be
     
     >
     
      discarded.  In theory, you could even get intermediate commands (if
     
     the queu is
>
     
      less than half full, send it, otherwise don't).
     
     
This sounds like...  um...  "an interesting feature if _I_ don't have to
code and debug it" (;-)) It also raises another point of ignorance 
(again, mine): _is_ this a serious problem?

That is, I know my own system is a bit slow-ish, but I'm new enough to
Crossfire that I have no sense of what hardware its servers (and
clients) are running on.  If everyone by me now has a 256Mb Athlon/P-III
600MHz box, my three-hour compilation (I'm slow and pedantic) may only
be of use to one or two people.

Do you (does anyone) have any idea how often users are actually
exceeding (for whatever reason) the default command_window seting of 10?


Frank


Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
E-mail: 
     
     frank_mckenney at mindspring.com