2000fps #sourcekernel

[drazah]

I shall load the kernel and the patch and test it myself, i will remove all the bloat and repost it here.

[DiSTANT]

drazah Wrote:I shall load the kernel and the patch and test it myself, i will remove all the bloat and repost it here.

Let me know how it goes. Also, after talking with a few people, it also looks like achieving 2000fps is possible on Windows 2003 64 bit addition. I am going to be testing out a few different windows configurations to see what I can come up with.

[BehaartesEtwas]

I don't want to destroy any hopes for you. But AFAIK srcds waits 1ms after each frame. Your kernel can be as fast as it wants, you will not get above 1000 fps unless you convince srcds to wait shorter. Has anyone ever seen fps higher than 1000?

btw: if you want to have stable and high fps, try to make your timer subsystem independent from the kernel HZ, i.e. use hrtimers. it is possible to have constant 1000 fps with HZ=100 and dynamic ticks in your kernel config. this has the advantage of reducing your interrupt load.

[css]

Do you have any link or reference to the 1ms wait after each frame? Where did you come up with this?

On the Valve mailing list there was some experiments with modifying sleep() system call. Nephyrin managed to get around 30000 fps, but I remember he said the game was too fast after that.

Here's link to the thread: http://www.mail-archive.com/hlds_linux@list.valvesoftware.com/msg46646.html

Good post overall. Many users on this forum believe tickless and non-1000 Hz kernels are generally a disaster. It's good to see someone point out what the Hz really means for the system.

[BehaartesEtwas]

css Wrote:On the Valve mailing list there was some experiments with modifying sleep() system call. Nephyrin managed to get around 30000 fps, but I remember he said the game was too fast after that.

I did the same, and just let me print out the amount of time srcds sleeps ;-)

But I suppose there is no way getting higher fps than 1000 without tampering the system functions.

Btw: What do you hope to accomplish with this? Getting 1000 fps really stable is already difficult enough, and in my experience the instabilities have a much greater impact than the nominal fps vaule on the gameplay. I.e. it is better to have stable 500 fps than constantly jumping between 500 and 1000 fps...

[DiSTANT]

So after reading the last few replies, I have been doing a little bit of digging around. Props to Monk for giving me some ideas on his blog.

Quote:http://people.summit-servers.com/monk/

He found out that the engine makes tons of calls to the Linux System Call gettimeofday. Since this is a system call it has tons of overhead (system calls are coded for accuracy, not speed). In order to achieve higher then 1000fps, I think we are going to need to intercept (hijack) calls like this. I found an interesting forum doing something of this nature to lower CPU usage on Neverwinter Night game servers.

Quote:http://nwn.bioware.com/forums/viewtopic.html?topic=622605&forum=56

In any case, I am gonna get busy building my own version of gettimeofday and see if I can inject it into userland for a speed increase.

Cheers.

[css]

DiSTANT Wrote:So after reading the last few replies, I have been doing a little bit of digging around. Props to Monk for giving me some ideas on his blog.

Quote:http://people.summit-servers.com/monk/

He found out that the engine makes tons of calls to the Linux System Call gettimeofday. Since this is a system call it has tons of overhead (system calls are coded for accuracy, not speed). In order to achieve higher then
1000fps, I think we are going to need to intercept (hijack) calls like this.

In any case, I am gonna get busy building my own version of gettimeofday and see if I can inject it into userland for a speed increase.

I've seen posts about this too.

Then few months ago Nephyrin Zey told how it was in reality: http://www.mail-archive.com/hlds_linux@list.valvesoftware.com/msg47456.html

Nephyrin Zey Wrote:I believe, and I could be wrong, that all recent versions of glibc call gettimeofday as a virtual syscall, which means the context switching doesn't occur.

[DiSTANT]

css Wrote:

DiSTANT Wrote:So after reading the last few replies, I have been doing a little bit of digging around. Props to Monk for giving me some ideas on his blog.

Quote:http://people.summit-servers.com/monk/

He found out that the engine makes tons of calls to the Linux System Call gettimeofday. Since this is a system call it has tons of overhead (system calls are coded for accuracy, not speed). In order to achieve higher then
1000fps, I think we are going to need to intercept (hijack) calls like this.

In any case, I am gonna get busy building my own version of gettimeofday and see if I can inject it into userland for a speed increase.

I've seen posts about this too.

Then few months ago Nephyrin Zey told how it was in reality: http://www.mail-archive.com/hlds_linux@list.valvesoftware.com/msg47456.html

Nephyrin Zey Wrote:I believe, and I could be wrong, that all recent versions of glibc call gettimeofday as a virtual syscall, which means the context switching doesn't occur.

Now we're getting somewhere. Thank you for the reply css. I am going to use the ktrace method to see if I can find other issues. If anything, it would be nice just to get an ultra stable 1000fps. You guys should all join the channel.

Late

[BehaartesEtwas]

DiSTANT Wrote:If anything, it would be nice just to get an ultra stable 1000fps.

I already have ultra-stable 1000 fps:
http://fpsmeter.fragaholics.de/?load=srcds.193.192.59.90.27015.1228246037.session

:-)

[Krillin]

BehaartesEtwas Wrote:

DiSTANT Wrote:If anything, it would be nice just to get an ultra stable 1000fps.

I already have ultra-stable 1000 fps:
http://fpsmeter.fragaholics.de/?load=srcds.193.192.59.90.27015.1228246037.session

:-)

Don't stop there, do tell? Share your wisdom with us?

Krillin

[BehaartesEtwas]

Sorry I cant. At least not to the full extend (I have solt the technology exclusivly). For a medium solution (like http://fpsmeter.fragaholics.de/?load=srcds.82.98.78.236.1337.1227647238.session if you are running only one server per cpu-core) I will write a HOWTO very soon!

[DiSTANT]

BehaartesEtwas Wrote:Sorry I cant. At least not to the full extend (I have solt the technology exclusivly). For a medium solution (like http://fpsmeter.fragaholics.de/?load=srcds.82.98.78.236.1337.1227647238.session if you are running only one server per cpu-core) I will write a HOWTO very soon!

BehaartestEtwas... that is a nice solid 1000fps.

I'd be interested in the HOWTO. If you have a second, jump in the chan so we can chat.

Cheers

[BehaartesEtwas]

DiSTANT Wrote:I'd be interested in the HOWTO. If you have a second, jump in the chan so we can chat.

I am there, but in IRC I am called hrg...

[scriptfu]

Forgive me if I'm too offtopic, but what are the benefits of having a server run at such high FPS? I understand the tickrate and fps correlation, higher meaning better synchronizatoin of client/server communication, but isn't there a certain point where this no longer matters? I'm especially interested in any benchmarks that have been performed to either solidify or refute the necessity of these particular modifications.

Thanks!

[BehaartesEtwas]

I agree, higher fps than 1000 will probably not really make any difference. I even doubt that fps higher than 500 will make any difference, apart from psycological effects ;-) The stability is much more important. I would always prefer a server running at constantly 500 fps over one jumping between 500 and 1000 fps. According to valve the fps should only affect the ping (as long as it is higher than the tickrate), but I my experience other things (like the interpolation) depend on the server frames and are thus affected by instabilities...