CPU Usage & Throttling

Joined
Mar 23, 2015
Messages
14
Reaction score
0
Hello folks-

I am a video surveillance tech and have been using Blue Iris for a few years now. Love the program, love the flexibility. However, I'm running into a serious issue with the CPU down throttling to 47% maximum frequency, and of course, at this time, the CPU caps out at 100%. This *only* happens if I attempt to use the web server and/or view a clip inside the Blue Iris player. JPEG/ActiveX, doesn't matter which. It continues until I close the webserver (or BI player), and then goes back to normal within say, 30s.

I maintain 4 Blue Iris systems and this is the only one with this problem. Normally the CPU sits at 28%-35% with all cameras running, and jumps to 45%-65% when being pushed hard..i.e.. multiple channels recording and viewing clips/webserver, before it tacks out.

This particular system is an i7-2600 3.4ghz running 9 cameras, 7 3MP cameras (15fps, 2 @ 2048x1536, 5 @ 1080p), and two low-res cameras (one off-site). Here's a list of all the things I've done in an attempt to narrow down the issue.

Changed minimum process state to 100% in power options (disables intel speedstep supposedly, need to double check BIOS for C-state options).

Turned indexing off for all drives (primary HD is a SSD).

Enabled Direct-to-Disc & using H264 for all feeds.

Added Blue Iris directories, including video storage locations to Antivirus exceptions.

Turned off Windows Update (I prefer to tell it when to update).

Disabled System Restore & Sleep/Hibernation.

Set Blue Iris to run as a service.
^^^
Important note here: System runs 25%-35% as service, 33%-40% with Blue Iris interface opened. Viewing all 9 cameras with the interface open does not seem to cause the issue at all.

Used LatencyMon for only a minute, but it definitely measured some delays in the computer's processing. Report will be at the bottom. *EDIT* Forgot to mention, using LatencyMon reproduced the same issue, 47% maximum frequency on the CPU. I should point out that temperature was not a factor here, it was low 60s.

Tried ThrottleStop to force the CPU & chipset frequency to stay at 100%, no obvious change. It did allow me to observe that all 8 cores seem to be operating and capable of reaching 100% usage.

Used IntelBurnTest to bench test the CPU. I noticed during the testing that the maximum frequency dropped to 47% in a cyclical manner, however the results at the end were exactly the same (ran at Standard, then Very High stress level). Am I mistaken in thinking this proves my cores are running stable? Wouldn't a variation in performance or throttling due to temperature cause the results to be inconsistent?
**I realize this isn't a program everyone uses. Anyone know of good program to *specifically* test if temperature is causing down throttle?**

I mention temperature because the CPU can get to 70-72 degrees Celsius at it's maximum, but the aftermarket cooler does a great job of keeping it between 50-65 degrees. This thing has run stable for 1.5 years with no change in its average temperature. So I would prefer not to just point a finger there unless there is no doubt. Hence my question above for a testing program.


The CPU should have no issue running Blue Iris as a service and the web server at the same time. The CPU is only at 33% average before I attempt to use the web server. This one has been stumping me for months.

Any thoughts?

**Latency Monitor Results** <-- notice CPU0 below, only processor showing ISR interrupts. Is that normal?

_________________________________________________________________________________________________________
CONCLUSION
_________________________________________________________________________________________________________
Your system appears to be having trouble handling real-time audio and other tasks. You are likely to experience buffer underruns appearing as drop outs, clicks or pops. One problem may be related to power management, disable CPU throttling settings in Control Panel and BIOS setup. Check for BIOS updates.
LatencyMon has been analyzing your system for 0:01:16 (h:mm:ss) on all processors.


_________________________________________________________________________________________________________
SYSTEM INFORMATION
_________________________________________________________________________________________________________
Computer name: RES-SECURITY
OS version: Windows 7 Service Pack 1, 6.1, build: 7601 (x64)
Hardware: INTEL_, Intel Corporation, DH67BL
CPU: GenuineIntel Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Logical processors: 8
Processor groups: 1
RAM: 8169 MB total


_________________________________________________________________________________________________________
CPU SPEED
_________________________________________________________________________________________________________
Reported CPU speed: 3392 MHz
Measured CPU speed: 1 MHz (approx.)

Note: reported execution times may be calculated based on a fixed reported CPU speed. Disable variable speed settings like Intel Speed Step and AMD Cool N Quiet in the BIOS setup for more accurate results.

