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
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 )
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
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
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
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
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
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
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
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
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
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:
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
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
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
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,
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
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
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,
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
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
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
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
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
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
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
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
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
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
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+
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
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
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.
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
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
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:
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
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
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
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
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
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
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 -
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:
- 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
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
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
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
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
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
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
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
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
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
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
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
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
57 matches
Mail list logo
