when replying to an e-mail , " RE:" is automaticly added to the subject line along with the title of the mail that was started. This is normal.
On Thu, Jun 30, 2011 at 12:25 PM, [email protected] <[email protected] > wrote: > 30.06.2011 10:41, > hlds_linux-request@list.**valvesoftware.com<[email protected]>пишет: > >> Send hlds_linux mailing list submissions to >> [email protected].**com<[email protected]> >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> http://list.valvesoftware.com/**mailman/listinfo/hlds_linux<http://list.valvesoftware.com/mailman/listinfo/hlds_linux> >> or, via email, send a message with subject or body 'help' to >> >> hlds_linux-request@list.**valvesoftware.com<[email protected]> >> >> You can reach the person managing the list at >> >> hlds_linux-owner@list.**valvesoftware.com<[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].**com<[email protected]> >> Subject: Re: [hlds_linux] fps changes in the last patch >> Message-ID:<4E0B92F5.2060907@**evcz.tk <[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: >>> hlds_linux-bounces@list.**valvesoftware.com<[email protected]>[ >>> hlds_linux-bounces@list.**valvesoftware.com<[email protected]>] >>> On Behalf Of ?????? ?????? [Nikita Bulaev] [[email protected]] >>> Sent: 28 June 2011 11:47 >>> To: [email protected].**com<[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<hlds_linux-request@**list.valvesoftware.com<[email protected]> >>> >: >>> >>>> ------------------------------ >>>> >>>> Message: 6 >>>> Date: Tue, 28 Jun 2011 08:16:45 +0000 >>>> From: Henry Goffin<henryg@valvesoftware.**com<[email protected]> >>>> > >>>> To: "hlds_linux@list.**valvesoftware.com<[email protected]> >>>> " >>>> >>>> <hlds_linux@list.**valvesoftware.com<[email protected]> >>>> > >>>> Subject: [hlds_linux] fps changes in the last patch >>>> Message-ID:<501EF4F8-E424-**4340-B194-9BF243029CF1@**valvesoftware.com<[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<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<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 >> >> <hlds_linux@list.**valvesoftware.com<[email protected]> >> > >> Subject: Re: [hlds_linux] New Replay feature listening on 27040 >> Message-ID:<4E0BA3BF.1050805@**opendreams.net<[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<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<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