WARNING: the CPU speed that was measured is only a fraction of the CPU speed reported. Your CPUs may be throttled back due to variable speed settings and thermal issues. It is suggested that you run a utility which reports your actual CPU frequency and temperature.



_________________________________________________________________________________________________________
MEASURED INTERRUPT TO USER PROCESS LATENCIES
_________________________________________________________________________________________________________
The interrupt to process latency reflects the measured interval that a usermode process needed to respond to a hardware request from the moment the interrupt service routine started execution. This includes the scheduling and execution of a DPC routine, the signaling of an event and the waking up of a usermode thread from an idle wait state in response to that event.

Highest measured interrupt to process latency (µs): 32234.471155
Average measured interrupt to process latency (µs): 18.729922

Highest measured interrupt to DPC latency (µs): 587.10760
Average measured interrupt to DPC latency (µs): 12.762292


_________________________________________________________________________________________________________
REPORTED ISRs
_________________________________________________________________________________________________________
Interrupt service routines are routines installed by the OS and device drivers that execute in response to a hardware interrupt signal.

Highest ISR routine execution time (µs): 96.160967
Driver with highest ISR routine execution time: ataport.SYS - ATAPI Driver Extension, Microsoft Corporation

Highest reported total ISR routine time (%): 0.015507
Driver with highest ISR total time: hal.dll - Hardware Abstraction Layer DLL, Microsoft Corporation

Total time spent in ISRs (%) 0.042946

ISR count (execution time <250 µs): 94666
ISR count (execution time 250-500 µs): 0
ISR count (execution time 500-999 µs): 0
ISR count (execution time 1000-1999 µs): 0
ISR count (execution time 2000-3999 µs): 0
ISR count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED DPCs
_________________________________________________________________________________________________________
DPC routines are part of the interrupt servicing dispatch mechanism and disable the possibility for a process to utilize the CPU while it is interrupted until the DPC has finished execution.

Highest DPC routine execution time (µs): 547.594340
Driver with highest DPC routine execution time: ndis.sys - NDIS 6.20 driver, Microsoft Corporation

Highest reported total DPC routine time (%): 0.677935
Driver with highest DPC total execution time: ndis.sys - NDIS 6.20 driver, Microsoft Corporation

Total time spent in DPCs (%) 0.909655

DPC count (execution time <250 µs): 727371
DPC count (execution time 250-500 µs): 0
DPC count (execution time 500-999 µs): 1256
DPC count (execution time 1000-1999 µs): 0
DPC count (execution time 2000-3999 µs): 0
DPC count (execution time >=4000 µs): 0


_________________________________________________________________________________________________________
REPORTED HARD PAGEFAULTS
_________________________________________________________________________________________________________
Hard pagefaults are events that get triggered by making use of virtual memory that is not resident in RAM but backed by a memory mapped file on disk. The process of resolving the hard pagefault requires reading in the memory from disk while the process is interrupted and blocked from execution.


Process with highest pagefault count: blueiris.exe

Total number of hard pagefaults 19
Hard pagefault count of hardest hit process: 16
Highest hard pagefault resolution time (µs): 511.034198
Total time spent in hard pagefaults (%): 0.000202
Number of processes hit: 2


