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

Mark Wedel mwedel at scruznet.com
Fri Jun 30 22:16:25 CDT 2000


Frank McKenney wrote:

>
     
      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?
     
     
 Times that will consume a lot of bandwidth:

1) entering a new map
2) Stepping on a square with lots of objects on it (piles of sold stuff in shops
for example, or if you have a narrow hallway and are killing a bunch of monsters
on the same space)
3) Picking up that large pile of stuff.


>
     
      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?
     
     
 Note that load on the server will vary this.  A server with 10 active players
certainly has different load than a single player server.

 I would say 32 mb of ram is on the low side in modern standards.

 One thing you can do use use the 'time (or is it times) command.  This displays
tick information - more importantly, how many times it was not able to complete
all the desired stuff within the 120 ms time constraint.  You will certainly get
some long times, since map loading will happen in one tick, so that can make for
some very long ticks here and there.


>
     
      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.
     
     
 3 hour?  I would really look at adding some more ram.  a 486 dx4-100 shouldn't
be that slow.  Compiling on a 100 mhz sparc 10 (hypersparc) only took about 8
minutes.  On a p3-500, it took about 1 min 45 seconds.

 It is hard to really determine minimum system requirements.  My own standard
would be if it is usable/playable, it meats the minimum requirements.  Note that
I believe that now days, the client can easily use more cpu than the server for
a single player, especially is using xpm/png graphics (this is also taking into
account the xserver load it causes).


>
     
     
     >
     
      Do you (does anyone) have any idea how often users are actually
     
     >
     
      exceeding (for whatever reason) the default command_window seting of 10?
     
     
 Just to be clear - I don't think exceeding it is necessarily a bad thing.

 I do at times exceed that when playing.  Most often beacause I am running in
some direction and enter a building or the like, so there is that brief pause. 
I generally find 10 about the right size - enough so that I can type a few
things in advanced, but not so long that I get stuck against a wall waiting for
all those movements to get resolved.

    
    


More information about the crossfire mailing list