Server: GT Idle before work results in unstable FPS

Development Programming & Scripting
, ,
1

Hello,

We’re looking into performance of the Linux server, and we often find frames which take 40ms to complete, or 20ms to complete, while the actual GT work is between 28ms or 20ms.

The server is set to a 33ms/30fps budget, which results in “Game thread idle time” before the GT work starts. But the idle time is based on the previous frames’s time.

When we have a frame where the GT work completed in 20ms, the next frame the server would idle about 12ms before starting the next frame, but if the next frame has a hitch/spike where it has to compute more than usual, and the actual GT work time would end up as 28ms the next frame, the total time for that frame would be over 40ms, despite being under the 33ms budget. Inversely, if we have a very expensive frame (40ms), and the next frame is very cheap (20ms), then we end up with a really short 20ms frame with no idle time at all. The idle before GT work starts, based on the previous frame, results in the server having a fluctuating MS between 30ms and 35ms, while the actual GT work is usually between 20ms and 26ms. We would expect that if our GT work is below 33ms, that we’d achieve a stable 33ms per frame.

This would likely not be a huge issue, as the values does balance out at 33ms on average, but we run with NPP, and artificially expensive frames of 40ms due to idle time, just because the previous frame was fast results in occasional double NPP simulations in a single frame, which can put the cost of our GT work well over the 33ms budget, and this can then compound over time.

For this our question here is, is there any particular reason we idle the GT before doing GT work, instead of after? The GT idle time can’t accurately predict how expensive a GT frame will be, but we know exactly how much time is left (if any) to achieve 33ms once the GT work is over. On clients, I can understand this as we’d likely want the GPU/CPU to be done around the same time, but on servers with no rendering, it looks to be causing unstable MS/FPS. Is there a particular reason it is done this way? Or would it be possible to move the idle time after the GT work on dedicated servers to ensure a more stable FPS server-side?

Thank you for your time,

With kind regards,

Céleste Neukirchen

[Attachment Removed]

2

Steps to Reproduce
Run a linux server with varying 20 to 40ms GT work time.

[Attachment Removed]

3

Hi Celeste.

If you measure for end of Idle to to the next frame’s end of idle time, do the frame measurements look more consistent?

Best regards.

[Attachment Removed]

4

Hi Celeste,

Looking at your frame sequence, work time of Frame ! + idle time for frame B which yields the expected 33ms. What is the idle time observed for the frame after Frame B?

Best regards.

[Attachment Removed]

5

Hello,

Apologies for the late response. Yes, if we take the end of idle to next end of idle, it does line up in most cases, which makes sense because the delay is added after the end of the frame. But I do see cases where we had a short frame, followed by a hitch frame, which first waited on the idle time of the previous frame, and then processed the hitch frame.

Example:

Frame A: Idled 11.8ms at the start of the frame (based on previous frame ms)

Frame A: Did work for 24ms

Frame A total: Total of 36ms

Frame B: idled for 9ms (based on the work of 24ms)

Frame B: Did work for 32.7ms

Frame B total: 42.7ms

Result: Frame A and B together took 79ms to complete, both both frames did work under 33ms. The total time should be 66ms, but because the idle time is done before the frame, the total time exceeds the 66ms and now half an extra NPP frame will be scheduled.

To us this seems wasteful, when we know both frames did not exceed the work budget of 33ms, but it took 13ms longer to complete 2 frames because of where the idle time is placed.

[Attachment Removed]