headers
Daniel Bard | 1 Apr 2003 01:54
Picon

Re: Linux server status report: 2003-03-31

I get the bungee-effect when I try having more than 14 players on my server
(100mbps). The problem is (from the little problem-checking I've done) that
the servers peaks at 40% cpu-load wether there is 14 ppl or 20 ppl on the
server. I don't know if it's just on my system the server acts that way or
not, but somehow I feel like it's connected.

|dkdt| Bureaucrat

----- Original Message -----
From: "Daniel Jimenez" <cuban <at> hoodedmaniac.com>
To: <bf1942 <at> icculus.org>
Sent: Monday, March 31, 2003 11:19 PM
Subject: Re: [bf1942] Linux server status report: 2003-03-31

> Damn, you are luckier than I. I get the bungee effect w/4 people and I'm
on
> a 100mbps link.
>
> cuban
> ----- Original Message -----
> From: "Daniel H. Valois" <ninzor <at> packet-kids.com>
> To: <bf1942 <at> icculus.org>
> Sent: Monday, March 31, 2003 1:20 PM
> Subject: Re: [bf1942] Linux server status report: 2003-03-31
>
>
> > i only get the bungee effect when there are lots of people on my server.
> > It's on a DS3 connection.
> > get about 16+ people on my server and you'll have the bungee effect.
> > server ip= 66.234.161.200
(Continue reading)

Permalink | Reply | 0 comments |
headers
oblio | 1 Apr 2003 03:57

Re: Linux server status report: 2003-03-25 - 2 more for the wishlist

On Tue, Mar 25, 2003 at 05:14:50PM -0600, Stewart, John wrote:
> Logging:

This may or may not be of help to you....
http://sourceforge.net/projects/bflog

-Jonathan
Permalink | Reply | 0 comments |
headers
roger | 1 Apr 2003 01:47
Picon

unscribe

bah. clicked on the link at the bottom of the welcome email (with
"unsubscribe" embedded in the email address) and it appears to not have
worked.

the icculus.org homepage lacks a link to the mailling list unscribe page
:-( 

--

-- 
Roger
http://www.eskimo.com/~roger/index.html
Permalink | Reply | 3 comments |
headers
ScratchMonkey | 1 Apr 2003 05:21

RE: Linux server status report: 2003-03-31

--On Monday, March 31, 2003 12:24 PM -0600 "Stewart, John" 
<johns <at> artesyncp.com> wrote:

> What is your objection to a static version? Binary size? If you've got
> enough bandwidth to run a bf1942 server, surely you have enough bandwidth
> to download a few hundered megs, right?

While a static version will serve the greater number of admins, a dynamic 
version has the advantage of a lower in-memory footprint. The memory for 
the library code is shared across all applications. This also improves 
cache performance.

I would argue for a static version until the server gets much more stable, 
and then consider releasing a dynamic version.
Permalink | Reply | 0 comments |
headers
Ryan C. Gordon | 1 Apr 2003 06:05

Re: unscribe


> the icculus.org homepage lacks a link to the mailling list unscribe page
> :-(

I just manually removed you.

--ryan.
Permalink | Reply | 2 comments |
headers
Andrew Chen | 1 Apr 2003 08:42

RE: Linux server status report: 2003-03-31

At 10:24 AM 3/31/2003, you wrote:

> > How about a static version and a dynamic version?  That way
> > we can choose
> > which one we want to run.  The solution should NOT be
> > maintaining both a
> > gcc2 and gcc3 build, though.
>
>What is your objection to a static version? Binary size? If you've got 
>enough bandwidth to run a bf1942 server, surely you have enough bandwidth 
>to download a few hundered megs, right?
>
>johnS

Memory.  Memory is cheap, but not THAT cheap :p  I suspect a statically 
compiled BF binary might run close to 100MB without trying too hard.
Permalink | Reply | 0 comments |
headers
Fredriksson, Andreas | 1 Apr 2003 09:23
Picon

RE: Linux server status report: 2003-03-31


Andrew,

the CPU load comes from all the disk I/O and file parsing going on
at level load time.

There's not much to do about this except maybe providing callbacks to
some external root-uid process that can change the niceness of the
main bf1942 thread during loading. But that way clients will have to
wait longer before they can connect to the new map, so it's not
a perfect solution either.

Regards,
Andreas

-----Original Message-----
From: Andrew Chen
To: bf1942 <at> icculus.org
Sent: 3/31/2003 8:21 PM
Subject: Re: [bf1942] Linux server status report: 2003-03-31

At 05:20 AM 3/31/2003, you wrote:
>- The Linux server is compiled with gcc3 now, and this has uncovered
>   some pretty nasty bugs that were masked out by gcc2/msvc. I'm still
>   sorting out library issues and how we are going to distribute the
>   package. Would a completely static version be acceptable for people
>   with older distributions?

Hehe, I called it, didn't I?  :)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Christian Wolf | 1 Apr 2003 09:58
Picon
Favicon

Re: Linux server status report: 2003-03-31


Hallo!

On Mon, 31 Mar 2003, Fredriksson, Andreas wrote:

> - The Linux server is compiled with gcc3 now, and this has uncovered
>   some pretty nasty bugs that were masked out by gcc2/msvc. I'm still
>   sorting out library issues and how we are going to distribute the
>   package. Would a completely static version be acceptable for people
>   with older distributions?

The bf1942_lnxded binary is currently 32 MB in size and already static
(at least this is what ldd tells me). I think it is a good idea to let
the binary static until gcc-3.x becomes standard for most users.

Another question/suggestion: why does the server need a tty (e.g. run
in a screen session)? Would it be possible to make bf1942_lnxded running
from /dev/null (stdin)?

Greetings,
	Chris
Permalink | Reply | 0 comments |
headers
Paul Richards | 1 Apr 2003 10:45

Re: Linux server status report: 2003-03-31

Is it not possible to add a switch or setting where we can choose the
maximum cpu usage that the server can use on a map change? Or just have a
switch that makes the server use only say 50% of the CPU on a map change, at
least then we have the choice of whether our servers run slower during a map
change... Or it automatically goes to a lower priority and therefore doesnt
effect other processes running....

This is probably a tall order, but alot of people will need to run more than
one BF server on a single CPU system, I would think a solution is definitly
needed.

----- Original Message -----
From: "Fredriksson, Andreas" <andreas.fredriksson <at> dice.se>
To: <bf1942 <at> icculus.org>
Sent: Tuesday, April 01, 2003 8:23 AM
Subject: RE: [bf1942] Linux server status report: 2003-03-31

>
> Andrew,
>
> the CPU load comes from all the disk I/O and file parsing going on
> at level load time.
>
> There's not much to do about this except maybe providing callbacks to
> some external root-uid process that can change the niceness of the
> main bf1942 thread during loading. But that way clients will have to
> wait longer before they can connect to the new map, so it's not
> a perfect solution either.
>
> Regards,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fredriksson, Andreas | 1 Apr 2003 11:28
Picon

RE: Linux server status report: 2003-03-31


Paul,

the loading code is completely linear so it would be very
hard to make it release the CPU now and then.

Also, once you increase the process niceness (via setpriority(2)),
you cannot lower it again due to unix custom--except if you're root..

And no, we don't want the server to run as root! :-)
Perhaps a suid/nice+load+unnice+droppriv combo could be developed, but
I think it's low priority for the time being.

Our first goal has to be to release a server of acceptable quality,
features will have to wait.

Regards,
Andreas

-----Original Message-----
From: Paul Richards
To: bf1942 <at> icculus.org
Sent: 4/1/2003 10:45 AM
Subject: Re: [bf1942] Linux server status report: 2003-03-31

Is it not possible to add a switch or setting where we can choose the
maximum cpu usage that the server can use on a map change? Or just have
a
switch that makes the server use only say 50% of the CPU on a map
change, at
(Continue reading)

Permalink | Reply | 1 comment |

Gmane