30.06.2011 10:41, [email protected] пишет:
Send hlds_linux mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hlds_linux digest..."
Today's Topics:
1. Re: fps changes in the last patch (Marco Padovan)
2. Re: New Replay feature listening on 27040 (Jesse Molina)
3. Re: fps changes in the last patch (Saint K.)
4. Re: New Replay feature listening on 27040 (Eric Riemers)
----------------------------------------------------------------------
Message: 1
Date: Wed, 29 Jun 2011 23:02:45 +0200
From: Marco Padovan<[email protected]>
To: [email protected]
Subject: Re: [hlds_linux] fps changes in the last patch
Message-ID:<[email protected]>
Content-Type: text/plain; charset=KOI8-R
which kind CPU are we talking about?
is the server running only the official maps? stv disabled (stv is still
resource intensive)?
Il 29/06/2011 16:43, Saint K. ha scritto:
This is really strange.
Our servers show an increase, rather than a decrease in server load!
Before F2P a full 24 slots TF2 server would take up around 80% of a single
core, topping to 90% leaving still 10% free for those cases where it peaks
extra high.
Currently, after the F2P update, our servers show a 95-100% CPU load per single
core on a server, with fps drops below 50 as result.
Help. What happened here?!
Saint K.
________________________________________
From: [email protected]
[[email protected]] On Behalf Of ?????? ?????? [Nikita
Bulaev] [[email protected]]
Sent: 28 June 2011 11:47
To: [email protected]
Subject: Re: [hlds_linux] fps changes in the last patch
That is really good news! Thank you!
I am really glad. I'm really thick and tired to play that "fps-game"
with clients and other hosters.
2011/6/28<[email protected]>:
------------------------------
Message: 6
Date: Tue, 28 Jun 2011 08:16:45 +0000
From: Henry Goffin<[email protected]>
To: "[email protected]"
<[email protected]>
Subject: [hlds_linux] fps changes in the last patch
Message-ID:<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hi all -
Free to Play brought a huge influx of new users to Team Fortress. To help
server counts scale up to match the demand, we are reworking the dedicated
server for performance. We want to improve player responsiveness as well as to
reduce CPU usage so that hosts can run more servers per physical server.
Some of those changes addressing CPU usage went out last night. Server operators should
see a big decrease in CPU load and can potentially run more instances per physical box
now. However, a side effect that many of you have noticed is that server FPS has an
effective cap of 500 instead of the previous 1000, or possibly even lower than 500
depending on your Linux kernel HZ setting. This should not have a noticeable impact on
gameplay as the tick rate is still locked (well, mostly locked) at 66 updates per second
and the frames that are being dropped are "empty" frames that do not actually
run a server tick.
We're going to address this further in another set of performance improvements.
Sorry for the temporary confusion, but we wanted to get these CPU load
reduction changes out quickly to help with the Free to Play user crush.
Longer term, we want to move away from FPS as a measure of performance and
instead show actual load and responsiveness (jitter/latency) statistics. The
difference between a tick and a frame is complicated, and fps_max sometimes
affects performance in counter-intuitive ways. We would like to retire fps_max
for servers and replace it with a more obvious server performance setting.
We'll give you all a heads up before we do so.
Henry G.
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
------------------------------
Message: 2
Date: Wed, 29 Jun 2011 15:14:23 -0700
From: Jesse Molina<[email protected]>
To: Half-Life dedicated Linux server mailing list
<[email protected]>
Subject: Re: [hlds_linux] New Replay feature listening on 27040
Message-ID:<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Follow-up on this issue.
I noticed that css and hl2mp now respect the -strictportbind option too.
I've updated my control script.
One thing that I noticed is that unless the -norestart option is also
given, the server will loop forever, trying to start. This was verified
with TF2, CSS, and HL2MP. That's not good because of the benchmark
going before the ports resource check and whatnot. Good thing for the
ten second sleep.
I would propose that the desired behavior is that for any startup error,
the error should be given on stderr and an appropriate exit code be
given. The server process should only restart if it has reached a
certain point of validity, where it can be considered up and running.
After all, I imagine that the auto-restart function is intended as a
crash recovery option for valid runnable servers.
I guess could always use -norestart in my own control script and write
my own while loop to restart on crashes... See, this is where exit
codes are useful. That srcds_run script could trap that easily in the
while loop you've got there. Oh well, I'll think about it.
l4d and l4d2 do not seem to know about "-strictportbind" yet. I realize
there is the -fork option that makes it more complicated. I would just
assume to make the two options incompatible together.
Jesse Molina wrote:
Thank you very much for implementing this. I hope this gets implemented
in the other Valve srcds games too.
I've got a host with two IPs and eleven srcds games that could all
potentially be running at the same time.
So, I tested by copying one of my TF2 server directories to make a clone
of it, started up the first one, then started up the clone.
Here's what the ports in my config file looks like;
CLIENTPORT="27013"
HOSTPORT="27113"
TVPORT="27213"
STEAMPORT="26013"
REPLAYPORT="27413"
The default behavior was that the clone clobbered the next positive
incremental available port.
This was on the console;
WARNING: Port 27113 was unavailable - bound to port 27114 instead
WARNING: Port 27013 was unavailable - bound to port 27014 instead
WARNING: Port 27213 was unavailable - bound to port 27214 instead
WARNING: Port 27413 was unavailable - bound to port 27414 instead
Network: IP 66.113.99.100, mode MP, dedicated Yes, ports 27114 SV /
27014 CL
Verified with lsof.
When I added the "-strictportbind" argument to the command, it did
indeed bail out and this was on the console;
ERROR: Port 27113 was unavailable - quitting due to "-strictportbind"
command-line flag!
"echo $?" returned exit code 100 from srcds_run. As someone else
mentioned, exit codes are great for those of us who have written control
wrappers.
The command line used was;
sudo -H -u hlds sh -c cd
/home/hlds/srcds-servers/server-tf2-JMOMOTEST/orangebox ;
/home/hlds/srcds-servers/server-tf2-JMOMOTEST2/orangebox/srcds_run -game
tf -ip 10.10.99.100 +clientport 27013 +hostport 27113 +tv_port 27213
-steamport 26013 +replay_port 27413 -strictportbind -norestart -pidfile
/home/hlds/srcds-servers/server-tf2-JMOMOTEST/server.pid -maxplayers 24
+map pl_goldrush
One thing to note is that I had to stty sane/reset my terminal after it
failed because local echo was messed up. It's not like I normally run it
interactively anyway, but that could annoy some noob.
Steven Hartland wrote:
Thanks Jon, just what the doctor ordered :)
----- Original Message ----- From: "Jon Lippincott"
<[email protected]>
Good idea.
I added a check for "-strictportbind." Without this, the engine will
print a warning, otherwise it will print an error and quit.
================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and
the person or entity to whom it is addressed. In the event of
misdirection, the recipient is prohibited from using, copying, printing
or otherwise disseminating it or any information contained in it.
In the event of misdirection, illegible or incomplete transmission
please telephone +44 845 868 1337
or return the E.mail to [email protected].
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds_linux
