[bf1942] New build question?

[Killing]

Depends on the player limits but a 32 player server will take
1Ghz+ to be smooth from what I've seen on our windows box.

    Steve / K
----- Original Message -----
From: "Götz Klingelhöfer [KGN]" <tankmann at krawall.de>
To: <bf1942 at icculus.org>
Sent: 06 January 2003 14:03
Subject: AW: [bf1942] New build question?


Hmmm...

our windows 2000 machines with same specs are working fine running 6
instances =) believe me.

--Goetz Klingelhoefer

> -----Ursprüngliche Nachricht-----
> Von: Killing [mailto:killing at barrysworld.com]
> Gesendet: Montag, 6. Januar 2003 14:52
> An: bf1942 at icculus.org
> Betreff: Re: [bf1942] New build question?
>
>
> yes but 6 instances will kill the machine
> ----- Original Message -----
> From: "Götz Klingelhöfer [KGN]" <tankmann at krawall.de>
> To: <bf1942 at icculus.org>
> Sent: 06 January 2003 13:33
> Subject: [bf1942] New build question?
>
>
> Hey guys,
>
> Sorry 'bout that question but did not have enough time to
> chek it myself. Does the new build uses both CPU's if i'll
> start 6 instances of bf42 on (for example) a P4 Dual 2.4 ? Or
> does it only use one CPU?
>
> thx
>
> --Goetz Klingelhoefer
>
> > -----Ursprüngliche Nachricht-----
> > Von: Ryan C. Gordon [mailto:icculus at clutteredmind.org]
> > Gesendet: Montag, 6. Januar 2003 08:46
> > An: bf1942 at icculus.org
> > Betreff: [bf1942] New build.
> >
> >
> >
> > http://icculus.org/betas/bf1942/bf1942-lnxded-betaupdate-build
> > -1041834125.tar.bz2
> >
> > The crashbugs are driving me nuts, and I'm not entirely
> certain they
> > aren't race conditions. So I ripped the multithreading out.
> There's a
> > few benefits to this:
> >
> > 1) The binary is 1.5 megs smaller (!).
> > 2) Less latency due to context switching and mutex contention, etc.
> > 3) Less context switches.
> >
> > The end result is that the server might actually respond better and
> > eat less CPU (although I suspect the lag people are seeing is
> > unrelated).
> >
> > Most importantly:
> > 4) No race conditions.
> >
> > No, most importantly:
> > 5) No more complaints that there's three copies of the game running!
> >
> > You might get all the same crashbugs in this build as the
> last one. We
> > won't know until you try it, but it will let us rule out a
> threading
> > problem (and at least I can say with certainty that you
> won't crash in
> > pthread_mutex_lock() anymore.  :)  )
> >
> > Other stuff:
> >
> > 1) The server status info (the little red dot in the server
> > browser) shouldn't be red anymore. That thing is based on
> framerate,
> > but since all the video stuff was ripped out of the Linux
> server, the
> > frames per second was always zero (which, I guess, is really really
> > slow.  :)  ). Now it reports server frames per second,
> which in terms
> > of a null rendering device, is a more accurate term for the
> exact same
> > thing.
> >
> > 2) I set the gamespy socket to "reusable", which is the ONLY
> > difference between the game's socket and the gamespy one...if this
> > doesn't fix FreeBSD's binding problems, I can't fathom what's wrong
> > with it.
> >
> > Ok, I'm getting on a plane for San Francisco now, but I'll
> be checking
> > email throughout the week. Please report success and failure (and
> > stack traces).
> >
> > Good luck,
> > --ryan.
> >
> >
> >
>
>
>