Re: [hlds_linux] cpu on i7 920
What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there perhaps certain BIOS settings which could benefit when running gameservers on them? Ours surely should perform much better then that? Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 05:15 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I have a AMD Phenom x6 1055T doing multiple servers at the same time. TF2 causes the active core to go to 100% for about two seconds during map changes, but otherwise I've never seen it go that high for extended periods of time. Average during full 24-player usage is about 40%. I also have an older AMD Athlon64 x2 4600+ that runs a single 24-player TF2 quickplay server. It averages 70% usage when full and gameplay is great. Both of these are desktop class boards with DDR2 PC800M RAM. Linux 2.6.39. Try watching your CPU usage at (relatively) high resolution with something like htop -d 1 No clue why you are maxing out like that. Eric Riemers wrote: All, I run a 32 slots server on a i7 920 @ 2.67ghz, but i can see with top and such that its potentially maxing out at 100% at times since it only uses one core. Is it really now doing so much cpu that even a i7 core isn't enough? Didn't have much complaints before the pew pew. 24 slots on the same server do around 60% when full. Eric ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- # Jesse Molina # Mail = je...@opendreams.net # Page = page-je...@opendreams.net # Cell = 1.602.323.7608 # Web = http://www.opendreams.net/jesse/ ___ 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
Re: [hlds_linux] [hlds] Half-Life 1 engine beta update released
Hello Tested new beta build 5382 under FreeBSD 7.4 with Fedora Core linux emulator, on start I constantly receive error ipcserver.cpp (956) : Assertion Failed: FD_ISSET( fd, (fd_set *)m_pfdset ) Assert( Assertion Failed: FD_ISSET( fd, (fd_set *)m_pfdset ) ):/home/VALVE/alfred/valve/steam3_rel_client/src/clientdll/../common/ipcserver.cpp:956 and after some time threadtools.cpp (2674) : Assertion Failed: Failed to create thread (error 0xb) Assert( Assertion Failed: Failed to create thread (error 0xb) ):/home/VALVE/alfred/valve/steam3_rel_client/src/tier0/threadtools.cpp:2674 On other testbox with FreeBSD 8.2 first error also appear, don't have much time now to make more testing, though... -- С уважением, Px mailto:p...@i.kiev.ua ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] cpu on i7 920
Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there perhaps certain BIOS settings which could benefit when running gameservers on them? Ours surely should perform much better then that? Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 05:15 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I have a AMD Phenom x6 1055T doing multiple servers at the same time. TF2 causes the active core to go to 100% for about two seconds during map changes, but otherwise I've never seen it go that high for extended periods of time. Average during full 24-player usage is about 40%. I also have an older AMD Athlon64 x2 4600+ that runs a single 24-player TF2 quickplay server. It averages 70% usage when full and gameplay is great. Both of these are desktop class boards with DDR2 PC800M RAM. Linux 2.6.39. Try watching your CPU usage at (relatively) high resolution with something like htop -d 1 No clue why you are maxing out like that. Eric Riemers wrote: All, I run a 32 slots server on a i7 920 @ 2.67ghz, but i can see with top and such that its potentially maxing out at 100% at times since it only uses one core. Is it really now doing so much cpu that even a i7 core isn't enough? Didn't have much complaints before the pew pew. 24 slots on the same server do around 60% when full. Eric ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- # Jesse Molina # Mail = je...@opendreams.net # Page = page-je...@opendreams.net # Cell = 1.602.323.7608 # Web = http://www.opendreams.net/jesse/ ___ 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
Re: [hlds_linux] cpu on i7 920
The servers are build on Tyan Tempest i5400 motherboards, based on the Intel 5400B chipset platform, the Gbit nic's used on this board are Intel 82563EB chips. I've never really figured the load could be related to the networking chip as our throughput tests never really show any issues when tested (with all sorts of packet sizes, tcp/udp) Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 09:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there perhaps certain BIOS settings which could benefit when running gameservers on them? Ours surely should perform much better then that? Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 05:15 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I have a AMD Phenom x6 1055T doing multiple servers at the same time. TF2 causes the active core to go to 100% for about two seconds during map changes, but otherwise I've never seen it go that high for extended periods of time. Average during full 24-player usage is about 40%. I also have an older AMD Athlon64 x2 4600+ that runs a single 24-player TF2 quickplay server. It averages 70% usage when full and gameplay is great. Both of these are desktop class boards with DDR2 PC800M RAM. Linux 2.6.39. Try watching your CPU usage at (relatively) high resolution with something like htop -d 1 No clue why you are maxing out like that. Eric Riemers wrote: All, I run a 32 slots server on a i7 920 @ 2.67ghz, but i can see with top and such that its potentially maxing out at 100% at times since it only uses one core. Is it really now doing so much cpu that even a i7 core isn't enough? Didn't have much complaints before the pew pew. 24 slots on the same server do around 60% when full. Eric ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- # Jesse Molina # Mail = je...@opendreams.net # Page = page-je...@opendreams.net # Cell = 1.602.323.7608 # Web = http://www.opendreams.net/jesse/ ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] cpu on i7 920
I wouldn't expect problems with. But I happily admit to being no expert. Try ethtool -k interface and see what's what? A On 25/07/2011 08:42, Saint K. wrote: The servers are build on Tyan Tempest i5400 motherboards, based on the Intel 5400B chipset platform, the Gbit nic's used on this board are Intel 82563EB chips. I've never really figured the load could be related to the networking chip as our throughput tests never really show any issues when tested (with all sorts of packet sizes, tcp/udp) Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 09:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there perhaps certain BIOS settings which could benefit when running gameservers on them? Ours surely should perform much better then that? Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 05:15 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I have a AMD Phenom x6 1055T doing multiple servers at the same time. TF2 causes the active core to go to 100% for about two seconds during map changes, but otherwise I've never seen it go that high for extended periods of time. Average during full 24-player usage is about 40%. I also have an older AMD Athlon64 x2 4600+ that runs a single 24-player TF2 quickplay server. It averages 70% usage when full and gameplay is great. Both of these are desktop class boards with DDR2 PC800M RAM. Linux 2.6.39. Try watching your CPU usage at (relatively) high resolution with something like htop -d 1 No clue why you are maxing out like that. Eric Riemers wrote: All, I run a 32 slots server on a i7 920 @ 2.67ghz, but i can see with top and such that its potentially maxing out at 100% at times since it only uses one core. Is it really now doing so much cpu that even a i7 core isn't enough? Didn't have much complaints before the pew pew. 24 slots on the same server do around 60% when full. Eric ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- # Jesse Molina # Mail = je...@opendreams.net # Page = page-je...@opendreams.net # Cell = 1.602.323.7608 # Web = http://www.opendreams.net/jesse/ ___ 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 ___ 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
Re: [hlds_linux] cpu on i7 920
Hi, I am getting these values returned, not entirely sure what I am looking at; mrblonde:~# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off Does this appear to be good? I've checked the chipset specs and it supports checksum offloading. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 10:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 I wouldn't expect problems with. But I happily admit to being no expert. Try ethtool -k interface and see what's what? A On 25/07/2011 08:42, Saint K. wrote: The servers are build on Tyan Tempest i5400 motherboards, based on the Intel 5400B chipset platform, the Gbit nic's used on this board are Intel 82563EB chips. I've never really figured the load could be related to the networking chip as our throughput tests never really show any issues when tested (with all sorts of packet sizes, tcp/udp) Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 09:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there perhaps certain BIOS settings which could benefit when running gameservers on them? Ours surely should perform much better then that? Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 05:15 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I have a AMD Phenom x6 1055T doing multiple servers at the same time. TF2 causes the active core to go to 100% for about two seconds during map changes, but otherwise I've never seen it go that high for extended periods of time. Average during full 24-player usage is about 40%. I also have an older AMD Athlon64 x2 4600+ that runs a single 24-player TF2 quickplay server. It averages 70% usage when full and gameplay is great. Both of these are desktop class boards with DDR2 PC800M RAM. Linux 2.6.39. Try watching your CPU usage at (relatively) high resolution with something like htop -d 1 No clue why you are maxing out like that. Eric Riemers wrote: All, I run a 32 slots server on a i7 920 @ 2.67ghz, but i can see with top and such that its potentially maxing out at 100% at times since it only uses one core. Is it really now doing so much cpu that even a i7 core isn't enough? Didn't have much complaints before the pew pew. 24 slots on the same server do around 60% when full. Eric ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- # Jesse Molina # Mail = je...@opendreams.net # Page = page-je...@opendreams.net # Cell = 1.602.323.7608 # Web = http://www.opendreams.net/jesse/ ___ 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 ___ 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:
Re: [hlds_linux] cpu on i7 920
The network traffic that srcds uses is mostly udp, not tcp, so all the tcp driver offloading stuff is not involved here, for the most part. Any old network card should do. Not that the quality of the driver doesn't affect udp traffic. Some drivers can have trouble with large amounts of small udp traffic, or large udp traffic. The game server traffic here is quite modest though. I don't think anything networking related would be involved with the CPU problems (I'm a Cisco/Juniper network engineer and do high-bandwidth supercomputing stuff) Andrew Armitage wrote: Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. -- # Jesse Molina # Mail = je...@opendreams.net # Page = page-je...@opendreams.net # Cell = 1.602.323.7608 # Web = http://www.opendreams.net/jesse/ ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] cpu on i7 920
Thanks for that. Are there any non-kernel tips people can give to look at? Because if I hear the loads of other people somehow ours are much higher, regardless of the kernels used. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 11:42 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 The network traffic that srcds uses is mostly udp, not tcp, so all the tcp driver offloading stuff is not involved here, for the most part. Any old network card should do. Not that the quality of the driver doesn't affect udp traffic. Some drivers can have trouble with large amounts of small udp traffic, or large udp traffic. The game server traffic here is quite modest though. I don't think anything networking related would be involved with the CPU problems (I'm a Cisco/Juniper network engineer and do high-bandwidth supercomputing stuff) Andrew Armitage wrote: Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. -- # Jesse Molina # Mail = je...@opendreams.net # Page = page-je...@opendreams.net # Cell = 1.602.323.7608 # Web = http://www.opendreams.net/jesse/ ___ 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
Re: [hlds_linux] cpu on i7 920
map used? is the problem happening on stock maps with no mods too? on a 100% stock 32slot server running at 500fps on a realtime preempt kernel max single core cpu usage i saw was 45%... Il 25/07/2011 11:49, Saint K. ha scritto: Thanks for that. Are there any non-kernel tips people can give to look at? Because if I hear the loads of other people somehow ours are much higher, regardless of the kernels used. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 11:42 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 The network traffic that srcds uses is mostly udp, not tcp, so all the tcp driver offloading stuff is not involved here, for the most part. Any old network card should do. Not that the quality of the driver doesn't affect udp traffic. Some drivers can have trouble with large amounts of small udp traffic, or large udp traffic. The game server traffic here is quite modest though. I don't think anything networking related would be involved with the CPU problems (I'm a Cisco/Juniper network engineer and do high-bandwidth supercomputing stuff) Andrew Armitage wrote: Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. -- # Jesse Molina # Mail = je...@opendreams.net # Page = page-je...@opendreams.net # Cell = 1.602.323.7608 # Web = http://www.opendreams.net/jesse/ ___ 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
Re: [hlds_linux] cpu on i7 920
Hi, Yes - default stock maps, we run no custom maps. There is no real difference between running it with sourcemod or without. We have our SM configured very lightly primarily just for administration purposes. They are so called Vanilla servers (defaults), 24 slots. We generally see high loads, and low FPS values. The machine is installed with Debian Squeeze (64bit), build on (imo) proper hardware, Tyan mobo's with Intel's 5400 chipset, 2 Quadcore E5410's in the case of the 90+% load, and E5420's in case of the 70-80% load per core. Machines are equipped with 16GB ECC 1333Mhz memory, using Cheetah 15K.6 SAS drives dedicated to the gameserver installs. Nothing else but TF2 servers run off the machine with the 5410's, the 5420's also run our databases etc. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Marco Padovan [e...@evcz.tk] Sent: 25 July 2011 12:12 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 map used? is the problem happening on stock maps with no mods too? on a 100% stock 32slot server running at 500fps on a realtime preempt kernel max single core cpu usage i saw was 45%... Il 25/07/2011 11:49, Saint K. ha scritto: Thanks for that. Are there any non-kernel tips people can give to look at? Because if I hear the loads of other people somehow ours are much higher, regardless of the kernels used. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 11:42 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 The network traffic that srcds uses is mostly udp, not tcp, so all the tcp driver offloading stuff is not involved here, for the most part. Any old network card should do. Not that the quality of the driver doesn't affect udp traffic. Some drivers can have trouble with large amounts of small udp traffic, or large udp traffic. The game server traffic here is quite modest though. I don't think anything networking related would be involved with the CPU problems (I'm a Cisco/Juniper network engineer and do high-bandwidth supercomputing stuff) Andrew Armitage wrote: Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. -- # Jesse Molina # Mail = je...@opendreams.net # Page = page-je...@opendreams.net # Cell = 1.602.323.7608 # Web = http://www.opendreams.net/jesse/ ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] cpu on i7 920
Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24-player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the 150-limiting jumpers on by default. Saint K. wrote: Hi, I am getting these values returned, not entirely sure what I am looking at; mrblonde:~# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off Does this appear to be good? I've checked the chipset specs and it supports checksum offloading. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 10:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 I wouldn't expect problems with. But I happily admit to being no expert. Try ethtool -kinterface and see what's what? A On 25/07/2011 08:42, Saint K. wrote: The servers are build on Tyan Tempest i5400 motherboards, based on the Intel 5400B chipset platform, the Gbit nic's used on this board are Intel 82563EB chips. I've never really figured the load could be related to the networking chip as our throughput tests never really show any issues when tested (with all sorts of packet sizes, tcp/udp) Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 09:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there perhaps certain BIOS settings which could benefit when running gameservers on them? Ours surely should perform much better then that? Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 05:15 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I have a AMD Phenom x6 1055T doing multiple servers at the same time. TF2 causes the active core to go to 100% for about two seconds during map changes, but otherwise I've never seen it go that high for extended periods of time. Average during full 24-player usage is about 40%. I also have an older AMD Athlon64 x2 4600+ that runs a single 24-player TF2 quickplay server. It averages 70% usage when full and gameplay is great. Both of these are desktop class boards with DDR2 PC800M RAM. Linux 2.6.39. Try watching your CPU usage at (relatively) high resolution with something like htop -d 1 No clue why you are maxing out like that. Eric Riemers wrote: All, I run a 32 slots server on a i7 920 @ 2.67ghz, but i can see with top and such that its potentially maxing out at 100% at times since it only uses one core. Is it really now doing so much cpu that even a i7 core isn't enough? Didn't have much complaints before the pew pew. 24 slots on the same server do around 60% when full.
Re: [hlds_linux] cpu on i7 920
I've got a question about your kernel, is it patched with the RT-patch? I know that RT causes more stable fps but a lot higher cpu load. Date: Mon, 25 Jul 2011 03:36:10 -0700 From: je...@opendreams.net To: hlds_linux@list.valvesoftware.com CC: sai...@specialattack.net Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24-player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the 150-limiting jumpers on by default. Saint K. wrote: Hi, I am getting these values returned, not entirely sure what I am looking at; mrblonde:~# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off Does this appear to be good? I've checked the chipset specs and it supports checksum offloading. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 10:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 I wouldn't expect problems with. But I happily admit to being no expert. Try ethtool -kinterface and see what's what? A On 25/07/2011 08:42, Saint K. wrote: The servers are build on Tyan Tempest i5400 motherboards, based on the Intel 5400B chipset platform, the Gbit nic's used on this board are Intel 82563EB chips. I've never really figured the load could be related to the networking chip as our throughput tests never really show any issues when tested (with all sorts of packet sizes, tcp/udp) Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 09:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there perhaps certain BIOS settings which could benefit when running gameservers on them? Ours surely should perform much better then that? Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 05:15 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I have a AMD Phenom x6 1055T doing multiple servers at the same time. TF2 causes the active core to go to 100% for about two seconds during map changes, but otherwise I've never seen it go that high for extended periods of time. Average during full 24-player usage is about 40%. I also have an older AMD Athlon64 x2 4600+ that runs a single 24-player TF2 quickplay server. It averages 70% usage when full and gameplay is great. Both of these are desktop class boards with DDR2 PC800M RAM.
Re: [hlds_linux] cpu on i7 920
Hi, Not that I am aware of. We're currently running the stock kernel again; 2.6.32-5-amd64 I've tried several kernels suggested here before, but that didn't change anything either. I don't care much for high FPS, currently our servers are running at a very low 40-ish FPS on high load, and you can't notice too much performance issues. So I'd much rather run around 66-ish FPS and have a lower CPU load. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Michael Johansen [michs...@live.no] Sent: 25 July 2011 12:44 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 I've got a question about your kernel, is it patched with the RT-patch? I know that RT causes more stable fps but a lot higher cpu load. Date: Mon, 25 Jul 2011 03:36:10 -0700 From: je...@opendreams.net To: hlds_linux@list.valvesoftware.com CC: sai...@specialattack.net Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24-player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the 150-limiting jumpers on by default. Saint K. wrote: Hi, I am getting these values returned, not entirely sure what I am looking at; mrblonde:~# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off Does this appear to be good? I've checked the chipset specs and it supports checksum offloading. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 10:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 I wouldn't expect problems with. But I happily admit to being no expert. Try ethtool -kinterface and see what's what? A On 25/07/2011 08:42, Saint K. wrote: The servers are build on Tyan Tempest i5400 motherboards, based on the Intel 5400B chipset platform, the Gbit nic's used on this board are Intel 82563EB chips. I've never really figured the load could be related to the networking chip as our throughput tests never really show any issues when tested (with all sorts of packet sizes, tcp/udp) Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 09:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there perhaps certain BIOS settings which could benefit when running gameservers on them? Ours surely should perform much better then that? Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf
Re: [hlds_linux] cpu on i7 920
Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24-player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the 150-limiting jumpers on by default. Saint K. wrote: Hi, I am getting these values returned, not entirely sure what I am looking at; mrblonde:~# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off Does this appear to be good? I've checked the chipset specs and it supports checksum offloading. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 10:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 I wouldn't expect problems with. But I happily admit to being no expert. Try ethtool -kinterface and see what's what? A On 25/07/2011 08:42, Saint K. wrote: The servers are build on Tyan Tempest i5400 motherboards, based on the Intel 5400B chipset platform, the Gbit nic's used on this board are Intel 82563EB chips. I've never really figured the load could be related to the networking chip as our throughput tests never really show any issues when tested (with all sorts of packet sizes, tcp/udp) Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 09:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there perhaps certain BIOS settings which could benefit when running gameservers on them? Ours surely should perform much better then that? Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 05:15 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I have a AMD Phenom x6 1055T doing multiple servers at the same time. TF2 causes the active core to go to 100% for about two seconds during map changes, but otherwise I've never seen it go that high for extended periods of time. Average
Re: [hlds_linux] cpu on i7 920
Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24-player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the 150-limiting jumpers on by default. Saint K. wrote: Hi, I am getting these values returned, not entirely sure what I am looking at; mrblonde:~# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off Does this appear to be good? I've checked the chipset specs and it supports checksum offloading. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 10:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 I wouldn't expect problems with. But I happily admit to being no expert. Try ethtool -kinterface and see what's what? A On 25/07/2011 08:42, Saint K. wrote: The servers are build on Tyan Tempest i5400 motherboards, based on the Intel 5400B chipset platform, the Gbit nic's used on this board are Intel 82563EB chips. I've never really figured the load could be related to the networking chip as our throughput tests never really show any issues when tested (with all sorts of packet sizes, tcp/udp) Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 09:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there perhaps certain BIOS settings which could benefit when running gameservers on them? Ours surely should perform much better then that? Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 05:15 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I have a AMD Phenom x6 1055T doing multiple servers at the same time. TF2 causes the active
Re: [hlds_linux] cpu on i7 920
Everytime a new weapon goes 'pew pew' the laser destroys a section of your CPU. It's a new feature. On 25/07/2011 12:14, Andres Pozos javato...@yahoo.es wrote: Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24-player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the 150-limiting jumpers on by default. Saint K. wrote: Hi, I am getting these values returned, not entirely sure what I am looking at; mrblonde:~# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off Does this appear to be good? I've checked the chipset specs and it supports checksum offloading. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 10:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 I wouldn't expect problems with. But I happily admit to being no expert. Try ethtool -kinterface and see what's what? A On 25/07/2011 08:42, Saint K. wrote: The servers are build on Tyan Tempest i5400 motherboards, based on the Intel 5400B chipset platform, the Gbit nic's used on this board are Intel 82563EB chips. I've never really figured the load could be related to the networking chip as our throughput tests never really show any issues when tested (with all sorts of packet sizes, tcp/udp) Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 09:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there perhaps certain BIOS settings which could benefit when running gameservers on them? Ours surely should perform much better then that? Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of
Re: [hlds_linux] cpu on i7 920
I tried to run 32 slots x2 on my Core2Duo dedicated server. It used 80% cpu and nothing more. However, fps drops were to 1 and shit, so i cba to host them. Date: Mon, 25 Jul 2011 12:14:45 +0100 From: javato...@yahoo.es To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24-player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the 150-limiting jumpers on by default. Saint K. wrote: Hi, I am getting these values returned, not entirely sure what I am looking at; mrblonde:~# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off Does this appear to be good? I've checked the chipset specs and it supports checksum offloading. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 10:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 I wouldn't expect problems with. But I happily admit to being no expert. Try ethtool -kinterface and see what's what? A On 25/07/2011 08:42, Saint K. wrote: The servers are build on Tyan Tempest i5400 motherboards, based on the Intel 5400B chipset platform, the Gbit nic's used on this board are Intel 82563EB chips. I've never really figured the load could be related to the networking chip as our throughput tests never really show any issues when tested (with all sorts of packet sizes, tcp/udp) Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 09:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for 24 players, and our Xeon E5410's 90%+, where you say your older 4600+ does 70%. Tried all sorts of different kernels out there. Is there
Re: [hlds_linux] cpu on i7 920
I could live with that, at least knowing a reason why my 3000,- euro hardware can only sustain 7-ish 24 slots TF2 servers. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of James Botting [bottswan...@googlemail.com] Sent: 25 July 2011 13:18 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 Everytime a new weapon goes 'pew pew' the laser destroys a section of your CPU. It's a new feature. On 25/07/2011 12:14, Andres Pozos javato...@yahoo.es wrote: Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24-player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the 150-limiting jumpers on by default. Saint K. wrote: Hi, I am getting these values returned, not entirely sure what I am looking at; mrblonde:~# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off Does this appear to be good? I've checked the chipset specs and it supports checksum offloading. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 10:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 I wouldn't expect problems with. But I happily admit to being no expert. Try ethtool -kinterface and see what's what? A On 25/07/2011 08:42, Saint K. wrote: The servers are build on Tyan Tempest i5400 motherboards, based on the Intel 5400B chipset platform, the Gbit nic's used on this board are Intel 82563EB chips. I've never really figured the load could be related to the networking chip as our throughput tests never really show any issues when tested (with all sorts of packet sizes, tcp/udp) Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Andrew Armitage [and...@thirdlife.org] Sent: 25 July 2011 09:36 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. A On 25/07/2011 07:28, Saint K. wrote: What I am still not getting is that our Xeon E5420's are doing like 70-80% load on a single core for
Re: [hlds_linux] cpu on i7 920
How load averages and cpu usage depends a lot from the kernel. I believe individual process usage more than core load or load averages. For example, if you look with top program, you might see something like this: load average: 0.34, 0.42, 0.23 Cpu0 : 29.0%us, 0.5%sy, 0.0%ni, 66.8%id, 0.5%wa, 0.0%hi, 2.2%si, 1.0%st Cpu1 : 26.0%us, 0.7%sy, 0.0%ni, 70.4%id, 1.1%wa, 0.0%hi, 0.7%si, 1.1%st and when you look at the process list below that stuff, you might see the real values: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 32094 game 20 0 493m 356m 11m R 61 17.8 638:30.00 srcds_linux 1499 game 20 0 487m 359m 11m S 54 17.9 516:56.58 srcds_linux So i'd rather believe the values in process list than the summary above. Then again, on our other bigger machine, the values are a bit different. The summary again: load average: 4.63, 5.07, 5.35 Cpu0 : 16.3%us, 0.0%sy, 0.0%ni, 82.4%id, 0.3%wa, 0.0%hi, 1.0%si, 0.0%st Cpu1 : 73.1%us, 0.7%sy, 0.0%ni, 25.6%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 97.7%id, 2.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu3 : 68.1%us, 1.0%sy, 0.0%ni, 30.2%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st And the process info: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7339 game 20 0 392m 258m 21m S 78 3.3 91:41.36 srcds_linux 10288 game 20 0 399m 275m 21m R 73 3.5 38:46.18 srcds_linux 7262 game 20 0 317m 201m 15m S 18 2.5 195:01.39 srcds_linux 5686 game20 0 341m 157m 12m R2 2.0 11:07.86 srcds_linux As you can see, the differences are caused by different kernels. We had 2.6.37 or something where there was constant 16-20 load average while the cpu stats where the same, just load went bonkers. Never seen 100% unless the server is stuck like it has been couple of times since the lazor update. It might be i7 issue, we have older machines. -ics 25.7.2011 14:22, Saint K. kirjoitti: I could live with that, at least knowing a reason why my 3000,- euro hardware can only sustain 7-ish 24 slots TF2 servers. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of James Botting [bottswan...@googlemail.com] Sent: 25 July 2011 13:18 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 Everytime a new weapon goes 'pew pew' the laser destroys a section of your CPU. It's a new feature. On 25/07/2011 12:14, Andres Pozosjavato...@yahoo.es wrote: Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24-player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the
Re: [hlds_linux] cpu on i7 920
Very weird... I'm having some boxes running cheap desktop hardware (i7 930 for example) and doing very good (even with very extreme realtime kernels...) Never used debian in gameservers environment tho centos only here... Il 25/07/2011 12:28, Saint K. ha scritto: Hi, Yes - default stock maps, we run no custom maps. There is no real difference between running it with sourcemod or without. We have our SM configured very lightly primarily just for administration purposes. They are so called Vanilla servers (defaults), 24 slots. We generally see high loads, and low FPS values. The machine is installed with Debian Squeeze (64bit), build on (imo) proper hardware, Tyan mobo's with Intel's 5400 chipset, 2 Quadcore E5410's in the case of the 90+% load, and E5420's in case of the 70-80% load per core. Machines are equipped with 16GB ECC 1333Mhz memory, using Cheetah 15K.6 SAS drives dedicated to the gameserver installs. Nothing else but TF2 servers run off the machine with the 5410's, the 5420's also run our databases etc. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Marco Padovan [e...@evcz.tk] Sent: 25 July 2011 12:12 To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] cpu on i7 920 map used? is the problem happening on stock maps with no mods too? on a 100% stock 32slot server running at 500fps on a realtime preempt kernel max single core cpu usage i saw was 45%... Il 25/07/2011 11:49, Saint K. ha scritto: Thanks for that. Are there any non-kernel tips people can give to look at? Because if I hear the loads of other people somehow ours are much higher, regardless of the kernels used. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 11:42 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 The network traffic that srcds uses is mostly udp, not tcp, so all the tcp driver offloading stuff is not involved here, for the most part. Any old network card should do. Not that the quality of the driver doesn't affect udp traffic. Some drivers can have trouble with large amounts of small udp traffic, or large udp traffic. The game server traffic here is quite modest though. I don't think anything networking related would be involved with the CPU problems (I'm a Cisco/Juniper network engineer and do high-bandwidth supercomputing stuff) Andrew Armitage wrote: Maybe the issue is the network hardware? HLDS is very network intensive. I believe that some cards support checksum offloading and some don't. -- # Jesse Molina # Mail = je...@opendreams.net # Page = page-je...@opendreams.net # Cell = 1.602.323.7608 # Web = http://www.opendreams.net/jesse/ ___ 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 ___ 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
Re: [hlds_linux] cpu on i7 920
I use a combination of top and htop to monitor the servers usage. I generally ignore the load av. value, as you point out, per kernel this can be completely different. Generally I use top to view al the servers load per process, here's an example output of top with 5 loaded TF2 servers; 25668 tf2 -21 -20 486m 349m 21m R 97 4.4 177:05.31 srcds_linux 26408 tf2 -21 -20 647m 475m 21m R 93 5.9 696:37.88 srcds_linux 32345 tf2 -21 -20 442m 306m 21m R 90 3.8 133:28.53 srcds_linux 3297 tf2 -21 -20 397m 269m 21m R 85 3.4 38:07.04 srcds_linux 25736 tf2 -21 -20 533m 383m 21m S 68 4.8 180:19.68 srcds_linux Cpu0 : 72.3%us, 0.4%sy, 0.0%ni, 26.3%id, 0.0%wa, 0.0%hi, 0.9%si, 0.0%st Cpu1 : 73.3%us, 0.0%sy, 0.0%ni, 26.2%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st Cpu2 : 66.1%us, 0.0%sy, 0.0%ni, 33.5%id, 0.0%wa, 0.0%hi, 0.5%si, 0.0%st Cpu3 : 70.2%us, 0.0%sy, 0.0%ni, 29.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 76.2%us, 0.0%sy, 0.0%ni, 23.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu5 : 71.6%us, 0.5%sy, 0.0%ni, 28.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 68.5%us, 0.5%sy, 0.0%ni, 31.1%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 67.1%us, 2.3%sy, 0.0%ni, 30.2%id, 0.0%wa, 0.0%hi, 0.5%si, 0.0%st load average: 6.84 Overall seen per cpu this is around 70-80% load steady, grouped together this comes to 73% overall load. htop shows 100+ CPU load per process, so not sure what to think of that, the overall load output per CPU however reads the same as top does. Mind you, this when 5 of the 7 servers are full. I generally assign 1 server per CPU core, and leave 1 core free for all OS stuff to be handled on. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of ics [i...@ics-base.net] Sent: 25 July 2011 13:42 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 How load averages and cpu usage depends a lot from the kernel. I believe individual process usage more than core load or load averages. For example, if you look with top program, you might see something like this: load average: 0.34, 0.42, 0.23 Cpu0 : 29.0%us, 0.5%sy, 0.0%ni, 66.8%id, 0.5%wa, 0.0%hi, 2.2%si, 1.0%st Cpu1 : 26.0%us, 0.7%sy, 0.0%ni, 70.4%id, 1.1%wa, 0.0%hi, 0.7%si, 1.1%st and when you look at the process list below that stuff, you might see the real values: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 32094 game 20 0 493m 356m 11m R 61 17.8 638:30.00 srcds_linux 1499 game 20 0 487m 359m 11m S 54 17.9 516:56.58 srcds_linux So i'd rather believe the values in process list than the summary above. Then again, on our other bigger machine, the values are a bit different. The summary again: load average: 4.63, 5.07, 5.35 Cpu0 : 16.3%us, 0.0%sy, 0.0%ni, 82.4%id, 0.3%wa, 0.0%hi, 1.0%si, 0.0%st Cpu1 : 73.1%us, 0.7%sy, 0.0%ni, 25.6%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 97.7%id, 2.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu3 : 68.1%us, 1.0%sy, 0.0%ni, 30.2%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st And the process info: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7339 game 20 0 392m 258m 21m S 78 3.3 91:41.36 srcds_linux 10288 game 20 0 399m 275m 21m R 73 3.5 38:46.18 srcds_linux 7262 game 20 0 317m 201m 15m S 18 2.5 195:01.39 srcds_linux 5686 game20 0 341m 157m 12m R2 2.0 11:07.86 srcds_linux As you can see, the differences are caused by different kernels. We had 2.6.37 or something where there was constant 16-20 load average while the cpu stats where the same, just load went bonkers. Never seen 100% unless the server is stuck like it has been couple of times since the lazor update. It might be i7 issue, we have older machines. -ics 25.7.2011 14:22, Saint K. kirjoitti: I could live with that, at least knowing a reason why my 3000,- euro hardware can only sustain 7-ish 24 slots TF2 servers. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of James Botting [bottswan...@googlemail.com] Sent: 25 July 2011 13:18 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 Everytime a new weapon goes 'pew pew' the laser destroys a section of your CPU. It's a new feature. On 25/07/2011 12:14, Andres Pozosjavato...@yahoo.es wrote: Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS
Re: [hlds_linux] cpu on i7 920
Regardless of CPU usage you're going to struggle running more servers than that. The thing is, it's not that the servers use a lot of CPU*, it's just that when they need it, they need it _NOW_, or else they miss their window and the framerate drops. The more things running per core, the higher the chance that something else will stop a server getting its slice when it needs it. *actually, they _DO_, but the point would stand even if they didn't This is why I find load average useful; it can point out overloading (if LA number of threads your server has) even when the CPU load isn't showing 100% Re: assigning servers to cores - this is going back about 3 years, but I noticed that gameservers liked to jump cores about every 30 seconds or so... but if I pinned them to a core, they'd lag for a split-second around every 30 seconds or so instead. No idea if that was the OS or the server, and we've not tested again since, but we've had little issue leaving them to roam free. -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux- boun...@list.valvesoftware.com] On Behalf Of Saint K. Sent: 25 July 2011 12:22 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I could live with that, at least knowing a reason why my 3000,- euro hardware can only sustain 7-ish 24 slots TF2 servers. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux- boun...@list.valvesoftware.com] On Behalf Of James Botting [bottswan...@googlemail.com] Sent: 25 July 2011 13:18 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 Everytime a new weapon goes 'pew pew' the laser destroys a section of your CPU. It's a new feature. On 25/07/2011 12:14, Andres Pozos javato...@yahoo.es wrote: Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24- player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the 150-limiting jumpers on by default. Saint K. wrote: Hi, I am getting these values returned, not entirely sure what I am looking at; mrblonde:~# ethtool -k eth0 Offload parameters for eth0: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: off udp-fragmentation-offload: off generic-segmentation-offload: on generic-receive-offload: off large-receive-offload: off ntuple-filters: off receive-hashing: off Does this appear to be good? I've checked the chipset specs and it supports checksum offloading. Saint K.
Re: [hlds_linux] cpu on i7 920
I forgot to mention that some of the default maps are also pretty cpu itensive comparing to the others. Hoodoo, Frontier, Thundermountain, Hydro. There's couple of examples. Propably this is due to all of them having very large open areas within them like let's say, gold rush, dustbowl, etc narrow maps. It also depends on what effects the maps use and how they are built. Difference between dustbowl and hoodoo cpu usage can be 5-10% or even more. -ics 25.7.2011 14:56, gamead...@127001.org kirjoitti: Regardless of CPU usage you're going to struggle running more servers than that. The thing is, it's not that the servers use a lot of CPU*, it's just that when they need it, they need it _NOW_, or else they miss their window and the framerate drops. The more things running per core, the higher the chance that something else will stop a server getting its slice when it needs it. *actually, they _DO_, but the point would stand even if they didn't This is why I find load average useful; it can point out overloading (if LA number of threads your server has) even when the CPU load isn't showing 100% Re: assigning servers to cores - this is going back about 3 years, but I noticed that gameservers liked to jump cores about every 30 seconds or so... but if I pinned them to a core, they'd lag for a split-second around every 30 seconds or so instead. No idea if that was the OS or the server, and we've not tested again since, but we've had little issue leaving them to roam free. -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux- boun...@list.valvesoftware.com] On Behalf Of Saint K. Sent: 25 July 2011 12:22 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I could live with that, at least knowing a reason why my 3000,- euro hardware can only sustain 7-ish 24 slots TF2 servers. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux- boun...@list.valvesoftware.com] On Behalf Of James Botting [bottswan...@googlemail.com] Sent: 25 July 2011 13:18 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 Everytime a new weapon goes 'pew pew' the laser destroys a section of your CPU. It's a new feature. On 25/07/2011 12:14, Andres Pozosjavato...@yahoo.es wrote: Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24- player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the 150-limiting jumpers on by default. Saint K. wrote: Hi, I am getting these values returned, not entirely sure what I am looking at; mrblonde:~# ethtool -k eth0 Offload parameters for eth0: rx-checksumming:
Re: [hlds_linux] cpu on i7 920
Hi, My concern is not really to have more servers on there (although it be nice if possible), but I'd like to get at least 66+fps stable per server per core, and having some load left to have replay etc enabled, as we had to kill that as well to get things running on the edge of normal. I've also tried assigning it per core, but never found clear bennifits to do so. The keeping one core free is just the thought process, leaves some room for other processes to peak (if required). Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of gamead...@127001.org [gamead...@127001.org] Sent: 25 July 2011 13:56 To: 'Half-Life dedicated Linux server mailing list' Subject: Re: [hlds_linux] cpu on i7 920 Regardless of CPU usage you're going to struggle running more servers than that. The thing is, it's not that the servers use a lot of CPU*, it's just that when they need it, they need it _NOW_, or else they miss their window and the framerate drops. The more things running per core, the higher the chance that something else will stop a server getting its slice when it needs it. *actually, they _DO_, but the point would stand even if they didn't This is why I find load average useful; it can point out overloading (if LA number of threads your server has) even when the CPU load isn't showing 100% Re: assigning servers to cores - this is going back about 3 years, but I noticed that gameservers liked to jump cores about every 30 seconds or so... but if I pinned them to a core, they'd lag for a split-second around every 30 seconds or so instead. No idea if that was the OS or the server, and we've not tested again since, but we've had little issue leaving them to roam free. -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux- boun...@list.valvesoftware.com] On Behalf Of Saint K. Sent: 25 July 2011 12:22 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I could live with that, at least knowing a reason why my 3000,- euro hardware can only sustain 7-ish 24 slots TF2 servers. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux- boun...@list.valvesoftware.com] On Behalf Of James Botting [bottswan...@googlemail.com] Sent: 25 July 2011 13:18 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 Everytime a new weapon goes 'pew pew' the laser destroys a section of your CPU. It's a new feature. On 25/07/2011 12:14, Andres Pozos javato...@yahoo.es wrote: Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24- player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have
Re: [hlds_linux] cpu on i7 920
Knowing that each new cpu generation have more cores and less cpu cycles its pointless to keep using a engine that doesnt support multicore. I forgot to mention that some of the default maps are also pretty cpu itensive comparing to the others. Hoodoo, Frontier, Thundermountain, Hydro. There's couple of examples. Propably this is due to all of them having very large open areas within them like let's say, gold rush, dustbowl, etc narrow maps. It also depends on what effects the maps use and how they are built. Difference between dustbowl and hoodoo cpu usage can be 5-10% or even more. -ics 25.7.2011 14:56, gamead...@127001.org kirjoitti: Regardless of CPU usage you're going to struggle running more servers than that. The thing is, it's not that the servers use a lot of CPU*, it's just that when they need it, they need it _NOW_, or else they miss their window and the framerate drops. The more things running per core, the higher the chance that something else will stop a server getting its slice when it needs it. *actually, they _DO_, but the point would stand even if they didn't This is why I find load average useful; it can point out overloading (if LA number of threads your server has) even when the CPU load isn't showing 100% Re: assigning servers to cores - this is going back about 3 years, but I noticed that gameservers liked to jump cores about every 30 seconds or so... but if I pinned them to a core, they'd lag for a split-second around every 30 seconds or so instead. No idea if that was the OS or the server, and we've not tested again since, but we've had little issue leaving them to roam free. -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux- boun...@list.valvesoftware.com] On Behalf Of Saint K. Sent: 25 July 2011 12:22 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I could live with that, at least knowing a reason why my 3000,- euro hardware can only sustain 7-ish 24 slots TF2 servers. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux- boun...@list.valvesoftware.com] On Behalf Of James Botting [bottswan...@googlemail.com] Sent: 25 July 2011 13:18 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 Everytime a new weapon goes 'pew pew' the laser destroys a section of your CPU. It's a new feature. On 25/07/2011 12:14, Andres Pozosjavato...@yahoo.es wrote: Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24- player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers. I really have no idea what I'm talking about. I've only been messing with srcds servers for the last nine months or so. Then again... Seagate did ship me all of those SATA 300 drives with the 150-limiting jumpers on by default. Saint K. wrote: Hi,
Re: [hlds_linux] cpu on i7 920
I only have issues on the box with the 32 slots server, and since tf2 is build for 24 i dont think there will be any performance increases in this area. The 24 slots sit around 60/70% and i've got no complaints from there (except for the few that always complain) Also if you have hlxce running or similar you can usually see your serverside fps too, not that this matters that much but if you see drops below 66 it could be cpu, at least a reference point to look at if people complain about lag. Still running an older distro of debian on that box though, perhaps a upgrade would do some good i presume too. On Mon, 25 Jul 2011 14:05:10 +0200, Saint K. sai...@specialattack.net wrote: Hi, My concern is not really to have more servers on there (although it be nice if possible), but I'd like to get at least 66+fps stable per server per core, and having some load left to have replay etc enabled, as we had to kill that as well to get things running on the edge of normal. I've also tried assigning it per core, but never found clear bennifits to do so. The keeping one core free is just the thought process, leaves some room for other processes to peak (if required). Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of gamead...@127001.org [gamead...@127001.org] Sent: 25 July 2011 13:56 To: 'Half-Life dedicated Linux server mailing list' Subject: Re: [hlds_linux] cpu on i7 920 Regardless of CPU usage you're going to struggle running more servers than that. The thing is, it's not that the servers use a lot of CPU*, it's just that when they need it, they need it _NOW_, or else they miss their window and the framerate drops. The more things running per core, the higher the chance that something else will stop a server getting its slice when it needs it. *actually, they _DO_, but the point would stand even if they didn't This is why I find load average useful; it can point out overloading (if LA number of threads your server has) even when the CPU load isn't showing 100% Re: assigning servers to cores - this is going back about 3 years, but I noticed that gameservers liked to jump cores about every 30 seconds or so... but if I pinned them to a core, they'd lag for a split-second around every 30 seconds or so instead. No idea if that was the OS or the server, and we've not tested again since, but we've had little issue leaving them to roam free. -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux- boun...@list.valvesoftware.com] On Behalf Of Saint K. Sent: 25 July 2011 12:22 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I could live with that, at least knowing a reason why my 3000,- euro hardware can only sustain 7-ish 24 slots TF2 servers. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux- boun...@list.valvesoftware.com] On Behalf Of James Botting [bottswan...@googlemail.com] Sent: 25 July 2011 13:18 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 Everytime a new weapon goes 'pew pew' the laser destroys a section of your CPU. It's a new feature. On 25/07/2011 12:14, Andres Pozos javato...@yahoo.es wrote: Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24-
Re: [hlds_linux] cpu on i7 920
On our servers we have noticed that cpu0 is used by the OP (Debian/Fedora) and accordingly we cant use that core for any gameservers. Peter Sweden ics skrev 2011-07-25 13:42: How load averages and cpu usage depends a lot from the kernel. I believe individual process usage more than core load or load averages. For example, if you look with top program, you might see something like this: load average: 0.34, 0.42, 0.23 Cpu0 : 29.0%us, 0.5%sy, 0.0%ni, 66.8%id, 0.5%wa, 0.0%hi, 2.2%si, 1.0%st Cpu1 : 26.0%us, 0.7%sy, 0.0%ni, 70.4%id, 1.1%wa, 0.0%hi, 0.7%si, 1.1%st and when you look at the process list below that stuff, you might see the real values: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 32094 game 20 0 493m 356m 11m R 61 17.8 638:30.00 srcds_linux 1499 game 20 0 487m 359m 11m S 54 17.9 516:56.58 srcds_linux So i'd rather believe the values in process list than the summary above. Then again, on our other bigger machine, the values are a bit different. The summary again: load average: 4.63, 5.07, 5.35 Cpu0 : 16.3%us, 0.0%sy, 0.0%ni, 82.4%id, 0.3%wa, 0.0%hi, 1.0%si, 0.0%st Cpu1 : 73.1%us, 0.7%sy, 0.0%ni, 25.6%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 97.7%id, 2.0%wa, 0.0%hi, 0.3%si, 0.0%st Cpu3 : 68.1%us, 1.0%sy, 0.0%ni, 30.2%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st And the process info: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 7339 game 20 0 392m 258m 21m S 78 3.3 91:41.36 srcds_linux 10288 game 20 0 399m 275m 21m R 73 3.5 38:46.18 srcds_linux 7262 game 20 0 317m 201m 15m S 18 2.5 195:01.39 srcds_linux 5686 game20 0 341m 157m 12m R2 2.0 11:07.86 srcds_linux As you can see, the differences are caused by different kernels. We had 2.6.37 or something where there was constant 16-20 load average while the cpu stats where the same, just load went bonkers. Never seen 100% unless the server is stuck like it has been couple of times since the lazor update. It might be i7 issue, we have older machines. -ics 25.7.2011 14:22, Saint K. kirjoitti: I could live with that, at least knowing a reason why my 3000,- euro hardware can only sustain 7-ish 24 slots TF2 servers. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of James Botting [bottswan...@googlemail.com] Sent: 25 July 2011 13:18 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 Everytime a new weapon goes 'pew pew' the laser destroys a section of your CPU. It's a new feature. On 25/07/2011 12:14, Andres Pozosjavato...@yahoo.es wrote: Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to cause such significant problems. I have no clue. Grab an old cruddy desktop, set it up on your home network, do a quickplay qualified server, and then watch how it runs. Use the same OS and versions you are using on your server and then start twiddling. You only need about a 2Mbps upstream rate for a 24-player server. I would blame software way before I started blaming hardware. Actually, I'd blame something you did unknowingly, first, but just because I'm a BOFH. People like to throw switches in the desperate hope that one of them was put there by system developers specifically just to slow things down, like a turbo switch on an old 486DX. Surely, my sheer desire to make things go faster and by randomly throwing every bios setting, recompiling my kernel with obscure realtime patches I found, enabling weird sysctrl parameters, and buying a Bigfoot gaming NIC will make things go faster! And that's why we have fps_max 1000 and 100PPS update/cmd rates on servers.
Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update
This isn't server-related, but Cow Mangler 5000 can be reflected, Righteous Bison can't be reflected (and this is noted in the item description for it). On Mon, Jul 25, 2011 at 12:37 AM, clad iron cladi...@gmail.com wrote: I can vouch for the crashes also. (Windows and Linux) I was just playing on a server and it crashed. I think i may have caused it. Can anyone else try to repeat it? I was playing as pyro with the degreaser and a soldier was firing at me from across the map with The Righteous Bison. I attempted to reflect the shot back at him. None seemed to have reflected and i'm not to bad. He killed me and i started to spawn. just as i spawn the server crashed. Also i thought earlier i had reflected 1, but i'm unsure due to all the lazier glare in my screen. (those should be made narrower,and maybe brighten it some since it would be smaller in diameter. IMO..) On Sun, Jul 24, 2011 at 1:38 PM, Aaron DJ Zyrphon Thompson rmesc...@gmail.com wrote: I tried disabling mantreads and the new laser weapons but still getting a crash as of this morning. What are all the new weapon names like tf_mantreads that format. My saxton hale server is making sad faces. Sent from my MOTOBLUR™ smartphone on ATT -Original message- From: daniel jokiaho daniel.joki...@gmail.com To: Half-Life dedicated Linux server mailing list hlds_linux@list.valvesoftware.com Sent: Sun, Jul 24, 2011 17:18:35 GMT+00:00 Subject: Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update howto disable replays? And new weapons? On 24 Jul 2011 18:12, Andrew Armitage and...@thirdlife.org wrote: We have had replays disabled almost since they were introduced, as they seemed to cause crashes. Today we have also disabled the new weapons, and we've been crash free again since. According to one of our regular players: This server will ever be a Retro Server No Updates Thats pretty cooler because everybody is updating! And this server not! Thats what makes it unusual Hurrah for being unusual I guess. A On 24/07/2011 18:04, Ross Bemrose wrote: I disabled replays on all my TF2 servers yesterday afternoon, and they have yet to crash or freeze since. Therefore, I'm assuming it's a replay-related crash. That doesn't rule out the new weapons being the ultimate cause, though. On 7/23/2011 2:32 PM, Yuki wrote: A weird crash this time. Someone joined the server and saw a teleporter built by no one, upon going through it, there was a crash. Unsure whether the missing name was a client side issue, but the fact that the server managed to crash at the same time is odd. No memory corruption and similar error this time however. PreMinidumpCallback: updating dump comment Uploading dump (in-process) [proxy ''] /tmp/dumps/crash_20110723191817_1.dmp success = yes response: CrashID=bp-445d6055-e9e7-420a-93b8-688a92110723 On 23 July 2011 18:03, Aaron DJ Zyrphon Thompsonrmesc...@gmail.comwrote: The only server I have crashing is my VS Saxton Hale server. I'm thinking a fresh SM install will solve the problem. Sent from my MOTOBLUR™ smartphone on ATT -Original message- From: Michael Johansenmichs...@live.no To: hlds_linux@list.valvesoftware.com Sent: Sat, Jul 23, 2011 16:41:22 GMT+00:00 Subject: Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update Hm.. I haven't had a crash since the updates. Anyways, VALVE: Any progress on fixing the issue? Date: Sat, 23 Jul 2011 16:39:30 +0100 From: d...@dazzozo.com To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update I just crashed at the exact same time. Seeing as we're all using Pastebin: http://pastebin.com/wigab20i Are these definitely related to the new weapons or not? On 23 July 2011 16:37, Peter Reinholdpeter_va...@reinhold.dk wrote: On Sat, 23 Jul 2011 00:22:25 -0400, E3pO wrote: Servers are still crashing like crazy. Just got a lock-up crash. Output: http://pastebin.com/mzNG71Rm /Peter __**_ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] cpu on i7 920
To get a true picture on the cpu load you have to monitor both the machines cpu-usage by core, and the srcds instances usage of cpu. This can be monitored by munin. Offcource it can also monitor fps, no.off players, uptime and the network traffic on the nic by port. But dont forget to monitor the memory usage on the machine. Its a easy way to find errors. Peter Sweden Eric Riemers skrev 2011-07-25 15:04: I only have issues on the box with the 32 slots server, and since tf2 is build for 24 i dont think there will be any performance increases in this area. The 24 slots sit around 60/70% and i've got no complaints from there (except for the few that always complain) Also if you have hlxce running or similar you can usually see your serverside fps too, not that this matters that much but if you see drops below 66 it could be cpu, at least a reference point to look at if people complain about lag. Still running an older distro of debian on that box though, perhaps a upgrade would do some good i presume too. On Mon, 25 Jul 2011 14:05:10 +0200, Saint K.sai...@specialattack.net wrote: Hi, My concern is not really to have more servers on there (although it be nice if possible), but I'd like to get at least 66+fps stable per server per core, and having some load left to have replay etc enabled, as we had to kill that as well to get things running on the edge of normal. I've also tried assigning it per core, but never found clear bennifits to do so. The keeping one core free is just the thought process, leaves some room for other processes to peak (if required). Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux-boun...@list.valvesoftware.com] On Behalf Of gamead...@127001.org [gamead...@127001.org] Sent: 25 July 2011 13:56 To: 'Half-Life dedicated Linux server mailing list' Subject: Re: [hlds_linux] cpu on i7 920 Regardless of CPU usage you're going to struggle running more servers than that. The thing is, it's not that the servers use a lot of CPU*, it's just that when they need it, they need it _NOW_, or else they miss their window and the framerate drops. The more things running per core, the higher the chance that something else will stop a server getting its slice when it needs it. *actually, they _DO_, but the point would stand even if they didn't This is why I find load average useful; it can point out overloading (if LA number of threads your server has) even when the CPU load isn't showing 100% Re: assigning servers to cores - this is going back about 3 years, but I noticed that gameservers liked to jump cores about every 30 seconds or so... but if I pinned them to a core, they'd lag for a split-second around every 30 seconds or so instead. No idea if that was the OS or the server, and we've not tested again since, but we've had little issue leaving them to roam free. -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux- boun...@list.valvesoftware.com] On Behalf Of Saint K. Sent: 25 July 2011 12:22 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 I could live with that, at least knowing a reason why my 3000,- euro hardware can only sustain 7-ish 24 slots TF2 servers. Saint K. From: hlds_linux-boun...@list.valvesoftware.com [hlds_linux- boun...@list.valvesoftware.com] On Behalf Of James Botting [bottswan...@googlemail.com] Sent: 25 July 2011 13:18 To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] cpu on i7 920 Everytime a new weapon goes 'pew pew' the laser destroys a section of your CPU. It's a new feature. On 25/07/2011 12:14, Andres Pozosjavato...@yahoo.es wrote: Its not a bug its a feature, jk. Orangebox take teh 100% cpu usage in a core with more than 25 slots, i tested it on many linux distros, many kernel configurations and many cpus. So welcome to the club. Hi, Thanks for the reply. The servers are build according to Tyans best practise, so everything is inserted in the correct slots. I've recently also updated the BIOS versions to be sure. One thing I notice, at the memory settings is a snooping option - If this is disabled, the overall load is slightly lower (as it is now). I'd generally wouldn't blame the hardware either, however, seeing I can't find anything software wise, it's the logical next thing to look at. Any more tips are welcome! Saint K. From: Jesse Molina [je...@opendreams.net] Sent: 25 July 2011 12:36 To: Half-Life dedicated Linux server mailing list Cc: Saint K. Subject: Re: [hlds_linux] cpu on i7 920 Looks fine, don't mess with it. generic-receive-offload would be good if you were doing 10G networking, but otherwise forget about it. Make sure that your RAM is in the right slots as recommended by Tyan. That can slow things down sometimes but I would not expect that to
Re: [hlds_linux] cpu on i7 920
I thought maybe I misunderstood or you mis-typed previously. You are saying that your server-side FPS is very unstable, below 100? I thought maybe you meant 66 packets-per-second/ticks/cmdrate/updaterate. FYI, I believe that the standard fps_max for tf2 is 300. My cruddy old AMD x2 4600+ holds steady with very little variance while loaded. There is something seriously wrong with your setup if that's true. I have no idea what it might be. Just for fun, apt-get install adjtimex and do adjtimex -p And maybe try running a few phoronics tests; sudo apt-cache show phoronix-test-suite install and do some memory and CPU tests. Compare with similar hardware to see what you are getting. As for setting process affinity, I doubt that there would be any benefit for an application like srcds. AMD processors for each core have their own cache, unlike Intel, so sometimes cache misses can hurt you for cache-intensive applications, but modern Linux schedulers take that into account and are pretty good about it (if I'm remembering right). There are also some cases where if you want maximum IO/network throughput (10G+ networking), it can be useful, but srcds isn't one of them. Per-CPU licensed apps (Oracle?) can also be a good reason to bind an app to a particular CPU. The issue with setting a process to a particular CPU affinity is that it does not provide exclusivity. Any other process will still run on that CPU too, potentially fighting for resources. Saint K. wrote: Hi, My concern is not really to have more servers on there (although it be nice if possible), but I'd like to get at least 66+fps stable per server per core, and having some load left to have replay etc enabled, as we had to kill that as well to get things running on the edge of normal. I've also tried assigning it per core, but never found clear bennifits to do so. The keeping one core free is just the thought process, leaves some room for other processes to peak (if required). Saint K. -- # Jesse Molina # Mail = je...@opendreams.net # Page = page-je...@opendreams.net # Cell = 1.602.323.7608 # Web = http://www.opendreams.net/jesse/ ___ 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 Servers are still crashing after July 22nd Update
actually after posting this , i went back to that server to play more. the Bison can be reflected. On Mon, Jul 25, 2011 at 10:51 AM, Ross Bemrose rbemr...@vgmusic.com wrote: This isn't server-related, but Cow Mangler 5000 can be reflected, Righteous Bison can't be reflected (and this is noted in the item description for it). On Mon, Jul 25, 2011 at 12:37 AM, clad iron cladi...@gmail.com wrote: I can vouch for the crashes also. (Windows and Linux) I was just playing on a server and it crashed. I think i may have caused it. Can anyone else try to repeat it? I was playing as pyro with the degreaser and a soldier was firing at me from across the map with The Righteous Bison. I attempted to reflect the shot back at him. None seemed to have reflected and i'm not to bad. He killed me and i started to spawn. just as i spawn the server crashed. Also i thought earlier i had reflected 1, but i'm unsure due to all the lazier glare in my screen. (those should be made narrower,and maybe brighten it some since it would be smaller in diameter. IMO..) On Sun, Jul 24, 2011 at 1:38 PM, Aaron DJ Zyrphon Thompson rmesc...@gmail.com wrote: I tried disabling mantreads and the new laser weapons but still getting a crash as of this morning. What are all the new weapon names like tf_mantreads that format. My saxton hale server is making sad faces. Sent from my MOTOBLUR™ smartphone on ATT -Original message- From: daniel jokiaho daniel.joki...@gmail.com To: Half-Life dedicated Linux server mailing list hlds_linux@list.valvesoftware.com Sent: Sun, Jul 24, 2011 17:18:35 GMT+00:00 Subject: Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update howto disable replays? And new weapons? On 24 Jul 2011 18:12, Andrew Armitage and...@thirdlife.org wrote: We have had replays disabled almost since they were introduced, as they seemed to cause crashes. Today we have also disabled the new weapons, and we've been crash free again since. According to one of our regular players: This server will ever be a Retro Server No Updates Thats pretty cooler because everybody is updating! And this server not! Thats what makes it unusual Hurrah for being unusual I guess. A On 24/07/2011 18:04, Ross Bemrose wrote: I disabled replays on all my TF2 servers yesterday afternoon, and they have yet to crash or freeze since. Therefore, I'm assuming it's a replay-related crash. That doesn't rule out the new weapons being the ultimate cause, though. On 7/23/2011 2:32 PM, Yuki wrote: A weird crash this time. Someone joined the server and saw a teleporter built by no one, upon going through it, there was a crash. Unsure whether the missing name was a client side issue, but the fact that the server managed to crash at the same time is odd. No memory corruption and similar error this time however. PreMinidumpCallback: updating dump comment Uploading dump (in-process) [proxy ''] /tmp/dumps/crash_20110723191817_1.dmp success = yes response: CrashID=bp-445d6055-e9e7-420a-93b8-688a92110723 On 23 July 2011 18:03, Aaron DJ Zyrphon Thompsonrmesc...@gmail.comwrote: The only server I have crashing is my VS Saxton Hale server. I'm thinking a fresh SM install will solve the problem. Sent from my MOTOBLUR™ smartphone on ATT -Original message- From: Michael Johansenmichs...@live.no To: hlds_linux@list.valvesoftware.com Sent: Sat, Jul 23, 2011 16:41:22 GMT+00:00 Subject: Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update Hm.. I haven't had a crash since the updates. Anyways, VALVE: Any progress on fixing the issue? Date: Sat, 23 Jul 2011 16:39:30 +0100 From: d...@dazzozo.com To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update I just crashed at the exact same time. Seeing as we're all using Pastebin: http://pastebin.com/wigab20i Are these definitely related to the new weapons or not? On 23 July 2011 16:37, Peter Reinholdpeter_va...@reinhold.dk wrote: On Sat, 23 Jul 2011 00:22:25 -0400, E3pO wrote: Servers are still crashing like crazy. Just got a lock-up crash. Output: http://pastebin.com/mzNG71Rm /Peter __**_ 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,
Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update
Should not be today an update ? 2011/7/25 clad iron cladi...@gmail.com actually after posting this , i went back to that server to play more. the Bison can be reflected. On Mon, Jul 25, 2011 at 10:51 AM, Ross Bemrose rbemr...@vgmusic.com wrote: This isn't server-related, but Cow Mangler 5000 can be reflected, Righteous Bison can't be reflected (and this is noted in the item description for it). On Mon, Jul 25, 2011 at 12:37 AM, clad iron cladi...@gmail.com wrote: I can vouch for the crashes also. (Windows and Linux) I was just playing on a server and it crashed. I think i may have caused it. Can anyone else try to repeat it? I was playing as pyro with the degreaser and a soldier was firing at me from across the map with The Righteous Bison. I attempted to reflect the shot back at him. None seemed to have reflected and i'm not to bad. He killed me and i started to spawn. just as i spawn the server crashed. Also i thought earlier i had reflected 1, but i'm unsure due to all the lazier glare in my screen. (those should be made narrower,and maybe brighten it some since it would be smaller in diameter. IMO..) On Sun, Jul 24, 2011 at 1:38 PM, Aaron DJ Zyrphon Thompson rmesc...@gmail.com wrote: I tried disabling mantreads and the new laser weapons but still getting a crash as of this morning. What are all the new weapon names like tf_mantreads that format. My saxton hale server is making sad faces. Sent from my MOTOBLUR™ smartphone on ATT -Original message- From: daniel jokiaho daniel.joki...@gmail.com To: Half-Life dedicated Linux server mailing list hlds_linux@list.valvesoftware.com Sent: Sun, Jul 24, 2011 17:18:35 GMT+00:00 Subject: Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update howto disable replays? And new weapons? On 24 Jul 2011 18:12, Andrew Armitage and...@thirdlife.org wrote: We have had replays disabled almost since they were introduced, as they seemed to cause crashes. Today we have also disabled the new weapons, and we've been crash free again since. According to one of our regular players: This server will ever be a Retro Server No Updates Thats pretty cooler because everybody is updating! And this server not! Thats what makes it unusual Hurrah for being unusual I guess. A On 24/07/2011 18:04, Ross Bemrose wrote: I disabled replays on all my TF2 servers yesterday afternoon, and they have yet to crash or freeze since. Therefore, I'm assuming it's a replay-related crash. That doesn't rule out the new weapons being the ultimate cause, though. On 7/23/2011 2:32 PM, Yuki wrote: A weird crash this time. Someone joined the server and saw a teleporter built by no one, upon going through it, there was a crash. Unsure whether the missing name was a client side issue, but the fact that the server managed to crash at the same time is odd. No memory corruption and similar error this time however. PreMinidumpCallback: updating dump comment Uploading dump (in-process) [proxy ''] /tmp/dumps/crash_20110723191817_1.dmp success = yes response: CrashID=bp-445d6055-e9e7-420a-93b8-688a92110723 On 23 July 2011 18:03, Aaron DJ Zyrphon Thompsonrmesc...@gmail.comwrote: The only server I have crashing is my VS Saxton Hale server. I'm thinking a fresh SM install will solve the problem. Sent from my MOTOBLUR™ smartphone on ATT -Original message- From: Michael Johansenmichs...@live.no To: hlds_linux@list.valvesoftware.com Sent: Sat, Jul 23, 2011 16:41:22 GMT+00:00 Subject: Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update Hm.. I haven't had a crash since the updates. Anyways, VALVE: Any progress on fixing the issue? Date: Sat, 23 Jul 2011 16:39:30 +0100 From: d...@dazzozo.com To: hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update I just crashed at the exact same time. Seeing as we're all using Pastebin: http://pastebin.com/wigab20i Are these definitely related to the new weapons or not? On 23 July 2011 16:37, Peter Reinholdpeter_va...@reinhold.dk wrote: On Sat, 23 Jul 2011 00:22:25 -0400, E3pO wrote: Servers are still crashing like crazy. Just got a lock-up crash. Output: http://pastebin.com/mzNG71Rm /Peter __**_ To unsubscribe, edit your list preferences, or view the list archives, please visit:
[hlds_linux] TF2 crashes
Hey guys, A status update on the crashes. I have identified what I think are 3 different problems. 1.) There's a bug in the replay system due to a flaw in libcurl using a signal to handle DNS timeout. You can avoid this bug by using IP addresses in your replay config, rather than DNS names. We will have a software workaround in the next update or so that essentially does this same thing automatically. 2.) There's a random memory scribble. It will manifest itself as double free or memory corruption crash, depending on your OS. Some have theorized than this is due to the Dr. G weapons. We cannot confirm this. 3.) There is a hang. From what information I have gathered, the last thing in the log is something along the lines of PreMinidumpCallback: updating dump comment. In other words, it is hanging while attempting to report the crash. This is particularly disastrous because it not only will it interfere with auto-restart scripts (unless you have some sort of watchdog), but it prevents the crash report from being generated and submitted, which of course would help us fix it. A random memory scribble can cause all sorts of behaviour, so it's possible that #2 is the real bug, and #3 just a side effect that sometimes attends the main bug. We have not been able to reproduce any of these issues internally, and we have had several playtests. (We, the actual developers, not a separate QA department and not a group of interns, playtest the game every day, on Windows and Linux servers.) However, our dedicated servers have experienced the hang. It has been very difficult to track down and fix these crashes because we seem to have several regressed all at once, and at least one of the problems is interfering with the normal reporting mechanism. If anyone is able to save a dump file (they usually go to /tmp/dumps), I would be great if you could post them in some webspace and post a URL where they may be downloaded. Or, if your console log shows that it was uploaded, please post the report ID. The output will look something like this: PreMinidumpCallback: updating dump comment Uploading dump (in-process) [proxy ''] /tmp/dumps/crash_20110723191817_1.dmp success = yes response: CrashID=bp-445d6055-e9e7-420a-93b8-688a92110723 Grabs of GDB stack traces, etc with raw addresses, are not totally useless, but they are definitely much less useful. Even with symbols, a stack trace does not have as much data as a dump has. So if we could get some actual dumps, that would be really great. These crashes continue to be our top priority. - Fletch ___ 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 crashes
Hi, Firstly, thanks for the update. 2.) There's a random memory scribble. It will manifest itself as double free or memory corruption crash, depending on your OS. Some have theorized than this is due to the Dr. G weapons. We cannot confirm this. Replays gave us trouble and so we disabled them after a day or so. We've had them turned off since. We had no crashes till the Dr G. weapons came out. Then we started to get the hangs. With the Dr. G weapons AND the replays turned off we've been running for over 24 hours without any issues at all. I know it's not MUCH evidence, and it's only one server, but I'd agree with that theory. A ___ 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 crashes
One of the hangs is caused by the bots. I think I've read before that it's caused by Engineer bots. Almost every time I enable bots on my server, it hangs and never restart. I have disabled them and don't have any issues now. 2011/7/25 Andrew Armitage and...@thirdlife.org Hi, Firstly, thanks for the update. 2.) There's a random memory scribble. It will manifest itself as double free or memory corruption crash, depending on your OS. Some have theorized than this is due to the Dr. G weapons. We cannot confirm this. Replays gave us trouble and so we disabled them after a day or so. We've had them turned off since. We had no crashes till the Dr G. weapons came out. Then we started to get the hangs. With the Dr. G weapons AND the replays turned off we've been running for over 24 hours without any issues at all. I know it's not MUCH evidence, and it's only one server, but I'd agree with that theory. A __**_ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/**mailman/listinfo/hlds_linuxhttp://list.valvesoftware.com/mailman/listinfo/hlds_linux -- Best regards, AnAkIn, - ESL EU TF2 Admin http://www.esl.eu/eu/tf2 ___ 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 crashes
Hi, I've got a dump for you: http://www.blackoutgaming.org/dumpsI'll upload more as the crashes go, i don't know if the one that's in there is because of the recent crashes however. From: fletch...@valvesoftware.com To: hlds_linux@list.valvesoftware.com; h...@list.valvesoftware.com Date: Mon, 25 Jul 2011 20:15:57 + Subject: [hlds_linux] TF2 crashes Hey guys, A status update on the crashes. I have identified what I think are 3 different problems. 1.) There's a bug in the replay system due to a flaw in libcurl using a signal to handle DNS timeout. You can avoid this bug by using IP addresses in your replay config, rather than DNS names. We will have a software workaround in the next update or so that essentially does this same thing automatically. 2.) There's a random memory scribble. It will manifest itself as double free or memory corruption crash, depending on your OS. Some have theorized than this is due to the Dr. G weapons. We cannot confirm this. 3.) There is a hang. From what information I have gathered, the last thing in the log is something along the lines of PreMinidumpCallback: updating dump comment. In other words, it is hanging while attempting to report the crash. This is particularly disastrous because it not only will it interfere with auto-restart scripts (unless you have some sort of watchdog), but it prevents the crash report from being generated and submitted, which of course would help us fix it. A random memory scribble can cause all sorts of behaviour, so it's possible that #2 is the real bug, and #3 just a side effect that sometimes attends the main bug. We have not been able to reproduce any of these issues internally, and we have had several playtests. (We, the actual developers, not a separate QA department and not a group of interns, playtest the game every day, on Windows and Linux servers.) However, our dedicated servers have experienced the hang. It has been very difficult to track down and fix these crashes because we seem to have several regressed all at once, and at least one of the problems is interfering with the normal reporting mechanism. If anyone is able to save a dump file (they usually go to /tmp/dumps), I would be great if you could post them in some webspace and post a URL where they may be downloaded. Or, if your console log shows that it was uploaded, please post the report ID. The output will look something like this: PreMinidumpCallback: updating dump comment Uploading dump (in-process) [proxy ''] /tmp/dumps/crash_20110723191817_1.dmp success = yes response: CrashID=bp-445d6055-e9e7-420a-93b8-688a92110723 Grabs of GDB stack traces, etc with raw addresses, are not totally useless, but they are definitely much less useful. Even with symbols, a stack trace does not have as much data as a dump has. So if we could get some actual dumps, that would be really great. These crashes continue to be our top priority. - Fletch ___ 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
[hlds_linux] Player counts, replay, and SourceTV
The last TF2 update should have fixed the last problems with the player count for replay and SourceTV. The player count, as shown on the server browser, will never include replay or SourceTV. As some have noted, the fact that replay and source TV are players is an implementation kludge, and this fact should not be visible outside of the server. Also, the maxplayers settings and visiblemaxplayers should not be incremented to have an extra slot for replay, they should only count regular players. We know that this is a change from previous behaviour, but it is how we want things to work going forward. In other words, you should use the same settings for the player counts, whether you have source TV and/or replay enabled. (Eventually you will be able to have the both at the same time.) For example, if you want to have a server with 24 human players, and one reserved secret slot for yourself, you will set maxplayers to 24 and visiblemaxplayers to 25. These values should apply whether replay is enabled or not. Your server will still increase the player count to make room for the proxies. We know the zombie player count problem still exists, but apparently it has decreased in frequency. We're still working on it. - Fletch ___ 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 crashes
http://www.x-cult.org/dumps.tar.gz Here is each dump in my /tmp/dumps folder starting from the 20th. I hope it helps. On 7/25/2011 4:15 PM, Fletcher Dunn wrote: Hey guys, A status update on the crashes. I have identified what I think are 3 different problems. 1.) There's a bug in the replay system due to a flaw in libcurl using a signal to handle DNS timeout. You can avoid this bug by using IP addresses in your replay config, rather than DNS names. We will have a software workaround in the next update or so that essentially does this same thing automatically. 2.) There's a random memory scribble. It will manifest itself as double free or memory corruption crash, depending on your OS. Some have theorized than this is due to the Dr. G weapons. We cannot confirm this. 3.) There is a hang. From what information I have gathered, the last thing in the log is something along the lines of PreMinidumpCallback: updating dump comment. In other words, it is hanging while attempting to report the crash. This is particularly disastrous because it not only will it interfere with auto-restart scripts (unless you have some sort of watchdog), but it prevents the crash report from being generated and submitted, which of course would help us fix it. A random memory scribble can cause all sorts of behaviour, so it's possible that #2 is the real bug, and #3 just a side effect that sometimes attends the main bug. We have not been able to reproduce any of these issues internally, and we have had several playtests. (We, the actual developers, not a separate QA department and not a group of interns, playtest the game every day, on Windows and Linux servers.) However, our dedicated servers have experienced the hang. It has been very difficult to track down and fix these crashes because we seem to have several regressed all at once, and at least one of the problems is interfering with the normal reporting mechanism. If anyone is able to save a dump file (they usually go to /tmp/dumps), I would be great if you could post them in some webspace and post a URL where they may be downloaded. Or, if your console log shows that it was uploaded, please post the report ID. The output will look something like this: PreMinidumpCallback: updating dump comment Uploading dump (in-process) [proxy ''] /tmp/dumps/crash_20110723191817_1.dmp success = yes response: CrashID=bp-445d6055-e9e7-420a-93b8-688a92110723 Grabs of GDB stack traces, etc with raw addresses, are not totally useless, but they are definitely much less useful. Even with symbols, a stack trace does not have as much data as a dump has. So if we could get some actual dumps, that would be really great. These crashes continue to be our top priority. - Fletch ___ 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
Re: [hlds_linux] TF2 Crashes
Just trying to be more helpful in gathering dump data for Valve. Does adding the -debug switch to the srcds_run command add any more useful information to the dump files generated? Or does it only create the not-as-useful debug log files. I want to try and get as much information out of my next crash. Thanks -Andrew On Mon, Jul 25, 2011 at 3:25 PM, hlds_linux-requ...@list.valvesoftware.com wrote: Send hlds_linux mailing list submissions to hlds_linux@list.valvesoftware.com 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 hlds_linux-requ...@list.valvesoftware.com You can reach the person managing the list at hlds_linux-ow...@list.valvesoftware.com When replying, please edit your Subject line so it is more specific than Re: Contents of hlds_linux digest... Today's Topics: 1. Re: TF2 Servers are still crashing after July 22nd Update (Bajdechi Nightbox Alexandru) 2. TF2 crashes (Fletcher Dunn) 3. Re: TF2 crashes (Andrew Armitage) 4. Re: TF2 crashes (AnAkIn .) 5. Re: TF2 crashes (Michael Johansen) -- Message: 1 Date: Mon, 25 Jul 2011 23:11:34 +0300 From: Bajdechi \Nightbox\ Alexandru alexandrualexa...@gmail.com To: Half-Life dedicated Linux server mailing list hlds_linux@list.valvesoftware.com Subject: Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update Message-ID: CAET_hr-HsDH6HSRF7Ba6-6pPJVAsyOx_OdTr1=1cs6ec_pk...@mail.gmail.com Content-Type: text/plain; charset=windows-1252 Should not be today an update ? 2011/7/25 clad iron cladi...@gmail.com actually after posting this , i went back to that server to play more. the Bison can be reflected. On Mon, Jul 25, 2011 at 10:51 AM, Ross Bemrose rbemr...@vgmusic.com wrote: This isn't server-related, but Cow Mangler 5000 can be reflected, Righteous Bison can't be reflected (and this is noted in the item description for it). On Mon, Jul 25, 2011 at 12:37 AM, clad iron cladi...@gmail.com wrote: I can vouch for the crashes also. (Windows and Linux) I was just playing on a server and it crashed. I think i may have caused it. Can anyone else try to repeat it? I was playing as pyro with the degreaser and a soldier was firing at me from across the map with The Righteous Bison. I attempted to reflect the shot back at him. None seemed to have reflected and i'm not to bad. He killed me and i started to spawn. just as i spawn the server crashed. Also i thought earlier i had reflected 1, but i'm unsure due to all the lazier glare in my screen. (those should be made narrower,and maybe brighten it some since it would be smaller in diameter. IMO..) On Sun, Jul 24, 2011 at 1:38 PM, Aaron DJ Zyrphon Thompson rmesc...@gmail.com wrote: I tried disabling mantreads and the new laser weapons but still getting a crash as of this morning. What are all the new weapon names like tf_mantreads that format. My saxton hale server is making sad faces. Sent from my MOTOBLUR? smartphone on ATT -Original message- From: daniel jokiaho daniel.joki...@gmail.com To: Half-Life dedicated Linux server mailing list hlds_linux@list.valvesoftware.com Sent: Sun, Jul 24, 2011 17:18:35 GMT+00:00 Subject: Re: [hlds_linux] TF2 Servers are still crashing after July 22nd Update howto disable replays? And new weapons? On 24 Jul 2011 18:12, Andrew Armitage and...@thirdlife.org wrote: We have had replays disabled almost since they were introduced, as they seemed to cause crashes. Today we have also disabled the new weapons, and we've been crash free again since. According to one of our regular players: This server will ever be a Retro Server No Updates Thats pretty cooler because everybody is updating! And this server not! Thats what makes it unusual Hurrah for being unusual I guess. A On 24/07/2011 18:04, Ross Bemrose wrote: I disabled replays on all my TF2 servers yesterday afternoon, and they have yet to crash or freeze since. Therefore, I'm assuming it's a replay-related crash. That doesn't rule out the new weapons being the ultimate cause, though. On 7/23/2011 2:32 PM, Yuki wrote: A weird crash this time. Someone joined the server and saw a teleporter built by no one, upon going through it, there was a crash. Unsure whether the missing name was a client side issue, but the fact that the server managed to crash at the same time is odd. No memory corruption and similar error this time however. PreMinidumpCallback: updating
Re: [hlds_linux] TF2 crashes
Hi, If anyone is able to save a dump file (they usually go to /tmp/dumps), I would be great if you could post them in some webspace and post a URL where they may be downloaded. Or, if your console log shows that it was uploaded, please post the report ID. The output will look something like this: http://new.knightssocialclub.org/dumps.tar.gz -rw--- 1 ksc ksc 242800 Jul 18 11:13 crash_20110718111306_1.dmp -rw--- 1 ksc ksc 247848 Jul 21 14:59 crash_20110721145926_1.dmp -rw--- 1 ksc ksc 272304 Jul 21 15:39 crash_20110721153920_1.dmp -rw--- 1 ksc ksc 254056 Jul 21 16:24 crash_20110721162453_1.dmp -rw--- 1 ksc ksc 248632 Jul 21 17:03 crash_20110721170314_1.dmp -rw--- 1 ksc ksc 272744 Jul 22 13:25 crash_20110722132543_1.dmp -rw--- 1 ksc ksc 215816 Jul 22 13:29 crash_20110722132927_1.dmp -rw--- 1 ksc ksc 264304 Jul 22 19:03 crash_20110722190345_1.dmp -rw--- 1 ksc ksc 140088 Jul 22 21:27 crash_20110722212723_1.dmp -rw--- 1 ksc ksc 231928 Jul 22 22:50 crash_2011075000_1.dmp -rw--- 1 ksc ksc 251384 Jul 23 15:24 crash_20110723152440_1.dmp -rw--- 1 ksc ksc 245896 Jul 23 17:20 crash_20110723172027_1.dmp -rw--- 1 ksc ksc 218704 Jul 23 17:24 crash_20110723172445_1.dmp -rw--- 1 ksc ksc 246304 Jul 23 19:01 crash_20110723190110_1.dmp -rw--- 1 ksc ksc 238760 Jul 23 21:09 crash_20110723210931_1.dmp A ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Player counts, replay, and SourceTV
Also, the maxplayers settings and visiblemaxplayers should not be incremented to have an extra slot for replay, they should only count regular players. We know that this is a change from previous behaviour, but it is how we want things to work going forward. Will this make having 33 slots servers impossible? (32 + 1 hidden, got by putting tv_enable 1; tv_enable 0 in autoexec.cfg) For example, if you want to have a server with 24 human players, and one reserved secret slot for yourself, you will set maxplayers to 24 and visiblemaxplayers to 25 Isn't it the other way round? maxplayers 25 sv_visiblemaxplayers 24 thanks ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Player counts, replay, and SourceTV
On Monday, 25 July 2011, Fletcher Dunn fletch...@valvesoftware.com wrote: As some have noted, the fact that replay and source TV are players is an implementation kludge, and this fact should not be visible outside of the server. NO SHIT. It would have been hundreds of times easier to just record network traffic in the same manner record does. Why a player slot has to be used as some kind of hacky way to grab network data is unbelievable. Who designed this system (I presume you), who the hell spent months trying to fix a player count bug (you again?), and why the hell are they still at Valve? -- Kind regards, *Saul Rennison* ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] [hlds_announce] Half-Life 1 engine beta update released
Hello Continue to test last beta build, just 5 minutes ago test port crashed, no crashdump or error string, 1 minute before crash hlds process begin to consume 100% of cpu and ping for all players raised to 160-200. Checking log, found several suspicious strings L 07/26/2011 - 00:05:12: World triggered Round_Start Assert( Assertion Failed: 0 == iRet ):/home/VALVE/alfred/valve/steam3_rel_client/src/common/tcpconnection.cpp:1820 tcpconnection.cpp (1820) : Assertion Failed: 0 == iRet L 07/26/2011 - 00:06:39: /m/27STEAM_0:1:34369754CT killed Px16STEAM_0:0:13865103TERRORIST with usp tcpconnection.cpp (1820) : Assertion Failed: 0 == iRet L 07/26/2011 - 00:10:49: zx48k19STEAM_0:1:32652372TERRORIST say_team 9 6 1st tcpconnection.cpp (1820) : Assertion Failed: 0 == iRet And on 00:11:50 server crashed -- С уважением, px mailto:p...@i.kiev.ua ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] [hlds_announce] Half-Life 1 engine beta update released
This assert is after a setsockopt() failed to turn off tcp_nodelay, but that won't be a hard failure in this case. It sounds like you reconnected to the Steam backend and that caused a downstream failure, I can check that out. - Alfred -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux- boun...@list.valvesoftware.com] On Behalf Of px Sent: Monday, July 25, 2011 2:21 PM To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] [hlds_announce] Half-Life 1 engine beta update released Hello Continue to test last beta build, just 5 minutes ago test port crashed, no crashdump or error string, 1 minute before crash hlds process begin to consume 100% of cpu and ping for all players raised to 160-200. Checking log, found several suspicious strings L 07/26/2011 - 00:05:12: World triggered Round_Start Assert( Assertion Failed: 0 == iRet ):/home/VALVE/alfred/valve/steam3_rel_client/src/common/tcpconnection.c pp:1820 tcpconnection.cpp (1820) : Assertion Failed: 0 == iRet L 07/26/2011 - 00:06:39: /m/27STEAM_0:1:34369754CT killed Px16STEAM_0:0:13865103TERRORIST with usp tcpconnection.cpp (1820) : Assertion Failed: 0 == iRet L 07/26/2011 - 00:10:49: zx48k19STEAM_0:1:32652372TERRORIST say_team 9 6 1st tcpconnection.cpp (1820) : Assertion Failed: 0 == iRet And on 00:11:50 server crashed -- С уважением, px mailto:p...@i.kiev.ua ___ 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
Re: [hlds_linux] Player counts, replay, and SourceTV
- Original Message - From: Saul Rennison saul.renni...@gmail.com On Monday, 25 July 2011, Fletcher Dunn fletch...@valvesoftware.com wrote: As some have noted, the fact that replay and source TV are players is an implementation kludge, and this fact should not be visible outside of the server. NO SHIT. It would have been hundreds of times easier to just record network traffic in the same manner record does. Why a player slot has to be used as some kind of hacky way to grab network data is unbelievable. Who designed this system (I presume you), who the hell spent months trying to fix a player count bug (you again?), and why the hell are they still at Valve? Point 1: Out of order! Point 2: If it where that simple don't you think that's what they would have done. Point 3: See point #1 Regards Steve 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 postmas...@multiplay.co.uk. ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Player counts, replay, and SourceTV
Saul is so mad. Why he so mad tho? On Mon, Jul 25, 2011 at 5:29 PM, Steven Hartland kill...@multiplay.co.uk wrote: - Original Message - From: Saul Rennison saul.renni...@gmail.com On Monday, 25 July 2011, Fletcher Dunn fletch...@valvesoftware.com wrote: As some have noted, the fact that replay and source TV are players is an implementation kludge, and this fact should not be visible outside of the server. NO SHIT. It would have been hundreds of times easier to just record network traffic in the same manner record does. Why a player slot has to be used as some kind of hacky way to grab network data is unbelievable. Who designed this system (I presume you), who the hell spent months trying to fix a player count bug (you again?), and why the hell are they still at Valve? Point 1: Out of order! Point 2: If it where that simple don't you think that's what they would have done. Point 3: See point #1 Regards Steve 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 postmas...@multiplay.co.uk. ___ 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
Re: [hlds_linux] Player counts, replay, and SourceTV
Not a single thing has changed in any update (Ghost Player wise). According to the legitimate list, I still have well over 14 ghost clients per server. Is this a new feature? Kyle. On Mon, Jul 25, 2011 at 1:26 PM, Fletcher Dunn fletch...@valvesoftware.com wrote: We know the zombie player count problem still exists, but apparently it has decreased in frequency. We're still working on it. - Fletch ___ 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
Re: [hlds_linux] TF2 crashes
PreMinidumpCallback: updating dump comment Uploading dump (in-process) [proxy ''] /tmp/dumps/crash_20110725222650_1.dmp success = yes response: CrashID=bp-d8b6d5c8-e1b4-4162-a5d8-47f652110725 On 25 July 2011 21:42, Andrew Armitage and...@thirdlife.org wrote: Hi, If anyone is able to save a dump file (they usually go to /tmp/dumps), I would be great if you could post them in some webspace and post a URL where they may be downloaded. Or, if your console log shows that it was uploaded, please post the report ID. The output will look something like this: http://new.knightssocialclub.**org/dumps.tar.gzhttp://new.knightssocialclub.org/dumps.tar.gz -rw--- 1 ksc ksc 242800 Jul 18 11:13 crash_20110718111306_1.dmp -rw--- 1 ksc ksc 247848 Jul 21 14:59 crash_20110721145926_1.dmp -rw--- 1 ksc ksc 272304 Jul 21 15:39 crash_20110721153920_1.dmp -rw--- 1 ksc ksc 254056 Jul 21 16:24 crash_20110721162453_1.dmp -rw--- 1 ksc ksc 248632 Jul 21 17:03 crash_20110721170314_1.dmp -rw--- 1 ksc ksc 272744 Jul 22 13:25 crash_20110722132543_1.dmp -rw--- 1 ksc ksc 215816 Jul 22 13:29 crash_20110722132927_1.dmp -rw--- 1 ksc ksc 264304 Jul 22 19:03 crash_20110722190345_1.dmp -rw--- 1 ksc ksc 140088 Jul 22 21:27 crash_20110722212723_1.dmp -rw--- 1 ksc ksc 231928 Jul 22 22:50 crash_2011075000_1.dmp -rw--- 1 ksc ksc 251384 Jul 23 15:24 crash_20110723152440_1.dmp -rw--- 1 ksc ksc 245896 Jul 23 17:20 crash_20110723172027_1.dmp -rw--- 1 ksc ksc 218704 Jul 23 17:24 crash_20110723172445_1.dmp -rw--- 1 ksc ksc 246304 Jul 23 19:01 crash_20110723190110_1.dmp -rw--- 1 ksc ksc 238760 Jul 23 21:09 crash_20110723210931_1.dmp A __**_ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/**mailman/listinfo/hlds_linuxhttp://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
Re: [hlds_linux] [hlds_announce] Half-Life 1 engine beta update released
Hello. It seems that in same time there was some problems with world internet connection at ISP, but ports with previous beta continue to working fine This assert is after a setsockopt() failed to turn off tcp_nodelay, but that won't be a hard failure in this case. It sounds like you reconnected to the Steam backend and that caused a downstream failure, I can check that out. - Alfred -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux- boun...@list.valvesoftware.com] On Behalf Of px Sent: Monday, July 25, 2011 2:21 PM To: Half-Life dedicated Linux server mailing list Subject: Re: [hlds_linux] [hlds_announce] Half-Life 1 engine beta update released Hello Continue to test last beta build, just 5 minutes ago test port crashed, no crashdump or error string, 1 minute before crash hlds process begin to consume 100% of cpu and ping for all players raised to 160-200. Checking log, found several suspicious strings L 07/26/2011 - 00:05:12: World triggered Round_Start Assert( Assertion Failed: 0 == iRet ):/home/VALVE/alfred/valve/steam3_rel_client/src/common/tcpconnection.c pp:1820 tcpconnection.cpp (1820) : Assertion Failed: 0 == iRet L 07/26/2011 - 00:06:39: /m/27STEAM_0:1:34369754CT killed Px16STEAM_0:0:13865103TERRORIST with usp tcpconnection.cpp (1820) : Assertion Failed: 0 == iRet L 07/26/2011 - 00:10:49: zx48k19STEAM_0:1:32652372TERRORIST say_team 9 6 1st tcpconnection.cpp (1820) : Assertion Failed: 0 == iRet And on 00:11:50 server crashed -- С уважением, px mailto:p...@i.kiev.ua ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux -- С уважением, px mailto:p...@i.kiev.ua ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Player counts, replay, and SourceTV
Will this make having 33 slots servers impossible? (32 + 1 hidden, got by putting tv_enable 1; tv_enable 0 in autoexec.cfg) I have no idea. :) I also cannot answer right now if it's possible to increase the maximum from 32 to 64 on TF or any other game. :( For example, if you want to have a server with 24 human players, and one reserved secret slot for yourself, you will set maxplayers to 24 and visiblemaxplayers to 25 Isn't it the other way round? maxplayers 25 sv_visiblemaxplayers 24 As Willy Wonka once said: Strike that. Reverse it. It would have been hundreds of times easier to just record network traffic in the same manner record does. Why a player slot has to be used as some kind of hacky way to grab network data is unbelievable. We will give this suggestion all the attention it deserves. Who designed this system (I presume you), who the hell spent months trying to fix a player count bug (you again?), and why the hell are they still at Valve? I believe this dates all the way back to the days of HL1...Quake...? In any case, no it wasn't me. If I locate the person responsible, I'll make sure and pass on your question. I fear that they will be quite devastated. But perhaps they will be able to explain why they weren't able to create the incredible amount of value for customers as they did, in a less kludgey way. - Fletch ___ 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 crashes
I've got enough dumps for now guys. Thanks. I'm hoping we can get this crash fixed soon. ___ 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 crashes
Hopefully today ? It's been already a weekend + some days since this 'bug'. 2011/7/26 Fletcher Dunn fletch...@valvesoftware.com I've got enough dumps for now guys. Thanks. I'm hoping we can get this crash fixed soon. ___ 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
Re: [hlds_linux] Player counts, replay, and SourceTV
On Tue, Jul 26, 2011 at 12:01 AM, Fletcher Dunn fletch...@valvesoftware.com wrote: I believe this dates all the way back to the days of HL1...Quake...? In any case, no it wasn't me. If I locate the person responsible, I'll make sure and pass on your question. I fear that they will be quite devastated. But perhaps they will be able to explain why they weren't able to create the incredible amount of value for customers as they did, in a less kludgey way. server admins aren't customers since they don't give you any money, but still are valuable stakeholders.. We are asking for more attention to us, and more quality in your releases as regards server performance and stability. It isn't acceptable we have to constantly babysit the servers (this happens only to TF2, and sometimes to CSS, among all the servers we host) and be almost sure that any new update will result in A LOT of troubles for the next few days, until valve releases a fix that often.is a dirty workaround that partially fix it. Please improve your release process ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
Re: [hlds_linux] Player counts, replay, and SourceTV
Are you _sure_ it's reversed? Maxplayers 24, visiblemaxplayers 25 (or not set) makes sense if the engine is still bumping the maxplayers by one if tv/replay is enabled like you had said it will. And since the in-game browser decrements one from maxplayers for each bot slot, it makes sense that it will display 24 players with visible max set to 25. I'm now confused at what the actual change is because it sounds like there isn't any since this is how it's worked for a while. -Original Message- From: hlds_linux-boun...@list.valvesoftware.com [mailto:hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Fletcher Dunn Sent: Monday, July 25, 2011 3:01 PM To: 'hlds_linux@list.valvesoftware.com' Subject: Re: [hlds_linux] Player counts, replay, and SourceTV For example, if you want to have a server with 24 human players, and one reserved secret slot for yourself, you will set maxplayers to 24 and visiblemaxplayers to 25 Isn't it the other way round? maxplayers 25 sv_visiblemaxplayers 24 As Willy Wonka once said: Strike that. Reverse it. - Fletch ___ 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
Re: [hlds_linux] TF2 crashes
Had one on round end, not sure if it's related to the others, so I'm still submitting it. response: CrashID=bp-c1f94f7e-da6c-457b-bab5-6e8bb2110725 On 25 July 2011 23:04, Bajdechi Nightbox Alexandru alexandrualexa...@gmail.com wrote: Hopefully today ? It's been already a weekend + some days since this 'bug'. 2011/7/26 Fletcher Dunn fletch...@valvesoftware.com I've got enough dumps for now guys. Thanks. I'm hoping we can get this crash fixed soon. ___ 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
Re: [hlds_linux] Player counts, replay, and SourceTV
For example, if you want to have a server with 24 human players, and one reserved secret slot for yourself, you will set maxplayers to 24 and visiblemaxplayers to 25 Isn't it the other way round? maxplayers 25 sv_visiblemaxplayers 24 As Willy Wonka once said: Strike that. Reverse it. And by that, I mean --- reverse what *I* said. What you said was right, and what I wrote in my first post was incorrect. Setting sv_visiblemaxplayers maxplayers I believe is illegal, as it is advertising to players that there are more slots available than there really are, which would cause them to join a server and then get rejected. ___ 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 crashes
I'd just like to say thank you for making such fun games! No one is perfect so I can't stay mad at you guys when stuff like this happens. No pressure, but fix it pronto! If my VS Saxton Hale Mode server crashes one more time I might go on a rampage lol. Sent from my MOTOBLUR™ smartphone on ATT -Original message- From: Yuki d...@dazzozo.com To: Half-Life dedicated Linux server mailing list hlds_linux@list.valvesoftware.com Sent: Mon, Jul 25, 2011 22:24:09 GMT+00:00 Subject: Re: [hlds_linux] TF2 crashes Had one on round end, not sure if it's related to the others, so I'm still submitting it. response: CrashID=bp-c1f94f7e-da6c-457b-bab5-6e8bb2110725 On 25 July 2011 23:04, Bajdechi Nightbox Alexandru alexandrualexa...@gmail.com wrote: Hopefully today ? It's been already a weekend + some days since this 'bug'. 2011/7/26 Fletcher Dunn fletch...@valvesoftware.com I've got enough dumps for now guys. Thanks. I'm hoping we can get this crash fixed soon. ___ 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 ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
