08-13-2009, 06:12 PM
please be a little more careful with your choice of words. I definitively know what I am talking about, I am developing software for the better part of my life now (sometimes very close to hardware), and I have some years experience with optimizing game servers.
you are right, srcds and hlds are 32 bit software. but they don't run in some emulated environment. they run in native 32 bit mode. x86_64 cpus can execute both 64 and 32 bit code, so there is no need for any emulation. Linux has both 32 and 64 bit libraries, and the kernel has a specific support to load 32 bit binaries (it has to switch the cpu to 32 bit mode for that process of course). still so far one could believe that there is no difference between 32 and 64 bit for the gameserver.
but: the kernel runs in 64 bit mode (on a 64 bit system), and so does every single system call from a certain point on (all drivers are 64 bit, so if you run e.g. some IO syscall you will end up in 64 bit sooner or later). Also, most important, the whole linux timer and scheduling system is 64 bit. this is the most important part for game servers, as they completely depend on them.
The problems you describe in the last part of your post are the reasons why I recommend using the RT paches. Hardware interrupts fire very precisely (this is "simple" electronics, a precision of a single usec is not a problem -> that's only MHz regime, even 10 nanosecs are not really difficult to reach), the only problem is the software that doesn't recognize them. Mainly this is because the CPU is busy with something else. Linux will handle the hardware ISR always at once (it has no other choice, the CPU runs the ISR when it receives the interrupt), but hardware ISRs need to be kept short so it will only set some flag somewhere in the kernel to be handled later. Then the linux scheduler will run the "real" software ISR when there is time. The RT paches will dramatically reduce the latency between the hardware interrupt and the recognition by the software. If you have a look at the debug facilities of the RT paches, you can see that "maximum" latencies of very few usecs are possible. Of course if heavy disk-IO is going on you will occasionally see higher latencies, that's why I wrote "maximum", and that's why the RT people are speaking of soft realtime.
And oh yes, I am pretty sure that a precision of some usecs of the clocks is possible, just have a look at ntp and what precision can be reached there (keep in mind that this is *absolute* precision which is much harder to reach then the relative precision we are talking about)!
I am sorry if I missed some of your points as some parts of your post are a little incomplete... (what do you mean by "make it return 999/1000/10000/1000000"??)
PS: Don't teach me about error estimation, I am a physicist
you are right, srcds and hlds are 32 bit software. but they don't run in some emulated environment. they run in native 32 bit mode. x86_64 cpus can execute both 64 and 32 bit code, so there is no need for any emulation. Linux has both 32 and 64 bit libraries, and the kernel has a specific support to load 32 bit binaries (it has to switch the cpu to 32 bit mode for that process of course). still so far one could believe that there is no difference between 32 and 64 bit for the gameserver.
but: the kernel runs in 64 bit mode (on a 64 bit system), and so does every single system call from a certain point on (all drivers are 64 bit, so if you run e.g. some IO syscall you will end up in 64 bit sooner or later). Also, most important, the whole linux timer and scheduling system is 64 bit. this is the most important part for game servers, as they completely depend on them.
The problems you describe in the last part of your post are the reasons why I recommend using the RT paches. Hardware interrupts fire very precisely (this is "simple" electronics, a precision of a single usec is not a problem -> that's only MHz regime, even 10 nanosecs are not really difficult to reach), the only problem is the software that doesn't recognize them. Mainly this is because the CPU is busy with something else. Linux will handle the hardware ISR always at once (it has no other choice, the CPU runs the ISR when it receives the interrupt), but hardware ISRs need to be kept short so it will only set some flag somewhere in the kernel to be handled later. Then the linux scheduler will run the "real" software ISR when there is time. The RT paches will dramatically reduce the latency between the hardware interrupt and the recognition by the software. If you have a look at the debug facilities of the RT paches, you can see that "maximum" latencies of very few usecs are possible. Of course if heavy disk-IO is going on you will occasionally see higher latencies, that's why I wrote "maximum", and that's why the RT people are speaking of soft realtime.
And oh yes, I am pretty sure that a precision of some usecs of the clocks is possible, just have a look at ntp and what precision can be reached there (keep in mind that this is *absolute* precision which is much harder to reach then the relative precision we are talking about)!
I am sorry if I missed some of your points as some parts of your post are a little incomplete... (what do you mean by "make it return 999/1000/10000/1000000"??)
PS: Don't teach me about error estimation, I am a physicist
http://www.fpsmeter.org
http://wiki.fragaholics.de/index.php/EN:Linux_Optimization_Guide (Linux Kernel HOWTO!)
Do not ask technical questions via PM!
http://wiki.fragaholics.de/index.php/EN:Linux_Optimization_Guide (Linux Kernel HOWTO!)
Do not ask technical questions via PM!