DS-2CD2386G2 stuttering caused by overruns

C

croy

n3wb
Jul 30, 2021
5
3
Scotland
Hi, I've been playing around with the hikvision 2386g2 but cant seem to get a smooth live view. Ive setup homebridge and webrtc to view the main feed but it stutters for a second everytime a new keyframe comes in.
ssh'ing into the camera and running ifconfig shows that packets are being constantly dropped due to overruns

"TX packets:1412725 errors:0 dropped:48327 overruns:48327 carrier:0"

lowering the bitrate on the camera and setting smoothing to 100% stops the overruns and dropped packets, the stream plays smoothly now but quality takes a big hit.
Ive tested with multiple switches and cables but the problem remains.

Has anyone else experieced any similiar issues?
 
croy said:
Ive setup homebridge and webrtc to view the main feed but it stutters for a second everytime a new keyframe comes in.
Click to expand...
With that many overruns, it may be that whatever you're feeding the video into isn't able to cope with the data rate.
Can you run any form of performance monitor on it, check CPU utilisation etc?
Presumably no part of the network path is over WiFi or powerline adaptor?
 
alastairstevenson said:
With that many overruns, it may be that whatever you're feeding the video into isn't able to cope with the data rate.
Can you run any form of performance monitor on it, check CPU utilisation etc?
Presumably no part of the network path is over WiFi or powerline adaptor?
Click to expand...
CPU usage is under 20% and the stream is set to copy so no encoding is taking place. Everything is hardwired and the switch reports no packet errors. A ping test averages around 3ms
I've also got a 2347G2 setup as well this runs without issue.
My theory is the 8MP camera isnt able to push out the data fast enough and thats causing the overruns
 
croy said:
CPU usage is under 20% and the stream is set to copy so no encoding is taking place. Everything is hardwired and the switch reports no packet errors.
Click to expand...
That should be OK, network-wise.

croy said:
A ping test averages around 3ms
Click to expand...
That does seem a bit high. I'd expect sub-millisecond as a rule.
I wonder if the CPU is being stretched.

As a comparison, here are ping tests on a couple of 8MP DS-2CD2385G1 cameras.
Code: 
alastair@PC-I5 ~ $ ping 192.168.1.111
PING 192.168.1.111 (192.168.1.111) 56(84) bytes of data.
64 bytes from 192.168.1.111: icmp_seq=1 ttl=64 time=0.233 ms
64 bytes from 192.168.1.111: icmp_seq=2 ttl=64 time=0.333 ms
64 bytes from 192.168.1.111: icmp_seq=3 ttl=64 time=0.235 ms
^C
--- 192.168.1.111 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2047ms
rtt min/avg/max/mdev = 0.233/0.267/0.333/0.046 ms
alastair@PC-I5 ~ $ ping 192.168.1.103
PING 192.168.1.103 (192.168.1.103) 56(84) bytes of data.
64 bytes from 192.168.1.103: icmp_seq=1 ttl=64 time=0.199 ms
64 bytes from 192.168.1.103: icmp_seq=2 ttl=64 time=0.234 ms
64 bytes from 192.168.1.103: icmp_seq=3 ttl=64 time=0.321 ms
^C
--- 192.168.1.103 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2031ms
rtt min/avg/max/mdev = 0.199/0.251/0.321/0.051 ms
alastair@PC-I5 ~ $


And here for comparison are some interface error counts for those cameras, over about a 5 month uptime.

Code: 
# prtHardInfo
Start at 2021-09-29 12:58:25
Serial NO :DS-2CD2385G1-I20190411AAWRD09494822
<snip>

# ifconfig
eth0      Link encap:Ethernet  HWaddr 98:8B:0A:64:DB:D5
          inet addr:192.168.1.103  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::9a8b:aff:fe64:dbd5/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4113913262 errors:0 dropped:1958 overruns:0 frame:0
          TX packets:1834890065 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3595876970 (3.3 GiB)  TX bytes:1061974719 (1012.7 MiB)
          Interrupt:65

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

#

Code: 
# prtHardInfo
Start at 2021-09-17 15:49:08
Serial NO :DS-2CD2385G1-I20190915AAWRD62218681
<snip>

# ifconfig
eth0      Link encap:Ethernet  HWaddr BC:BA:C2:EB:28:EB
          inet addr:192.168.1.111  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::beba:c2ff:feeb:28eb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:289428791 errors:0 dropped:2115 overruns:0 frame:0
          TX packets:2913437899 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2026567060 (1.8 GiB)  TX bytes:1878459394 (1.7 GiB)
          Interrupt:65

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1345 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1345 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:121050 (118.2 KiB)  TX bytes:121050 (118.2 KiB)

#

croy said:
My theory is the 8MP camera isnt able to push out the data fast enough and thats causing the overruns
Click to expand...
Yes, but why?
The camera, or its environment?
The data rate isn't huge, even with a 10/100Mbps link.
And network processing isn't onerous with these farm fast ARM cores.
I don't believe we have many posts about 8MP G2 cameras stuttering - maybe others can comment.
 
alastairstevenson said:
Just a thought - what does 'top' show for the camera?
On the samples I quoted above, the CPU is running at around 50% utilisation.
Click to expand...
I've been doing more testing and might have found the cause. I tested the camera with a netgear switch and the overruns have stopped, My main switch is a unifi 24port and it seems like everytime the camera is connected via the unifi switch the overruns and dropped packets return. The colorvu camera is also connected to the unifi but doesnt have the same issues.
Running "top" shows around 20% cpu usage on the camera
 
  • Like
Reactions: alastairstevenson
Interesting. I'd not have thought that the model of switch would be implicated in the cause. Switches are believed to be mature and stable technology, not a source of problems.
Just out of curiosity, did you power cycle the switch?
Presumably the ping response is looking better now.
It's as if the switch fabric is congested and not coping with the traffic.
 
alastairstevenson said:
Interesting. I'd not have thought that the model of switch would be implicated in the cause. Switches are believed to be mature and stable technology, not a source of problems.
Just out of curiosity, did you power cycle the switch?
Presumably the ping response is looking better now.
It's as if the switch fabric is congested and not coping with the traffic.
Click to expand...
I power cycled the switch and also did a factory reset but neither helped. Connecting directly to the camera without the switch shows a ping of around 1ms, with the switch ping times vary from around 0.5 to 5ms

When there was a direct connection between the pc and camera the overruns issue also dissapeared. Any ideas what the unifi switch could be doing?
 
  • Like
Reactions: alastairstevenson
You must log in or register to reply here.
Top Bottom