I've updated the post containing the download with an xxl-sized red text to warn from downloading and using it.
I'm making good progress with v2 but will have to do a lot more blackbox-testing and benchmarking before I actually know the exact impact of different functions and values with different players, load and hardware.
Q: What would an omnipotent computer to?
A: Get rid of humanity!
(01-07-2010, 04:30 AM)f0y Wrote: and in source code I changed this line
Code:
//(hardcode fallback) FPS-value we are trying to reach
static int FPSS_WANTED = 512;
because i don't want 1000fps.
but i have 1000 fps...
something wrong?
First of all it is not recommended to use this lib at the moment. Back to your Problem. do not change the FPSS_WANTED = 512 part. leave it as it is and only change the FPS=500 Value setting the srcds value fps_max 0.
That way it worked fine for me setting fps to 500 using the stabalizer lib. Anyway the gameplay on servers with that lib felt not that good.
If you want to run the lib in a produktive enviroment let it be and wait till v2 is out.
The lib currently calculates the timing incorrectly and contains other bugs.
Please _do not_ use it until the release of V 2.0, it simply won't give the desired result!
Q: What would an omnipotent computer to?
A: Get rid of humanity!
Any news ? Is it ready ?
Version 1 gave me stable 995-1000 FPS but with horrible game-play and a lot of server crashes ( ./hlds_run line 321: 8174 Segmentation fault $HL_CMD ).
I suggest that the next version should concentrate more in game-accuracy and stable 1000 fps ! That's all that matters,no point in haveing 4-5-6000 fps )
accuracy can't be improved by fps.
Sluggish accuracy is mostly due to network latency, jitter and prediction errors resulting from those, not inaccuracte (in the range of nanoseconds!) sleeps and slower packet polling.
I have some issues in real-life I have to deal with, the lib comes second
Q: What would an omnipotent computer to?
A: Get rid of humanity!
01-22-2010, 09:03 PM (This post was last modified: 01-22-2010, 09:03 PM by d4f.)
From my experience fps drops from 1000 to 900 are not noticeable, since it's still over 9x faster than the max. client update rate and well below the network latency variation. However I agree, stable fps can easily be achieved without a lib, especially since the libs dont really change anything but simply use somewhat more precise equivalents of the commands.
v2 is following a completely other approach - it tries to reduce cpu usage and syscalls aswell as produce (mostly - not always) high-precision nanosleep, not correct timing issues from the past runs.
Q: What would an omnipotent computer to?
A: Get rid of humanity!
01-24-2010, 02:12 AM (This post was last modified: 01-24-2010, 02:14 AM by saintjimmygd.)
Well my FPS drops are between 1000 and 100 , so i have a huge problem.Tried vanilla & RT kernel on debian x64 but the results are the same...huge fps drops when server is full.Disabled cool & quiet cpu on my amd system,tried almost everything.The idlers don't have any effect,not even the resched.sh.My best result was when i tried distant's library on kernel-2.6.31.6-rt19.It made my fps stable between 950-1000,but huge CPU load and choppy game-play.I would be very pleased with drops down to 800 fps,but i don't know how.Tried everything in BehaartesEtwas's tutorials,different kernels,different distro's for almost one year.My system is:AMD AThlon x64 Dual core 2.3 Ghz,1 Gb RAM,10 Mbit upload speed.It's very very frustrating ..
Quote:From my experience fps drops from 1000 to 900 are not noticeable, since it's still over 9x faster than the max. client update rate and well below the network latency variation. However I agree, stable fps can easily be achieved without a lib, especially since the libs dont really change anything but simply use somewhat more precise equivalents of the commands.
true, drops to 900 fps are not noticeable. but not because it's still 9x bigger than 100, but because the time difference is very small. a server running with constant 100 fps would maintain all rates but would be noticeable worse than a 1000 fps server.
Quote:v2 is following a completely other approach - it tries to reduce cpu usage and syscalls aswell as produce (mostly - not always) high-precision nanosleep, not correct timing issues from the past runs.
I've done measurements that show that only ~0.1% of the frame calculations take longer than 1ms. It was on hlds during a 5on5 war, but I will repeat it on srcds some day. I guess it's not much different there. So I don't see much potential there. If the wake-up latency is minimal you get stable 1000 fps.
And btw: usleep calls nanosleep. So replacing usleep with nanosleep really doesn't change anything :-) Also replacing all those syscalls with something similar does not improve anything. In virtually all cases there is no way to reach the same functionality without a syscall. E.g. gettimeofday() is a direct syscall, but all other time measurement functions either call gettimeofday() or some other syscall which lead all to the same fundamental kernel function in the end.
That's what I meant with following the wrong approach...
You don't need to syscall for time. You can do rdtsc, read the DRAM refresh rate. All you need to gage time is 2 sources to interpolate from. Linux kernel does this for jiffies/ticks..
01-30-2010, 12:09 AM (This post was last modified: 01-30-2010, 12:10 AM by DiSTANT.)
(01-29-2010, 08:12 PM)Monk Wrote: You don't need to syscall for time. You can do rdtsc, read the DRAM refresh rate. All you need to gage time is 2 sources to interpolate from. Linux kernel does this for jiffies/ticks..
Monk is correct. You can keep time without making a syscall. From my testing it leads to slightly increased CPU, but is more precise than gtod.
)
