AW: [bf1942] New build question?

[Götz Klingelhöfer [KGN]]

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.
> >
> >
> >
> 
> 
>