On Sat, 2006-06-03 at 22:23 -0300, Marcelo Bezerra wrote:
And then you would have to ask users to download and install that codec...
Not very usefull at all.
I suspect that that is the heart of the problem. If you want to have a
new codec DLL, you've also got to make sure that every one of
Are the daemons time-sensitive with regard to the system time? The
reason is, we had a few servers that were out of sync, and I resynced
them manually, then the inevitable flood of support requests came in.
I guess my second question could be: is there a reason this
limitation exists?
--
Erik
Erik Hollensbe wrote:
Are the daemons time-sensitive with regard to the system time? The
reason is, we had a few servers that were out of sync, and I resynced
them manually, then the inevitable flood of support requests came in.
I guess my second question could be: is there a reason this
On Jun 4, 2006, at 9:42 AM, m0gely wrote:
Erik Hollensbe wrote:
Are the daemons time-sensitive with regard to the system time? The
reason is, we had a few servers that were out of sync, and I resynced
them manually, then the inevitable flood of support requests came in.
I guess my second
If you are talking about cumulative clock drifting, yes. As far as
it's interaction to hlds etc, I don't know :)
I know the quartz is sensitive to temperatures and if it gets too
warm/BIOS issue, it will drift more.
At 03:02 AM 6/4/2006, Erik Hollensbe wrote:
Are the daemons time-sensitive with
On Jun 4, 2006, at 11:37 AM, Gary wrote:
If you are talking about cumulative clock drifting, yes. As far as
it's interaction to hlds etc, I don't know :)
I know the quartz is sensitive to temperatures and if it gets too
warm/BIOS issue, it will drift more.
Sorry, I meant the daemons. The
Could this cause choke if the gettimeofday() is really choppy and time
consuming?
/Bjorn
On Sun, 4 Jun 2006, Alfred Reynolds wrote:
Both server engines use the gettimeofday() call to work out elpased
time. If that time moves significantly during a frame then the next
frame will not run
I don't see how it could cause a crash, but with the complexity of the
simulation engine in Source I guess this is possible. Get a better clock in
your server.
- Alfred
Ondrej Hošek wrote:
So much for Monday... ;)
How can a server actually crash when the time is reset? Is there any
part of
In theory as the network system uses the gettimeofday() value to work
out network usage, but you would need a really really bad clock.
- Alfred
kama wrote:
Could this cause choke if the gettimeofday() is really choppy and time
consuming?
/Bjorn
On Sun, 4 Jun 2006, Alfred Reynolds wrote:
On Jun 4, 2006, at 2:27 PM, Alfred Reynolds wrote:
I don't see how it could cause a crash, but with the complexity of
the simulation engine in Source I guess this is possible. Get a
better clock in your server.
Yeah, these machines had been long-neglected and I was doing a time
sync on them,
Some OS's have very expensive gettimeofday calls..
At 04:04 PM 6/4/2006, kama wrote:
Could this cause choke if the gettimeofday() is really choppy and time
consuming?
/Bjorn
On Sun, 4 Jun 2006, Alfred Reynolds wrote:
Both server engines use the gettimeofday() call to work out elpased
I tried using these commands (sv_minrate, sv_maxrate, sv_minupdaterate,
sv_maxupdaterate) in my server, but they don't seem to enforce the
players rates, any ideas maybe why? or I need to configure something else?
Infact in my server sv_minrate is set to 15000, but still I tried settig
my rate
On Mon, 2006-06-05 at 01:58 +0200, SeNtiX wrote:
I tried using these commands (sv_minrate, sv_maxrate, sv_minupdaterate,
sv_maxupdaterate) in my server, but they don't seem to enforce the
players rates, any ideas maybe why? or I need to configure something else?
Infact in my server sv_minrate
13 matches
Mail list logo
