Hello,
I've been seeing major issues with FPS Instability when sourcetv is enabled.
Servers arnt overloaded, quite the opposite, when sourcetv is enabled
I'm seeing almost constant fps drops, when it's off the servers are
sitting at a nice 995fps.
I've found the orange box extremely sexy for
None of my forks had users on them. The master had notice that on map
change it would update. I figures since nobody was on the master would
shut down. Guess not. Had to quit manually which forced it to auto
update
Wish auto update would get fixed.
Sent from my iPhone
On Jan 24, 2009, at
Auto update doesn't work either here with forked servers. I had to shut down
the servers and start the script again, so it would update and then start
the forked servers.
2009/1/24 Steven J. Sumichrast packh...@gmail.com
None of my forks had users on them. The master had notice that on map
All I had to do was issue a quit command to the parent process through
telnet. Once I did that the forks shut down, which were already in
hibernate, and then the 10 second auto restart kicked in and caused
the auto update to happen.
I really need auto update to work. I'm the sole admin and
Hi,
there was a nice thread a week ago, Gary suggested turning acpi off may
stabilize fps.
Kveri
RTL-Servers wrote:
Hello,
I've been seeing major issues with FPS Instability when sourcetv is enabled.
Servers arnt overloaded, quite the opposite, when sourcetv is enabled
I'm seeing almost
I think almost everyone here uses newer processors, so everyone should
be interested :).
Why not to use all that power the x64 processors offer?
Kveri
Joseph Laws wrote:
Yes, I'm very interested in the status of the AMD64 binaries as well.
Gary Stanley wrote:
What ever happened to
I admit I haven't dug into the scripts to see what is actually being run,
but whenever I start my server (using Ubuntu x64), I see:
Auto detecting CPU
Using AMD-Opteron (64 bit) Optimised binary.
This sounds to me like there already is a 64-bit binary. Am I mistaken?
Walton
The detection part is detecting you should be served an amd-64 binary, but
as none are available you get the standard one.
I seem to recall that the compile process was changed so that a lot of stuff
that would previously require selection of different binaries now doesn't...
so you get an
It's not a 64bit binary, its optimized for 64bit Opterons.
Walton Hoops wrote:
I admit I haven't dug into the scripts to see what is actually being run,
but whenever I start my server (using Ubuntu x64), I see:
Auto detecting CPU
Using AMD-Opteron (64 bit) Optimised binary.
This sounds to
64bit binaries have been distributed since before VAC2. This means they
are still using the old protocol (47), and if any servers still happen
to use amd64 nobody will be able to connect to them.
Instead of actually building it for 64bit, their fix was to edit
hlds_run to use hlds_amd instead
Maybe 64bit binary was discontinued because it was harder to keep up
many branches of the engine. Srcds_i486 runs fine on most machines.
Thats the main purpose anyway, not best performance which some people
here seem to be looking for. Their agenda may be commercial or out of
interest but i
Those amd-optimized binaries weren't 64-bit binaries AFAIK (this is from before
I started working on the linux ds), but rather were just binaries produced with
gcc tuning settings set to favor the amd64 chips. With the orange box (and
subsequently with l4d), we changed a lot of our compiler
Has anyone been having problems starting a hlds_run without internet or with
-nomaster?
If I choose to use the nomaster value on the command line, the servers isnt
viewable from any server browser, hlds, qstat og steams server browser it
self
And if i start a hlds_run without the server has
At 03:32 PM 1/24/2009, Chris Green wrote:
Those amd-optimized binaries weren't 64-bit binaries AFAIK (this is
from before I started working on the linux ds), but rather were just
binaries produced with gcc tuning settings set to favor the amd64
chips. With the orange box (and subsequently with
At 03:32 PM 1/24/2009, Chris Green wrote:
Those amd-optimized binaries weren't 64-bit binaries AFAIK (this is
from before I started working on the linux ds), but rather were just
binaries produced with gcc tuning settings set to favor the amd64
chips. With the orange box (and subsequently with
The first thing I can think of that you could do is rewrite the time
function to cache time and only update it every so often.. I have a
proof of concept here. It reduces
syscall time by 40% for HZ=1000 for gettimeofday/clock_gettime.
The left4dead server replaces the gettimeofday calls with
Last I checked L4D binaries didn't work for CS 1.6, CZ, DOD, DOD:S, CS:S
or TF2...or maybe I'm out of the loop on something.
Chris Green wrote:
The first thing I can think of that you could do is rewrite the time
function to cache time and only update it every so often.. I have a
proof
Would be amazing to see these changes ported to Source/Orangebox engines :)
Chris Green escribió:
The first thing I can think of that you could do is rewrite the time
function to cache time and only update it every so often.. I have a
proof of concept here. It reduces
syscall time by
18 matches
Mail list logo
