Best kernel?

[Peter_Pan123]

Monk: did you recommend rt patches? Do you recommend the idler? does the idler makes problems in the system when iam running 1-3 GS each CPU? i am a little bit scared when i spectate the "top" and can see some processes with 100% (hopefully the system dont crash)

[Terrorkarotte]

The load doesnt matter when you run these idlers. Doing it for a year now the load was always ~8 and no trouble so far.

[Peter_Pan123]

how many gs? fps?

[Terrorkarotte]

I run both tick 66 and tick 100 at fps_max 0. They reach the ~990 stabel with peaks and drops of 2fps.
I use a core i7 920. With the idlers on I run per core maximal 2 12slots tick 100 or 2 24 slots tick 66. On two cores there is only one gs with tick 66 but 32 slots. Even when all gs are full I had no problems so far. I dont need more at the time so I have not tried out what the maximum of the hardware is. Based on the fact, that the most time not all servers are full, there would be no problem to run more than this on the machine. I haave had no need to so far. So I did not try it out yet.

[BehaartesEtwas]

(11-13-2009, 08:03 AM)Monk Wrote:  The problem you don't seem to understand is that no matter how low of latency to push to userland applications that run in ring3, the game server binaries are broken.

I am sorry, Monk, you should not conclude from yourself to others I understand this perfectly well, that's why I change more than only the kernel.

Quote:In order to have high, stable FPS the following needs to happen:
- Coarse gettimeofday()

completely wrong. imagine you want to make a car running faster. would you start changing the tachometer? if you make gettimeofday more coarse in the right way (which can be done btw. easily) you will fake stable fps. but the fps will remain unchanged.

Quote:- Minimal jitter from nanosleep/tsleep/usleep() (the last calls the first)

usleep is the function used for waiting after each frame. the jitter of this function already is very small if you use RT paches and SCHED_RR or SCHED_FIFO. it is simply the wrong function used by valve. nanosleep & friends are not better, it's the logic that is wrong. the server always waits 1ms after each frame, regardless how long the frame took. that means fps are dropping if the server is doing actual calculations.

Quote:- Minimal scheduler latency (SCHED_RR or SCHED_FIFO)

the first right statement in your post

Quote:The first one is not really hard to implement, the 2nd one depends on the hardware, what scheduler youre running (CFS or the default, or even the staircase scheduler)

bullshit, see above.

Quote:Youre 'idler' program makes the FPS stay stable because of preemption latency. When a CPU is idle, there's wakeup latency, but if you peg 99% at lower priority (SCHED_OTHER) than (SCHED_RR/FIFO) there will be hardly none at all. When a CPU is idle, a HLT is issued and it waits for the next interrupt to wake up to see if there's work to do, but if it's not idle that's one more step it doesn't have to do.

I don't know how the idler works. But at least one piece of your explanation is incorrect: the term "wakeup latency" refers to the latency it takes to wake a specific process. that latency gets larger if the cpu is busy, simply because if it's idle it can start running the process right away (but it has to wait e.g. while certain phases of disk IO). if you put the cpu to sleep using HLT or some infinite loop doesn't matter.

Quote:You cannot have stable FPS on idle machines with low load due to the aforementioned issues,

yes you can. I don't use the idler on my system anymore.

Quote:plus you cannot have nanosecond nanosleep latency.

you don't need to. microseconds are good enough by far. the PC clock doesn't have a better resolution in any case.

Quote:I did not recommend to anyone to use older kernels, I was stating the best one for Linux is 2.4 (just before they removed the busywait stuff)

sounds alike for me :-)


sorry for being so direct. I don't want to be rude. But I am dealing with realtime applications for several years now, and not only as a user... So you should probably be a little more careful if you say I wouldn't have understood certain things.

[Monk]

(11-14-2009, 10:27 PM)BehaartesEtwas Wrote:  

(11-13-2009, 08:03 AM)Monk Wrote:  The problem you don't seem to understand is that no matter how low of latency to push to userland applications that run in ring3, the game server binaries are broken.

I am sorry, Monk, you should not conclude from yourself to others I understand this perfectly well, that's why I change more than only the kernel.

Quote:In order to have high, stable FPS the following needs to happen:
- Coarse gettimeofday()

completely wrong. imagine you want to make a car running faster. would you start changing the tachometer? if you make gettimeofday more coarse in the right way (which can be done btw. easily) you will fake stable fps. but the fps will remain unchanged.

Quote:- Minimal jitter from nanosleep/tsleep/usleep() (the last calls the first)

usleep is the function used for waiting after each frame. the jitter of this function already is very small if you use RT paches and SCHED_RR or SCHED_FIFO. it is simply the wrong function used by valve. nanosleep & friends are not better, it's the logic that is wrong. the server always waits 1ms after each frame, regardless how long the frame took. that means fps are dropping if the server is doing actual calculations.

Quote:- Minimal scheduler latency (SCHED_RR or SCHED_FIFO)

the first right statement in your post

Quote:The first one is not really hard to implement, the 2nd one depends on the hardware, what scheduler youre running (CFS or the default, or even the staircase scheduler)

bullshit, see above.

Quote:Youre 'idler' program makes the FPS stay stable because of preemption latency. When a CPU is idle, there's wakeup latency, but if you peg 99% at lower priority (SCHED_OTHER) than (SCHED_RR/FIFO) there will be hardly none at all. When a CPU is idle, a HLT is issued and it waits for the next interrupt to wake up to see if there's work to do, but if it's not idle that's one more step it doesn't have to do.

