Send hlds mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://list.valvesoftware.com/mailman/listinfo/hlds
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of hlds digest..."
Today's Topics:
1. RE: AMX Mod Slot Reservation and Auto-Retry function in Steam (m0gely)
(David)
2. Re: Re: What does RCON STATS CPU Really mean? (Ian mu)
3. RE: server crashes w/ new update (PiTaGoRaS)
4. RE: server crashes w/ new update (Alfred Reynolds)
5. RE: hlds digest, Vol 1 #3673 - 15 msgs (David)
6. Re: Re: What does RCON STATS CPU Really mean? (Whisper)
--__--__--
Message: 1
From: "David" <[EMAIL PROTECTED]>
To: <[email protected]>
Date: Fri, 20 May 2005 09:07:16 +0100
Subject: [hlds] RE: AMX Mod Slot Reservation and Auto-Retry function in Steam
(m0gely)
Reply-To: [email protected]
It's what we do on our server Mogely and I have over 40 reserved slots in
issue (never more than 20 seem to be in use at a time). I quoted HLSW as
what you would use or console. However, ASE or any other 3rd party connect
app should be just as good. Only through STEAM would the join process show
the reduced number of slots and allow the auto-retry to work as designed.
DD
Date: Thu, 19 May 2005 08:14:54 -0700
From: m0gely <[EMAIL PROTECTED]>
To: [email protected]
Subject: Re: [hlds] AMX Mod Slot Reservation and Auto-Retry function in
Steam
Reply-To: [email protected]
Saint K. wrote:
On all our servers it seems to work perfectly.
As long as that cvar works then yeah, he should be able to do what he
wants. I just know when my servers got full, to the maxplayer value, I
saw 1 more slot show up on my query page at random doing refreshes. I
used pquery back then when I cared, now I use qstat. I will play with
this later today when my server fills up.
Don't 3rd party server apps like ASE cause the client to connect as if
you typed 'connect' in your console though?
--
- m0gely
http://quake2.telestream.com/
Q2 | Q3A | Counter-strike
--__--__--
Message: 2
Date: Fri, 20 May 2005 09:09:13 +0100
From: Ian mu <[EMAIL PROTECTED]>
To: [email protected]
Subject: Re: [hlds] Re: What does RCON STATS CPU Really mean?
Reply-To: [email protected]
Out of interest, how much cpu do others think a 40 slot game server
would take when fully loaded? Not sure if you said what spec the CPUs
are. I'd probably guess its about right (can't be "that" far off
whatever) and expect most current CPUs to hit 85% or so with that.
On 5/20/05, Whisper <[EMAIL PROTECTED]> wrote:
--
[ Picked text/plain from multipart/alternative ]
There does appear to be a correlation between the FPS and the CPU numbers
The 18 player server though seems to cope quite well with:
fps_max 600
sv_maxrate 2000
sv_maxupdaterate 120
tickrate 100
whilst maintaining >500 FPS
The 40 player server though (which I never expect to run constantly at >
500 fps) seems to cope quite well with:
fps_max 600
sv_maxrate 2000
sv_maxupdaterate 100
tickrate 66
The but the overall playing experience on the 40 Player server for people
with client computers that can keep up, results in a excellent end result
especially considering the numbers of players.
On 5/20/05, Alexander Kobbevik <[EMAIL PROTECTED]> wrote:
Look at the FPS though... it drops, right?
And maybe the stats command stress the CPU or HLDS? :-)
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Whisper
Sent: 20. mai 2005 06:05
To: [email protected]
Subject: Re: [hlds] Re: What does RCON STATS CPU Really mean?
--
[ Picked text/plain from multipart/alternative ]
Clayton the sampling might be correct, but how would that explain the
results I get when I spam "rcon stats" into console and receive numbers
that
are all within 10% of each other?
Here is exmple:
14:03:37 stats
14:03:37 CPU In Out Uptime Users FPS Players
86.53 73784.24 227882.64 177 6 56.87 39
14:03:38 stats
14:03:38 CPU In Out Uptime Users FPS Players
86.53 74690.58 228744.00 177 6 63.98 39
14:03:38 stats
14:03:38 CPU In Out Uptime Users FPS Players
86.77 75565.57 229665.05 177 6 35.32 39
14:03:38 stats
14:03:38 CPU In Out Uptime Users FPS Players
86.77 76380.45 231317.58 177 6 34.13 39
14:03:39 stats
14:03:39 CPU In Out Uptime Users FPS Players
86.77 77197.75 232984.47 177 6 34.13 39
14:03:39 stats
14:03:39 CPU In Out Uptime Users FPS Players
86.77 77256.87 234898.08 177 6 30.10 39
14:03:39 stats
14:03:39 CPU In Out Uptime Users FPS Players
95.31 77242.05 236992.31 177 6 26.96 39
14:03:39 stats
14:03:39 CPU In Out Uptime Users FPS Players
95.31 77264.55 238138.23 177 6 33.02 39
14:03:40 stats
14:03:40 CPU In Out Uptime Users FPS Players
95.31 77243.81 238387.27 177 6 33.04 39
14:03:40 stats
14:03:40 CPU In Out Uptime Users FPS Players
94.57 77214.17 238615.45 177 6 40.99 39
14:03:40 stats
14:03:40 CPU In Out Uptime Users FPS Players
94.57 77057.98 238889.06 177 6 34.12 39
14:03:40 stats
14:03:40 CPU In Out Uptime Users FPS Players
94.57 76746.83 239109.53 177 6 33.05 39
14:03:41 stats
14:03:41 CPU In Out Uptime Users FPS Players
94.57 76242.27 239287.92 177 6 57.57 39
14:03:41 stats
14:03:41 CPU In Out Uptime Users FPS Players
94.30 75778.00 238699.22 177 6 37.94 39
14:03:41 stats
14:03:41 CPU In Out Uptime Users FPS Players
94.30 75704.43 238780.63 177 6 60.21 39
14:03:41 stats
14:03:42 CPU In Out Uptime Users FPS Players
94.30 75405.64 238652.98 177 6 25.60 39
14:03:42 stats
14:03:42 CPU In Out Uptime Users FPS Players
93.41 75245.19 238275.91 177 6 28.43 39
14:03:42 stats
14:03:42 CPU In Out Uptime Users FPS Players
93.41 75358.87 238213.38 177 6 27.67 39
14:03:42 stats
14:03:42 CPU In Out Uptime Users FPS Players
93.41 75571.36 237885.63 177 6 28.46 39
14:03:43 stats
14:03:43 CPU In Out Uptime Users FPS Players
93.41 76112.34 237668.05 177 6 30.11 39
14:03:43 stats
14:03:43 CPU In Out Uptime Users FPS Players
89.06 76824.73 237348.69 177 6 60.34 39
14:03:43 stats
14:03:43 CPU In Out Uptime Users FPS Players
89.06 77527.95 237276.89 177 6 36.56 39
14:03:43 stats
14:03:44 CPU In Out Uptime Users FPS Players
89.06 77854.19 237533.16 177 6 46.56 39
14:03:44 stats
14:03:44 CPU In Out Uptime Users FPS Players
90.63 77517.18 238679.83 177 6 34.15 39
14:03:44 stats
14:03:44 CPU In Out Uptime Users FPS Players
90.63 77084.93 240084.63 177 6 36.57 39
14:03:44 stats
14:03:44 CPU In Out Uptime Users FPS Players
90.63 76791.86 241383.80 177 6 31.04 39
14:03:45 stats
14:03:45 CPU In Out Uptime Users FPS Players
90.63 76871.59 242368.47 177 6 22.76 39
14:03:45 stats
14:03:45 CPU In Out Uptime Users FPS Players
91.71 77053.85 242882.44 177 6 23.81 39
14:03:45 stats
14:03:45 CPU In Out Uptime Users FPS Players
91.71 77454.66 242307.06 177 6 32.04 39
14:03:45 stats
14:03:46 CPU In Out Uptime Users FPS Players
91.71 78062.38 240988.48 177 6 35.32 39
14:03:46 stats
14:03:46 CPU In Out Uptime Users FPS Players
91.71 78272.21 239666.45 177 6 32.02 39
14:03:46 stats
14:03:46 CPU In Out Uptime Users FPS Players
91.83 78384.60 238314.08 177 6 36.57 39
14:03:46 stats
14:03:46 CPU In Out Uptime Users FPS Players
91.83 78409.96 237305.31 177 6 33.04 39
Now you cannot tell me that this is not odd and that this is some sort of
time sampling mismatch
task manager ought to damn well show something that approximates what
SRCDS
is reporting back or vice versa, but it does not!
On 5/20/05, Clayton Macleod <[EMAIL PROTECTED]> wrote:
true, but you have to sample for a certain period of time to get a
percentage reading. Obviously I'm just guessing that the period that
the game's using is shorter than the period that task manager uses,
but it would seem to make sense considering the observations. Why
would that be so hard to accept? If you're only sampling usage for 0.1
seconds and you see a 99% value there's nothing wrong with that, even
if task manager only showed 10% usage at the same time, since task
manager samples for 1.0 seconds and it could have been idle for the
other 0.9 seconds, which would indeed mean 10% usage for task
manager's period.
On 5/19/05, Whisper <[EMAIL PROTECTED]> wrote:
--
[ Picked text/plain from multipart/alternative ]
Well it is not like anybody has stepped up and stated categorically
what
it
really means and is able to explain the discrepancies between the 2
that
a
critically thinking human being would accept.
--
Clayton Macleod
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--__--__--
Message: 3
From: PiTaGoRaS <[EMAIL PROTECTED]>
To: <[email protected]>
Date: Fri, 20 May 2005 10:09:56 +0200
Subject: RE: [hlds] server crashes w/ new update
Reply-To: [email protected]
I will never understand why Valve make this this kind of "fixes" that broke=
something else without any warning. Is it so dificult to contact with the =
Mani/AMX plugin devs, for example, some days before relase so they are able=
to update their code and everybody is happy?
... really tired of this.
Alfred Reynolds escribi=F3=A0(Fri, 20 May 2005 00:49:04 -0700):
=A0They are using an undocumented hack to display those menus, this
=A0update removes the hack and so they can no longer use it (because
=A0the last subsystem that was using it, radio menus, has finally been
=A0fixed to be client side). They have a plugin API to display
=A0messages to users and get feedback, they should use that.
=A0- Alfred
=A0----Original Message----
=A0From: [EMAIL PROTECTED]
=A0[mailto:[EMAIL PROTECTED] On Behalf Of K2 Sent:
=A0Friday, May 20, 2005 12:43 AM To: [email protected]
=A0Subject: RE: [hlds] server crashes w/ new update
=A0Thx Alfred for staying on top of this and offering a roll-back.
=A0Looking forward to the fix.
=A0Something else tho that I believe needs to be addressed. The Mani
=A0plugin as well as Beetles plugin no longer work as intended - the
=A0AMX-style menus no longer function. A quote from Beetle: 'valve
=A0stopped any commands from the menus being sent to the server... I
=A0have no idea of any way to do it now..'
=A0Was this intentional or part of the problem with the new binary?
=A0- K2
=A0-----Original Message-----
=A0From: [EMAIL PROTECTED]
=A0[mailto:[EMAIL PROTECTED] On Behalf Of Alfred
=A0Reynolds Sent: Thursday, May 19, 2005 7:35 PM To:
[EMAIL PROTECTED] Subject: RE: [hlds] server crashes w/
=A0new update
=A0I am going to do an update soon that will roll the binary back
=A0(but keep the new de_inferno, it had a couple valuable fixes perf
=A0wise). The de_inferno update made the whole update mandatory.
=A0- Alfred
=A0----Original Message----
=A0From: [EMAIL PROTECTED]
=A0[mailto:[EMAIL PROTECTED] On Behalf Of Simon
=A0Garner Sent: Thursday, May 19, 2005 10:26 PM To:
[EMAIL PROTECTED] Subject: Re: [hlds] server crashes w/
=A0new update
=A0On 20/05/2005 3:47 p.m., Alfred Reynolds wrote:
=A0I have had a couple reports of this happening on de_port.
=A0Does anyone get it on any other Valve maps? (not third party
=A0ones).
=A0- Alfred
=A0Seems to be happening on all maps.
=A0Save us Alfred, teh servers are dyiinng!
=A0On a related note, why was this a required update anyway? I
=A0wasn't even going to bother updating as I hadn't had any
=A0trouble with the two issues it was fixing, but unfortunately I
=A0was forced to. :(
=A0-Simon
=A0_______________________________________________
=A0To unsubscribe, edit your list preferences, or view the list
=A0archives, please visit:
=A0http://list.valvesoftware.com/mailman/listinfo/hlds
=A0_______________________________________________
=A0To unsubscribe, edit your list preferences, or view the list
=A0archives, please visit:
=A0http://list.valvesoftware.com/mailman/listinfo/hlds
=A0_______________________________________________
=A0To unsubscribe, edit your list preferences, or view the list
=A0archives, please visit:
=A0http://list.valvesoftware.com/mailman/listinfo/hlds
=A0_______________________________________________
=A0To unsubscribe, edit your list preferences, or view the list
=A0archives, please visit:
=A0http://list.valvesoftware.com/mailman/listinfo/hlds
--__--__--
Message: 4
Subject: RE: [hlds] server crashes w/ new update
Date: Fri, 20 May 2005 01:15:05 -0700
From: "Alfred Reynolds" <[EMAIL PROTECTED]>
To: <[email protected]>
Reply-To: [email protected]
They were warned multiple times to not use the hacks they were, so it is up=
on their own heads.
- Alfred
----Original Message----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of PiTaGoRaS Sent:
Friday, May 20, 2005 1:10 AM To: [email protected]
Subject: RE: [hlds] server crashes w/ new update
I will never understand why Valve make this this kind of "fixes" that
broke something else without any warning. Is it so dificult to
contact with the Mani/AMX plugin devs, for example, some days before
relase so they are able to update their code and everybody is happy?
... really tired of this.
Alfred Reynolds escribi=F3=A0(Fri, 20 May 2005 00:49:04 -0700):
=A0They are using an undocumented hack to display those menus, this
=A0update removes the hack and so they can no longer use it (because
=A0the last subsystem that was using it, radio menus, has finally been
=A0fixed to be client side). They have a plugin API to display
=A0messages to users and get feedback, they should use that.
=A0- Alfred
=A0----Original Message----
=A0From: [EMAIL PROTECTED]
=A0[mailto:[EMAIL PROTECTED] On Behalf Of K2 Sent:
=A0Friday, May 20, 2005 12:43 AM To: [email protected]
=A0Subject: RE: [hlds] server crashes w/ new update
=A0Thx Alfred for staying on top of this and offering a roll-back.
Looking forward to the fix.
=A0Something else tho that I believe needs to be addressed. The Mani
=A0plugin as well as Beetles plugin no longer work as intended - the
=A0AMX-style menus no longer function. A quote from Beetle: 'valve
=A0stopped any commands from the menus being sent to the server... I
=A0have no idea of any way to do it now..'
=A0Was this intentional or part of the problem with the new binary?
=A0- K2
=A0-----Original Message-----
=A0From: [EMAIL PROTECTED]
=A0[mailto:[EMAIL PROTECTED] On Behalf Of Alfred
=A0Reynolds Sent: Thursday, May 19, 2005 7:35 PM To:
[EMAIL PROTECTED] Subject: RE: [hlds] server crashes
w/ =A0new update
=A0I am going to do an update soon that will roll the binary back
=A0(but keep the new de_inferno, it had a couple valuable fixes perf
=A0wise). The de_inferno update made the whole update mandatory.
=A0- Alfred
=A0----Original Message----
=A0From: [EMAIL PROTECTED]
=A0[mailto:[EMAIL PROTECTED] On Behalf Of Simon
=A0Garner Sent: Thursday, May 19, 2005 10:26 PM To:
[EMAIL PROTECTED] Subject: Re: [hlds] server crashes
w/ =A0new update
=A0On 20/05/2005 3:47 p.m., Alfred Reynolds wrote:
=A0I have had a couple reports of this happening on de_port.
=A0Does anyone get it on any other Valve maps? (not third party
ones).
=A0- Alfred
=A0Seems to be happening on all maps.
=A0Save us Alfred, teh servers are dyiinng!
=A0On a related note, why was this a required update anyway? I
=A0wasn't even going to bother updating as I hadn't had any
=A0trouble with the two issues it was fixing, but unfortunately I
was forced to. :(
=A0-Simon
=A0_______________________________________________
=A0To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
=A0_______________________________________________
=A0To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
=A0_______________________________________________
=A0To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
=A0_______________________________________________
=A0To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list
archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--__--__--
Message: 5
From: "David" <[EMAIL PROTECTED]>
To: <[email protected]>
Date: Fri, 20 May 2005 09:32:08 +0100
Subject: [hlds] RE: hlds digest, Vol 1 #3673 - 15 msgs
Reply-To: [email protected]
If you don't kick a player, how to you propose to make a playing space for
the person joining?
The only way of not kicking a player is to not allow any regular players
into a reserved slot and have as many reserved slots as you need. I.e. start
the server with 32 slots and if you have 6 res slot holders, you set
sv_visiblemaxplayers 26 and put 6 reserved slots in the amx.cfg
DD
-- __--__--
ate: Thu, 19 May 2005 17:43:38 -0500
From: [EMAIL PROTECTED]
To: [email protected]
Subject: Re: [hlds] AMX Mod Slot Reservation and Auto-Retry function in
Steam
Reply-To: [email protected]
Saint K. wrote:
hello,
Look for the AMX reservation plugin wich allowes you to hide the
reservated
slot.
This way people can use auto retry, and admins etc can do a console
connect
(connect iphere).
This WILL allowe em to join when the server shows to be "full"
If u cant find the plugin let me know and ill find it for u after work
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, May 19, 2005 3:27 AM
Subject: [hlds] AMX Mod Slot Reservation and Auto-Retry function in Steam
Can this be made to work without kicking non-reserved slot players? I
use the method that doesn't kick players, as I never really liked the
option of kicking a person actively playing in the server.
--__--__--
Message: 6
Date: Fri, 20 May 2005 18:39:58 +1000
From: Whisper <[EMAIL PROTECTED]>
To: [email protected]
Subject: Re: [hlds] Re: What does RCON STATS CPU Really mean?
Reply-To: [email protected]
--
[ Picked text/plain from multipart/alternative ]
Ian thats my(our) problem
SRCDS stats shows numbers like 90%, ok fair enough when the round starts
and and there are 40 players on the server. The server still appears to run
fine from a players perspective, everything is as responsive as normal, or
better than normal because the server is actually under utilised atm.
BUT every Windows performance monitoring tool says neither physical CPU is
going past 50% and none of us can afford to sit there all day typing "rcon
stats" or just plain stats directly into the console just to keep an eye on
the CPU usage for SRCDS and trying to guage player experience.
The server is a Dual P4 3.6GHz Xeon with 4GB of RAM (I was mistaken I was
quoting 3GB before, but its actually 4GB)
It is very difficult to maximise the benefit of this sort of hardware if
you cannot get decent performace numbers. I think we have all seen SRCDS
crap out and players start warping all over the place, pings skyrocket or
pings are substantially higher than average, ie. you are getting 80ms
average pings when 40ms is the norm, no shot registration etc etc. All the
things CS players whine and bitch about and what all server adminsitrators
try to avoid if at all possible, if for no reason other than not having to
listen to bitching CS players! :)
That being said, its bloody well difficult to do the tweaking of you setups
if the in game player experience (good or bad) is not being matched by the
numbers Windows reports back to you, in terms of CPU usage (overall), CPU
usage (per CPU), and CPU usage (per process).
On 5/20/05, Ian mu <[EMAIL PROTECTED]> wrote:
Out of interest, how much cpu do others think a 40 slot game server
would take when fully loaded? Not sure if you said what spec the CPUs
are. I'd probably guess its about right (can't be "that" far off
whatever) and expect most current CPUs to hit 85% or so with that.
On 5/20/05, Whisper <[EMAIL PROTECTED]> wrote:
--
[ Picked text/plain from multipart/alternative ]
There does appear to be a correlation between the FPS and the CPU
numbers
The 18 player server though seems to cope quite well with:
fps_max 600
sv_maxrate 2000
sv_maxupdaterate 120
tickrate 100
whilst maintaining >500 FPS
The 40 player server though (which I never expect to run constantly at >
500 fps) seems to cope quite well with:
fps_max 600
sv_maxrate 2000
sv_maxupdaterate 100
tickrate 66
The but the overall playing experience on the 40 Player server for
people
with client computers that can keep up, results in a excellent end
result
especially considering the numbers of players.
On 5/20/05, Alexander Kobbevik <[EMAIL PROTECTED]> wrote:
Look at the FPS though... it drops, right?
And maybe the stats command stress the CPU or HLDS? :-)
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Whisper
Sent: 20. mai 2005 06:05
To: [email protected]
Subject: Re: [hlds] Re: What does RCON STATS CPU Really mean?
--
[ Picked text/plain from multipart/alternative ]
Clayton the sampling might be correct, but how would that explain the
results I get when I spam "rcon stats" into console and receive
numbers
that
are all within 10% of each other?
Here is exmple:
14:03:37 stats
14:03:37 CPU In Out Uptime Users FPS Players
86.53 73784.24 227882.64 177 6 56.87 39
14:03:38 stats
14:03:38 CPU In Out Uptime Users FPS Players
86.53 74690.58 228744.00 177 6 63.98 39
14:03:38 stats
14:03:38 CPU In Out Uptime Users FPS Players
86.77 75565.57 229665.05 177 6 35.32 39
14:03:38 stats
14:03:38 CPU In Out Uptime Users FPS Players
86.77 76380.45 231317.58 177 6 34.13 39
14:03:39 stats
14:03:39 CPU In Out Uptime Users FPS Players
86.77 77197.75 232984.47 177 6 34.13 39
14:03:39 stats
14:03:39 CPU In Out Uptime Users FPS Players
86.77 77256.87 234898.08 177 6 30.10 39
14:03:39 stats
14:03:39 CPU In Out Uptime Users FPS Players
95.31 77242.05 236992.31 177 6 26.96 39
14:03:39 stats
14:03:39 CPU In Out Uptime Users FPS Players
95.31 77264.55 238138.23 177 6 33.02 39
14:03:40 stats
14:03:40 CPU In Out Uptime Users FPS Players
95.31 77243.81 238387.27 177 6 33.04 39
14:03:40 stats
14:03:40 CPU In Out Uptime Users FPS Players
94.57 77214.17 238615.45 177 6 40.99 39
14:03:40 stats
14:03:40 CPU In Out Uptime Users FPS Players
94.57 77057.98 238889.06 177 6 34.12 39
14:03:40 stats
14:03:40 CPU In Out Uptime Users FPS Players
94.57 76746.83 239109.53 177 6 33.05 39
14:03:41 stats
14:03:41 CPU In Out Uptime Users FPS Players
94.57 76242.27 239287.92 177 6 57.57 39
14:03:41 stats
14:03:41 CPU In Out Uptime Users FPS Players
94.30 75778.00 238699.22 177 6 37.94 39
14:03:41 stats
14:03:41 CPU In Out Uptime Users FPS Players
94.30 75704.43 238780.63 177 6 60.21 39
14:03:41 stats
14:03:42 CPU In Out Uptime Users FPS Players
94.30 75405.64 238652.98 177 6 25.60 39
14:03:42 stats
14:03:42 CPU In Out Uptime Users FPS Players
93.41 75245.19 238275.91 177 6 28.43 39
14:03:42 stats
14:03:42 CPU In Out Uptime Users FPS Players
93.41 75358.87 238213.38 177 6 27.67 39
14:03:42 stats
14:03:42 CPU In Out Uptime Users FPS Players
93.41 75571.36 237885.63 177 6 28.46 39
14:03:43 stats
14:03:43 CPU In Out Uptime Users FPS Players
93.41 76112.34 237668.05 177 6 30.11 39
14:03:43 stats
14:03:43 CPU In Out Uptime Users FPS Players
89.06 76824.73 237348.69 177 6 60.34 39
14:03:43 stats
14:03:43 CPU In Out Uptime Users FPS Players
89.06 77527.95 237276.89 177 6 36.56 39
14:03:43 stats
14:03:44 CPU In Out Uptime Users FPS Players
89.06 77854.19 237533.16 177 6 46.56 39
14:03:44 stats
14:03:44 CPU In Out Uptime Users FPS Players
90.63 77517.18 238679.83 177 6 34.15 39
14:03:44 stats
14:03:44 CPU In Out Uptime Users FPS Players
90.63 77084.93 240084.63 177 6 36.57 39
14:03:44 stats
14:03:44 CPU In Out Uptime Users FPS Players
90.63 76791.86 241383.80 177 6 31.04 39
14:03:45 stats
14:03:45 CPU In Out Uptime Users FPS Players
90.63 76871.59 242368.47 177 6 22.76 39
14:03:45 stats
14:03:45 CPU In Out Uptime Users FPS Players
91.71 77053.85 242882.44 177 6 23.81 39
14:03:45 stats
14:03:45 CPU In Out Uptime Users FPS Players
91.71 77454.66 242307.06 177 6 32.04 39
14:03:45 stats
14:03:46 CPU In Out Uptime Users FPS Players
91.71 78062.38 240988.48 177 6 35.32 39
14:03:46 stats
14:03:46 CPU In Out Uptime Users FPS Players
91.71 78272.21 239666.45 177 6 32.02 39
14:03:46 stats
14:03:46 CPU In Out Uptime Users FPS Players
91.83 78384.60 238314.08 177 6 36.57 39
14:03:46 stats
14:03:46 CPU In Out Uptime Users FPS Players
91.83 78409.96 237305.31 177 6 33.04 39
Now you cannot tell me that this is not odd and that this is some sort
of
time sampling mismatch
task manager ought to damn well show something that approximates what
SRCDS
is reporting back or vice versa, but it does not!
On 5/20/05, Clayton Macleod <[EMAIL PROTECTED]> wrote:
true, but you have to sample for a certain period of time to get a
percentage reading. Obviously I'm just guessing that the period that
the game's using is shorter than the period that task manager uses,
but it would seem to make sense considering the observations. Why
would that be so hard to accept? If you're only sampling usage for
0.1
seconds and you see a 99% value there's nothing wrong with that,
even
if task manager only showed 10% usage at the same time, since task
manager samples for 1.0 seconds and it could have been idle for the
other 0.9 seconds, which would indeed mean 10% usage for task
manager's period.
On 5/19/05, Whisper <[EMAIL PROTECTED]> wrote:
--
[ Picked text/plain from multipart/alternative ]
Well it is not like anybody has stepped up and stated
categorically
what
it
really means and is able to explain the discrepancies between the
2
that
a
critically thinking human being would accept.
--
Clayton Macleod
_______________________________________________
To unsubscribe, edit your list preferences, or view the list
archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives,
please visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
--
--__--__--
_______________________________________________
To unsubscribe, edit your list preferences, or view the list archives, please
visit:
http://list.valvesoftware.com/mailman/listinfo/hlds
End of hlds Digest
