How to tell the difference between networking issues and CPU/load issues?

[camviewer43]

I have Blue Iris on a VM, and it doesn't have quick sync. When I watch the Blue Iris feed of my cameras in VLC on a computer, I see it often skip a couple seconds where the the time on the footage stops and then runs again. And sometimes the BI stream is "blocky".

Trying to figure out if this is caused by the lack of Quick Sync support or if it's the weak network link from the toolshed to the house (wifi bridge), what should I look out for? What would indicate an CPU issue, and what would indicate a network issue?

The VM is only using less than 20% of the two cores it's allowed, even when I'm viewing the BI provided camera stream. Does that indicate that it's not a processing issue if the CPU utilization is so low? Or is that not a good indicator? Do you get different artifacts between CPU-bound vs network-bound issues?

 

[TonyR]

Have you read ==>> Troubleshooting Streaming Problems ?

My money is on the wireless, although could be a bit of both network and CPU.

• So you have a "wi-fi bridge" out to the tool shed?
• Is this a different run from your project Dec. last year with underground conductors out to the garage?
• What are the components of the "wi-fi bridge" ?

 

[bp2008]

20% utilization of 2 cores sounds great, since it would need to be 50% to make one core fully saturated.

Network trouble is a possibility, one way to test is to get a tool like pingtracer (an app I wrote for visual ping monitoring). Put that on the Blue Iris VM. Enter your camera IPs, comma separated, and have it ping them at a rate of 3 to 10 pings per second. This will draw the response times on a graph. Now ideally you will barely even see anything on the graphs because all the response times will be 0ms and that will draw as a flat line at the bottom of each graph. But realistically there will be a few upward spikes and maybe a little packet loss indicated by red lines. As long as it is low (< 10ms) and steady with almost no packet loss, that means your network is performing pretty well. One missed ping every once in a while is not unusual.

The lack of Quick Sync support is not a problem, if anything Quick Sync in Blue Iris is more likely to cause a problem than to solve a problem these days.

If the network is good and stable, then probably the issue can be chalked up to either bugs in the camera, bugs in Blue Iris, or some other kind of VM performance problem. VMs do add a layer of complexity and that can encourage issues where a bare metal Windows install would work better.

 

[bp2008]

And sometimes the BI stream is "blocky".

As seen in Blue Iris's console (the desktop app)?

Could it simply be your method of remote access to the VM is not particularly performant? It is common for VMs to have poor graphics performance if they only have virtual graphics hardware.

 

[camviewer43]

The wifi bridge is just a router that's connected as a wifi client to the main house wifi. I'll try to do some more testing on how well that wifi bridge performs. I did hardwire to it one time and did a quick download test and it was more than 30MBps, but I know that doesn't tell the whole story.

I'm surprised to hear about quick sync - all the wiki seems to say it's important. I might do a BI test where I install temporarily on a computer by itself and see how that performance differs.

@bp2008 I'm using the web interface for Blue Iris when I see the blockyness, not accessing the remote desktop.

 

[wittaj]

The wiki is a little dated.

Around the time AI was introduced in BI, many here had their system become unstable with hardware acceleration on (even if not using DeepStack or CodeProject). Some have also been fine. I started to see that error when I was using hardware acceleration.

This hits everyone at a different point. Some had their system go wonky immediately, some it was after a specific update, and some still don't have a problem, yet the trend is showing running hardware acceleration will result in a problem at some point especially if using VPP.

However, with substreams being introduced, the CPU% needed to offload video to a GPU (either internal graphics on the CPU or an added GPU) is more than the CPU% savings seen by offloading to a GPU. Especially after about 12 cameras, the CPU goes up by using a GPU and hardware acceleration.

My CPU % went down by not offloading to a GPU.

In fact I even disabled the internal GPU as a test and it was fine.

Further, the use of substreams has allowed non Intel computers (thus no quick sync) and intel chips without wuick sync to become effective machines.

 

[ludshed]

It’s usually a wireless bottleneck, even for my test/demo rig I had to upgrade both router and wireless extender to ax for 4 cameras. Have you tried either running a temp line out or bringing cameras inside to see if problem replicates?

 

[TonyR]

The wifi bridge is just a router that's connected as a wifi client to the main house wifi. I'll try to do some more testing on how well that wifi bridge performs. I did hardwire to it one time and did a quick download test and it was more than 30MBps, but I know that doesn't tell the whole story.

It would be good to know the results of the test of the wireless bridge's speed and bandwidth, since you already know the hardwired.
As mentioned above by @ludshed , going hardwired to see how it affects your issue would be a great ideo, IMO, even if the test of the wireless bridge comes back 'good.'

FWIW, a purpose-built, outdoor-rated Wireless Layer 2 Transparent Bridge works so much better that consumer indoor routers set up as AP and client.
Example schema:

 

[bp2008]

@bp2008 I'm using the web interface for Blue Iris when I see the blockyness, not accessing the remote desktop.

Don't use the VBR streaming profiles in the web interface. The quality tends to drop very noticeably temporarily whenever those streams have a keyframe (which is infrequent, but it does happen on a regular basis). The other streaming profiles use a lot more bandwidth, but they deliver higher quality more consistently.