obsproject / obs-studio

OBS Studio - Free and open source software for live streaming and screen recording
https://obsproject.com
GNU General Public License v2.0
59.39k stars 7.88k forks source link

CPU usage in Stats tab inaccurate and consistently underreported. #6525

Open jessegrondin opened 2 years ago

jessegrondin commented 2 years ago

Operating System Info

Windows 11

Other OS

No response

OBS Studio Version

27.2.4

OBS Studio Version (Other)

No response

OBS Studio Log URL

https://obsproject.com/logs/5VFgNqpO5YlrB3eQ

OBS Studio Crash Log URL

No response

Expected Behavior

CPU usage reported in OBS Stats panel and bottom right corner appears to be consistently underreported.

Here is a screenshot capturing both Task Manager and OBS at the same point in time. image image

__

Current Behavior

CPU usage is consistently under reported.

Steps to Reproduce

  1. Start OBS with usual sources.
  2. Measure CPU usage from both OBS stats and Task Manager
  3. Compare results. ...

Anything else we should know?

Windows 11 21H2 22000.675 Ryzen 5600x 16 gig of ram Geforce RTX 3700

Pablomx2 commented 2 years ago

image Not for me

jessegrondin commented 2 years ago

Please provide full machine details.

DlmuZQ commented 2 years ago

I met the same problem image image

andmayfi92 commented 2 years ago

I'll do you one better. Stats dock shows <10% CPU usage in OBS but Task Manager shows 45%!!!! Thats not just underreporting its just plain incorrect. IDK what the value of the OBS Stats dock is tracking but man is it incorrect.

Specs: Ryzen 9 5900HX 64GB 3200MHz RAM RTX 3080 2x970 Pro Raid 0 image

WizardCM commented 2 years ago

@andmayfi92 The Stats dock only tracks the obs64.exe process. If you expand OBS Studio in task manager, you'll see a bunch of obs-browser-page.exe which are all your browser sources and browser docks.

andmayfi92 commented 2 years ago

Fair enough but its still 50% inaccurate on that process alone. image

killarny commented 2 years ago

System: Core i5-6500, 32GB RAM, RTX 2070 Super OS: Windows 11, 22H2 OBS: 27.2.4

Seeing similar wild inaccuracies here in both CPU and memory usage numbers (although mem is closer to accurate) and I don't even have any browser sources:

image

Judging by the performance impact on my system while OBS is running, I think the usage reported in task manager is more likely the correct number.

MisutaaAsriel commented 1 year ago

I get the same thing on macOS. I get the impression that the "stat" is only that of the renderer itself, not the application as a whole.

kodizhuk commented 1 year ago

I see the same problem OBS 29.0.0 CPU i7-4720HQ, GPU Nvidia GeForce GTX 970

Screenshot_1
alinsavix commented 5 months ago

Hokay, best I can tell, this is a legitimate bug, but perhaps not in OBS. I'm not sure exactly what's happening, but windows seems like maybe it's lying to us (though what OBS is doing differently from other software, I'm not sure).

Initial testing setup:

Testing:

These are very obviously different.

OBS also normalizes by CPU count. If I undo that normalization (I have 24 cores -- 8 core/16 threads performance, 8 economy), 0.1% to 0.2% turns into 2.4% to 4.8%, which is a whole lot closer to the right ballpark. It's difficult to say if it's actually giving the right value, due to differing sampling intervals and such, but it's at least closer. So what's going on?

The code in OBS (in os_cpu_usage_info_query inside platform-windows.c) is, basically:

  1. every 3 seconds, call GetProcessTimes(GetCurrentProcess()) to get user time and system time measurements, storing the previous measurement in a variable first
  2. at the same time, call call GetSystemTimeAsFileTime() to get the time of the measurement
  3. calculate amount of CPU time used by adding (current_sys_cpu - previous_sys_cpu) and (current_user_cpu - previous_user_cpu)
  4. calculate the percentage of the total available CPU time was used by dividing that result by (current_time - previous_time)
  5. normalize the result by dividing by the number of CPU cores
  6. convert to a percent by multiplying by 100

Logically, this makes sense. Are the windows APIs not returning what we think they're returning? Well, there's two things I can think of... but first, just a quick note: GetSystemTimeAsFileTime and GetProcessTimes both return times in terms of a FILETIME structure, which is basically just an ugly representation of an unsigned 64-bit integer measuring units of "100ns" of time. Because everything is working in the same units of time, the units cancel and we can ignore the stupid "100ns" units. The math works out the same regardless if the units are 100ns or 1s or 1h, as long as they're the same.

Anyhow, possibility 1: we're only measuring the CPU utilization of a single OBS thread, rather than all threads, in the main process. I have no way to objectively determine whether this is the case, but the documentation for GetProcessTimes explicitly says:

The time that each of the threads of the process has executed in kernel mode is determined, and then all of those times are summed together to obtain this value. and The time that each of the threads of the process has executed in user mode is determined, and then all of those times are summed together to obtain this value. So unless that's really wrong and just nobody has noticed in the past two decades, that's probably not what is happening.

Possibility 2: CPU time used for the process is already normalized by CPU count. But again looking at the documentation for GetProcessTimes, it says:

Note that this value can exceed the amount of real time elapsed (between lpCreationTime and lpExitTime) if the process executes across multiple CPU cores. It being possible for the cumulative CPU time used to exceed the total runtime of the process, due to having multiple cores, is a solid indication that this is not the case, either.

So... I got nothing. The CPU value given by OBS (at least under what should be pretty normal conditions) is wrong to the point of uselessness, but I don't see an obvious reason why. It seems like GetProcessTimes is returning bad values, but that seems unlikely. So what am I missing?