Re: [hlds_linux] TF2 Lag bug?
Does anyone have any specific information about this bug that causes servers to lag every once and a while temporarily? I am seeing some weird outbound spikes in all the server's bandwidth every 2 hours or so. At the same moment the router's CPU usage spikes. It also seems like this happens at the same time across all the servers. Wouldn't know but then again... HAHA I wouldn't care anymore either. Between the last updates to TF2 and yesterday's update to L4D dedicated server, Valve is batting 1000 on -EFSCKINGSTUPID. Our TF2 servers lag and nobody (not even ME) can reach our L4D servers now. Enough already. Valve is same as it ever was... same as it ever was.., the players out there are getting more and more arrogant ie gimme this gimme that, this map is retarded blah blah blah. Bunch of spoiled brats. Somebody else can babysit the little bastards, I'm done with them and done depending on Valve to do anything right. I am definitely done paying $400 a month to babysit grown-up children. Out like a boner in sweat pants... ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] TF2 Update still problems
Lol, you are using Mani Admin Plugin, the most outdated and inestable plugin ever, use beetlesmod or sourcemod -Rodrigo Yeah, seriously. He's only been AFK for about what, 2 years now? When we first started running TF2 servers (when TF2 came out) I tried the orangebox edition of Mani (the one thing he seems to have done for Mani Admin Plugin in the last couple years) and when I found that half of the stuff that wasn't CS:S-specific anyway didn't work right, I decided it was time to move on. You really should get rid of Mani, even if it isn't the cause of your crashes. It's DEAD. iirc there are a couple sourcemod plugin scripts that will give you some additional compatibility command translation for sourcemod, so you can keep using the mani commands. Beetlemod is pretty good. Sourcemod is pretty good too, and as an added bonus you can code your own stuff for it without having to recompile everything else too if you are so inclined. We're 100% sourcemod now on all servers (CS:S, TF2, L4D). Being able to change thing we don't like about the stock way some plugin scripts are written is important to us. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Kernel Options and Clocksource
I feel like such a linux nub... how do you set your clocksource? On any fairly recent 2.6-series kernel you can put this right on the kernel boot commandline: clocksource=$whatever like clocksource=hpet or clocksource=tsc so that it is set at boot. The echoing of available options into the /sys entry is valid as well, ie: # echo hpet /sys/devices/system/clocksource/clocksource0/current_clocksource but is more of a post-boot type thing. That's not bad, necessarily. You can use it to change the clocksource post-boot. This is useful if you are experimenting with different ones because you can change the clocksource without rebooting. So to get a list of which clocksources your hardware has available: # cat /sys/devices/system/clocksource/clocksource0/current_clocksource you'll get something like this back (but it will vary from system to system): tsc jiffies hpet acpi_pm Someone else asked whether running a 500Hz timer resolution will allow you to get a stable 500 server fps. I'm not going to say it is impossible, but I will say that *I* have yet to find a server machine (server-class hardware) that would let me get 500fps with a 500Hz kernel. I've only ever been able to get 500 server fps with a 1000Hz or tickless kernel, and setting fps_max to 600 or higher. Entirely possible I'm just not doing it right though. But what I do works, so I keep doing it. :) Setting fps_max to 600 usually gets me around 490-496 server fps. CPU utilization for the core a full 30-slot server runs on is usually around 60-65% on a 2.5GHz Harpertown but it does briefly peak higher at times. This is under F10 x86_64 with a stock 2.6.27 kernel (which I'm pretty sure is built dynamic/tickless) and I can get ~1000 server fps out of it for our CS:S games by setting fps_max to 2000. I'm using clocksource=hpet currently, but have considered experimenting with tsc since I've read that there are some recent userspace optimizations in glibc for it on x86_64 which may be of benefit. (And yes, I know you don't need to run 1000 server fps on CS:S to get a good smooth game, or 500 server fps on TF2, but our server has the spare cycles. And let's face it, for server ops this game is ALL about attracting players to your servers and since with GSP advertising etc. many players are convinced they have to be on a 100 tick 1000fps counterstrike server to be on a good server.. well you get the idea) I also use isolcpus= on the kernel cmdline to set aside processor cores for the high-demand games. The cores our TF2 games run on are the only processes allowed to execute on those cores. All hardware IRQ service is pinned to specific other cores by disabling irqbalance and programming the smp_affinity for each valid numeric IRQ. http://kbase.redhat.com/faq/docs/DOC-15596 Cheers On Fri, Mar 6, 2009 at 11:56 PM, The Universes ad...@theuniverses.comwrote: Do you think dropping it down to 500HZ is a better choice or do you suggest something else? If yes, does 500HZ still maintain 500FPS? Thanks! Gary Stanley wrote: At 10:33 PM 3/6/2009, The Universes wrote: I'm running 4 32 man TF2 servers at 500fps (66 tick) and I'm wondering if having kernel at 1000HZ (not tickless) with PREEMPT is necessary? Is that putting unnecessary strain on my CPU (Q9300)? My second question is if you guys use HPET as your clocksource $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource tsc hpet acpi_pm jiffies $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource tsc 1000hz kernels make nanosleep() expensive to call.. on a core2quad calling usleep (which calls nanosleep) nanosleep: 6157 cycles That's alot of cpu time. Cranking up HZ makes interrupts fire so often, so you get more accurate sleep behavior.. TSC lives on the CPU, so calling it is fairly cheap. HPET lives off somewhere on a bridge, so you need to go out to PCI land to read it. HPET is a decent choice, but overall the fastest one is TSC. Would you recommend changing that to HPET? I'm basically trying to lower CPU usage so it doesnt shoot up to 90% sometimes. Thanks, Dan ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- From Ben B. (Goerge) ___ To unsubscribe, edit your list preferences, or view the list archives, please visit:
Re: [hlds_linux] Kernel Options and Clocksource
So to get a list of which clocksources your hardware has available: # cat /sys/devices/system/clocksource/clocksource0/current_clocksource you'll get something like this back (but it will vary from system to system): tsc jiffies hpet acpi_pm Oops... that is supposed to be: # cat /sys/devices/system/clocksource/clocksource0/available_clocksource ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Kernel Options and Clocksource
So to get a list of which clocksources your hardware has available: # cat /sys/devices/system/clocksource/clocksource0/current_clocksource I think you meant available_clocksource not current_clocksource ? Yes, already corrected myself TYVM ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] New update, new bull
Yep same here. I tried removing all plugins as well, it was the first thing I thought about. Same deal. Thanks, Valve. You just killed our servers. When are you idiots going to start TESTING this shit before you shove it down our throats? kthxbai Fucking unbelievable. When Valve is running 100% of the servers their customers play on, then you can shove whatever you want to out as mandatory updates. But until then, you need to understand that WE support your customers and WE pay the bills to operate our servers. And we therefore have a right to pissed off when an update we don't get to say no to kills our servers, and Valve just goes home for the day after pickling the turd. MORONS Right after the TF2 update I was having problems with some of my Linux servers where everyone would get disconnected after joining team or a class. Eventually, after restarting the server over and over, the problem goes away and people can connect and play fine. I talked to octohd and FLOOR_MASTER and they said they are getting the same problem. Anyone else? Thanks, Tony ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] New update, new bull
Eventually, after restarting the server over and over, the problem goes away and people can connect and play fine. I talked to octohd and FLOOR_MASTER and they said they are getting the same problem. Also, lest Valve think the problem just magically disappears and fixes itself after a random number of times rebooting the server, and never comes back again once players can successfully spawn -- The first time I got our 24/7 2Fort Fast Respawn server to successfully spawn a player without the connection problem, I was still running the server OUTSIDE of its usual screen session, so I could easily scroll back and look at console messages. I then reattached (screen -rd) to the screen session the gameserver normally runs in and restarted the server. Voila. Players can't spawn. So whatever the problem is, it doesn't magically disappear. I would venture to guess that it is subject to come back after ANY server reboot. This sucks because many/most of us reboot our games daily to reset the game's memory allocations. It's going to take an update to fix it, IMO. So Valve, when you fix the fix for the string table and startup crash problems, how about leaving the damn dedicated server alone until you are SURE ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] New update, new bull
Also, lest Valve think the problem just magically disappears and fixes itself after a random number of times rebooting the server, and never comes back again once players can successfully spawn -- . So Valve, when you fix the fix for the string table and startup crash problems, how about leaving the damn dedicated server alone until you are SURE Sorry I accidentally triggered the send before I was done ranting... How about leaving the damn dedicated server alone until you are SURE that something you think we need is really READY before you shove it down our throats? In other words TEST YOUR CRAP before you MAKE us put it on our servers. BTW it has nothing to do with mp_disable_respawn_times 1. It's just as borked without that set. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] New update, new bull
One of our servers is experiancing this issue aswell. I have restarted it a zillion times now, but i am unable to choose a class without getting a timeout afterwards. Servers on other machines are not experiancing this issue. Saint K. Saint K. ++ The machine we have problems with (ALL TF2 instances running on it) is running Fedora 10 x86_64. [2f...@wolf ~]$ rpm -q glibc glibc-2.9-3.i686 glibc-2.9-3.x86_64 [2f...@wolf ~]$ rpm -q libstdc++ libstdc++-4.3.2-7.x86_64 libstdc++-4.3.2-7.i386 [2f...@wolf ~]$ uname -r 2.6.27.15-170.2.24.fc10.x86_64 Ran fine til the update. I only run Sourcemod/Metamod and had just started using the Sourceop plugin to prevent the stringtable-related crashes in goldrush thanks to last week's update. But it occurs without any of these loaded as well. The user is not actually disconnecting, at least for us. They are still connected to the server. We don't see the disconnect by user message in the logs until the client disconencts from their menu after seeing the timeout in top right. If that helps any. From: hlds_linux-boun...@list.valvesoftware.com on behalf of Severian Sent: Fri 3/6/2009 1:28 PM To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] New update, new bull Happening to us too; it happens with or without plugins. The only disconnect reason in the logs is Disconnected by user, but clients see timeouts. Sometimes clients start hanging when trying to connect. Restart the server enough times, and it'll just get lucky and start working. This is a PITA though since I start/restart multiple servers with a script. Command line: ./srcds_run -game tf +ip 198.104.138.69 +port 27015 +fps_max 450 -debug -heapsize 10 +maxplayers 24 +map garbage_day +servercfgfile server_poe.cfg +mapcyclefile poecycle.txt +motdfile poe.txt server1.log 2server1.err Other info: - server_poe.cfg attached, autoexec.cfg is empty - RHE 5.2 on dual core, 2GB, dual 100mbps - no affinity set, irqbalance not running - kernel release 2.6.18-92.el5 Help! Sev It is extremely frustrating. The disconnects show as user disconnect Ronny Schedel wrote: Try without any server plugins. Right after the TF2 update I was having problems with some of my Linux servers where everyone would get disconnected after joining team or a class. Eventually, after restarting the server over and over, the problem goes away and people can connect and play fine. I talked to octohd and FLOOR_MASTER and they said they are getting the same problem. Anyone else? Thanks, Tony ___ 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 !DSPAM:3,49b12ce124131060472814! ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux !DSPAM:3,49b12ce124131060472814! ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
[hlds_linux] 3/6/09 update... F4!L
$SUBJECT Was this supposed to fix the problems with the Linux server failures in the 3/5/09 update? It didn't. This is why I would NEVER trust Valve to make any kind of recommendations about keeping gaming client machines up to date on drivers, etc. Impress me with something that is 100% yours to maintain first I'll take care of my stuff myself, TYVM. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] 3/6/09 update... F4!L
If you mean was it supposed to fix the issues that the change notes said are still being looked into then no, funnily enough, it wasn't. Before you get all high and mighty you might want to check your own statements aren't a pile of mince. Yeah, I'll buy that. And I'll also admit that I didn't read the changelog yet. I just saw one of my servers give me us the ZOMG Your server needs to be restarted to receive the latest updates notification and thought well WTF I'll give it a whirl. I mean, what possible harm could it do since we can't properly serve any players now whether I update or not anyway, thanks to yesterday's update? Since yet another ZOMFGUNEEDTHISUPDATERFN update was being forced on our servers, I thought it just might be relevant. Since after all I am *FAR* from the only Linux TF2 server operator having this problem. I keep asking myself why I spend my money for this. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