I don't know how the idler works. But at least one piece of your explanation is incorrect: the term "wakeup latency" refers to the latency it takes to wake a specific process. that latency gets larger if the cpu is busy, simply because if it's idle it can start running the process right away (but it has to wait e.g. while certain phases of disk IO). if you put the cpu to sleep using HLT or some infinite loop doesn't matter.

Quote:You cannot have stable FPS on idle machines with low load due to the aforementioned issues,

yes you can. I don't use the idler on my system anymore.

Quote:plus you cannot have nanosecond nanosleep latency.

you don't need to. microseconds are good enough by far. the PC clock doesn't have a better resolution in any case.

Quote:I did not recommend to anyone to use older kernels, I was stating the best one for Linux is 2.4 (just before they removed the busywait stuff)

sounds alike for me :-)


sorry for being so direct. I don't want to be rude. But I am dealing with realtime applications for several years now, and not only as a user... So you should probably be a little more careful if you say I wouldn't have understood certain things.

I am not incorrect about the idler program. Go read the kernel code, specifically sched.c around like 1220 (IIRC). I am not incorrect about the gettimeofday either. You don't need nanosecond accuracy on time when the game expects at the most, microsecond. Time cannot be fast and lose, it has to be slow and accurate. Running it with a corase gettimeofday saves overhead when doing clock lookups (in my benchmarks, 330uS for accurate vs 145uS for fast and loose). The 'bullshit' comment about what I stated that needs for stable FPS is far from bullshit. High precision sleep timers depend on the hardware. If you do not have HPET, what's next in line.. the PIT/8254? PMtimer?

From the kernel code (READ IT)

CONFIG_HIGH_RES_TIMERS
"This option enables high resolution timer support. If your hardware is not capable then this option only increases the size of the kernel image."

Also, SCHED_RR and SCHED_FIFO give the same latency on sleeping, I do not suggest you tell people to run their applications as the same scheduler as say, the network scheduler:

Code:

[root@sched_other ~]# chrt -f 50 ./wakeup_latency
0.000008
0.000009
0.000007
0.000009
0.000007
0.000008
0.000009
0.000007
0.000010
0.000010
0.000010
^C
[root@swamp ~]# chrt -r 50 ./wakeup_latency
0.000008
0.000008
0.000006
0.000004
0.000008
0.000008
0.000005
0.000005
0.000006
0.000007
0.000008

Verses SCHED_OTHER:

Code:

[root@swamp ~]# ./wakeup_latency
0.000057
0.000059
0.000057
0.000056
0.000056
0.000057
0.000058
^C

All in all, I believe doing all this crazy bullshit to the kernel to get stable FPS is backwards when you should just fix the engine yourself, with reverse engineering.

I will no longer respond to replies after this.

-M

[Terrorkarotte]

(11-14-2009, 10:27 PM)BehaartesEtwas Wrote:  yes you can. I don't use the idler on my system anymore.

How do you managed this? Did you modify the kernel or are you using libarys?

[Peter_Pan123]

yes he does, if you are interested he sells it ^^

[BehaartesEtwas]

no I am not selling anything anymore. I sold a library a year ago exclusively unfortunately to one provider, so I cannot provide you with it. sorry.

but nevertheless, I have also seen servers without the idler but in all other parts 100% after my howto running perfectly smooth. the idler helps in some cases but not in every. I really don't know when and how it helps, I don't see any pattern in this...

commenting on monks statements:

first one should not mix up kernel code with the help in the kernel config. kernel code is in C not in English high res timers are supported since ages by any PC (HPET, ACPI timer, TSC are 3 implementations of this). also, he misses one important point: gettimeofday has "only" microseconds resolution, not nanoseconds. but you don't need to look into kernel source for this, just read the man page of gettimeofday ;-) well ok, inside the kernel gettimeofday calls getnstimeofday and divides the nanosecods by 1000. but one should not mix up resolution with the number of digits. HPET usually has a resolution of 0.1 microseconds. basically the kernel uses one clock source only in any case, so it's only a question where the numbers are being divided to the required "resolution". even time() with its one second resolution calls gettimeofday...

second, about his example with the wakeup_latency: this looks fine with ~10 numbers. if one does this 1000 times per second under load, one will see that RT patches help a lot. it's the maximum latency that creates lags even if those happen only 1% of the time...

I know he won't answer, but maybe this helps everyone else to understand...

[loopyman]

Why wont this topic die -_-

[BehaartesEtwas]

maybe someone should close it :-D

[Peter_Pan123]

but who ?

[loopyman]

Its been off topic forever...

[Magic8Ball]

Monk is a genius. BehaartesEtwas is just a poser.
Monk is a rock n roll legend. BehaartesEtwas is just an indie R&B singer.
Monk is a monster truck. BehaartesEtwas is just a tricycle.
Monk is a B52 Bomber. BehaartesEtwas is a roflcopter.

[loopyman]

(11-25-2009, 04:40 AM)Magic8Ball Wrote:  Monk is a genius. BehaartesEtwas is just a poser.
Monk is a rock n roll legend. BehaartesEtwas is just an indie R&B singer.
Monk is a monster truck. BehaartesEtwas is just a tricycle.
Monk is a B52 Bomber. BehaartesEtwas is a roflcopter.

The hell?