_________________________________________________________________________________________________________
PER CPU DATA
_________________________________________________________________________________________________________
CPU 0 Interrupt cycle time (s): 6.901831
CPU 0 ISR highest execution time (µs): 96.160967
CPU 0 ISR total execution time (s): 0.261661
CPU 0 ISR count: 94666
CPU 0 DPC highest execution time (µs): 547.594340
CPU 0 DPC total execution time (s): 5.285386
CPU 0 DPC count: 683133
_________________________________________________________________________________________________________
CPU 1 Interrupt cycle time (s): 0.879469
CPU 1 ISR highest execution time (µs): 0.0
CPU 1 ISR total execution time (s): 0.0
CPU 1 ISR count: 0
CPU 1 DPC highest execution time (µs): 81.112028
CPU 1 DPC total execution time (s): 0.035775
CPU 1 DPC count: 5851
_________________________________________________________________________________________________________
CPU 2 Interrupt cycle time (s): 0.856029
CPU 2 ISR highest execution time (µs): 0.0
CPU 2 ISR total execution time (s): 0.0
CPU 2 ISR count: 0
CPU 2 DPC highest execution time (µs): 102.984670
CPU 2 DPC total execution time (s): 0.035047
CPU 2 DPC count: 6531
_________________________________________________________________________________________________________
CPU 3 Interrupt cycle time (s): 0.809029
CPU 3 ISR highest execution time (µs): 0.0
CPU 3 ISR total execution time (s): 0.0
CPU 3 ISR count: 0
CPU 3 DPC highest execution time (µs): 110.494104
CPU 3 DPC total execution time (s): 0.029970
CPU 3 DPC count: 5868
_________________________________________________________________________________________________________
CPU 4 Interrupt cycle time (s): 0.863103
CPU 4 ISR highest execution time (µs): 0.0
CPU 4 ISR total execution time (s): 0.0
CPU 4 ISR count: 0
CPU 4 DPC highest execution time (µs): 117.557783
CPU 4 DPC total execution time (s): 0.040026
CPU 4 DPC count: 8772
_________________________________________________________________________________________________________
CPU 5 Interrupt cycle time (s): 0.801276
CPU 5 ISR highest execution time (µs): 0.0
CPU 5 ISR total execution time (s): 0.0
CPU 5 ISR count: 0
CPU 5 DPC highest execution time (µs): 42.825472
CPU 5 DPC total execution time (s): 0.021650
CPU 5 DPC count: 3290
_________________________________________________________________________________________________________
CPU 6 Interrupt cycle time (s): 0.471334
CPU 6 ISR highest execution time (µs): 0.0
CPU 6 ISR total execution time (s): 0.0
CPU 6 ISR count: 0
CPU 6 DPC highest execution time (µs): 141.412736
CPU 6 DPC total execution time (s): 0.081057
CPU 6 DPC count: 13532
_________________________________________________________________________________________________________
CPU 7 Interrupt cycle time (s): 0.583384
CPU 7 ISR highest execution time (µs): 0.0
CPU 7 ISR total execution time (s): 0.0
CPU 7 ISR count: 0
CPU 7 DPC highest execution time (µs): 48.807193
CPU 7 DPC total execution time (s): 0.013361
CPU 7 DPC count: 1650
_________________________________________________________________________________________________________

****
 
Last edited by a moderator:

ruppmeister

Getting the hang of it
Joined
Apr 15, 2015
Messages
668
Reaction score
98
I noticed the other night I was having a similar problem on my BI system if I was accessing the jpegpull.htm page from the server machine itself. As soon as I used another machine on my network, problem wasn't present. Only when I tried from the server to access the server webpage. Is this what you were doing also?
 
Joined
Mar 23, 2015
Messages
14
Reaction score
0
For me, the down-throttling occurs whether I use the BI machine or a different one to access the web viewer, and/or whenever I access a BVR file in the BI player or the web viewer.
 

fenderman

Staff member
Joined
Mar 9, 2014
Messages
36,901
Reaction score
21,269
Send this info to support and see what he says.
 
Joined
Mar 23, 2015
Messages
14
Reaction score
0
I've already contacted Ken and he is doing what he can to help, but this issue *could* be hardware specific, so it might be difficult to reproduce. I will check the Bios tomorrow and get the model number off the motherboard and see if anyone has had similar issues with the hardware.
 

fenderman

Staff member
Joined
Mar 9, 2014
Messages
36,901
Reaction score
21,269
I've already contacted Ken and he is doing what he can to help, but this issue *could* be hardware specific, so it might be difficult to reproduce. I will check the Bios tomorrow and get the model number off the motherboard and see if anyone has had similar issues with the hardware.
are you running the latest bios for your mobo?
 

fenderman

Staff member
Joined
Mar 9, 2014
Messages
36,901
Reaction score
21,269
Good question, will confirm that tomorrow. I bought the computer used, but since the install was very clean looking I didn't bother to wipe it.
i would certainly do a clean install..also check the device manager and confirm that all the drivers are properly installed, particularly the chipset drivers.
 
Joined
Mar 23, 2015
Messages
14
Reaction score
0
So as I suspected (hoped really), the BIOS had C states to disable, and additional Intel SpeedStep, and disabling these stopped the system from down-throttling the CPU. I am now able to view the web server, and BVR files, without a single hiccup. CPU only goes as high as 45%.

There is one remaining issue, which hopefully is easier to troubleshoot.

If I view a BVR file, everything is fine until I attempt to 4x or 8x, and that works for a moment, but then quickly maxes out the CPU (no down-throttling, so it is the ACTUAL maximum).

Is processing for 4x/8x playback really so intensive that it would take up the remainder 50% available, on a system running 9 3MP cameras smoothly?
 
Top