High load average in hikvision camera

[flasher]

Hi,
I have just bought my first hikvision camera - DS-2CD2087G2H-LIU 8MP. Accessing ssh I found out that the load average is around 50 (!). Is this normal for a hikvision camera? Rarely any system can work normally with such an load average ,

Here is part of top dump:

Mem: 343404K used, 6912K free, 31628K shrd, 56768K buff, 182552K cached
CPU: 18.3% usr  5.6% sys  0.0% nic 73.8% idle  0.0% io  0.0% irq  2.1% sirq
Load average: 49.40 48.70 48.82 2/324 6633
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
1018     1 admin    S     713m208.5   0 18.4 {Dsp_Main} /home/hikdsp
1089     1 admin    S <   384m112.2   1  2.4 /home/process/davinci
1151     2 admin    DW       0  0.0   1  1.5 [kdf_ipp_tsk]
1242     2 admin    DW       0  0.0   0  0.7 [NMR_VdoTrig_D2D]
1147     2 admin    DW       0  0.0   0  0.5 [ctl_ipp_buf_tsk]
1131     2 admin    DW       0  0.0   1  0.3 [ctl_sie_buf_tsk]
  752     2 admin    DW       0  0.0   1  0.3 [iq_tsk]
1132     2 admin    DW       0  0.0   0  0.2 [ctl_sie_isp_tsk]
1149     2 admin    DW       0  0.0   0  0.2 [ctl_ipp_isp_tsk]
   32     2 admin    SW       0  0.0   0  0.2 [irq/58-DAI_INT]
  633     2 admin    DW       0  0.0   0  0.1 [kdrv_ise_proc_t]
1150     2 admin    DW       0  0.0   0  0.1 [ctl_ipp_tsk]
  634     2 admin    DW       0  0.0   0  0.1 [kdrv_ise_cb_tsk]
    9     2 admin    SW       0  0.0   0  0.1 [ksoftirqd/0]
6576     2 admin    IW       0  0.0   1  0.1 [kworker/1:0-mm_]
6633  6630 admin    R     2848  0.8   1  0.0 top
6625  1302 admin    S     2696  0.7   1  0.0 dropbear -R -I 1800 -p 22
  949     2 admin    DW       0  0.0   1  0.0 [motor]
1381     2 admin    DW       0  0.0   1  0.0 [wav_play_tsk]
1380     2 admin    DW       0  0.0   0  0.0 [wav_rec_update_]
   10     2 admin    IW       0  0.0   0  0.0 [rcu_sched]
1379     2 admin    DW       0  0.0   0  0.0 [wav_rec_tsk]
1148     2 admin    DW       0  0.0   1  0.0 [ctl_ipp_ise_tsk]
1068     1 admin    S    26844  7.6   1  0.0 /home/process/net_process
1067     1 admin    S    24688  7.0   0  0.0 /home/process/database_process
  525     1 admin    S    20976  5.9   0  0.0 /bin/tee-supplicant
1019     1 admin    S     6168  1.7   0  0.0 /home/process/daemon_fsp_app
    1     0 admin    S     2848  0.8   1  0.0 init
1085     1 admin    S     2848  0.8   1  0.0 init
1302     1 admin    S     2568  0.7   1  0.0 dropbear -R -I 1800 -p 22
  460     1 admin    S     2408  0.6   0  0.0 syslogd -L -C320 -s512 -b 0
  526     1 admin    S     2400  0.6   0  0.0 logread -n -l
  990     1 admin    S     2312  0.6   0  0.0 /bin/execSystemCmd
6630  6625 admin    S     2252  0.6   1  0.0 -psh
1084     1 admin    S     2252  0.6   1  0.0 -/bin/psh
  462     1 admin    S     2080  0.5   0  0.0 klogd
  169     1 admin    S <   1780  0.5   1  0.0 /usr/bin/udevd -d
  742     2 admin    DW       0  0.0   0  0.0 [af_tsk]
1366     2 admin    SW       0  0.0   1  0.0 [jbd2/mmcblk0p1-]
   47     2 admin    SW       0  0.0   1  0.0 [kswapd0]
1244     2 admin    DW       0  0.0   0  0.0 [NMR_VdoTrig_D2D]
6098     2 admin    IW<      0  0.0   1  0.0 [kworker/1:2H-kb]
  954     2 admin    DW       0  0.0   1  0.0 [lt8618sx]
   16     2 admin    SW       0  0.0   1  0.0 [ksoftirqd/1]
6568     2 admin    IW       0  0.0   1  0.0 [kworker/1:2-eve]
   15     2 admin    SW       0  0.0   1  0.0 [migration/1]
   20     2 admin    SW       0  0.0   1  0.0 [hik-wdk-1]
6577     2 admin    IW       0  0.0   0  0.0 [kworker/0:2-eve]
   12     2 admin    SW       0  0.0   0  0.0 [migration/0]
   19     2 admin    SW       0  0.0   0  0.0 [hik-wdk-0]
1072     2 admin    SW<      0  0.0   0  0.0 [loop1]
    2     0 admin    SW       0  0.0   1  0.0 [kthreadd]
   26     2 admin    SW       0  0.0   0  0.0 [kcompactd0]
6609     2 admin    IW       0  0.0   1  0.0 [kworker/u4:0-ev]
6618     2 admin    IW<      0  0.0   0  0.0 [kworker/0:0H-mm]
6624     2 admin    IW       0  0.0   1  0.0 [kworker/u4:1-ev]
6626     2 admin    IW<      0  0.0   0  0.0 [kworker/0:1H-mm]
  497     2 admin    SW       0  0.0   1  0.0 [ubi_bgt3d]
6628     2 admin    IW       0  0.0   0  0.0 [kworker/0:1-eve]

 

[alastairstevenson]

Accessing ssh I found out that the load average is around 50 (!). Is this normal for a hikvision camera? Rarely any system can work normally with such an load average ,

This isn't something I've looked at in a while - but the load average does look a little anomalous (in that is it a real reading?) if the CPU idle is typically as shown in your extract.
But then I'm not sure what busybox is using to derive that figure when there are multiple cores in play, and a DSP closely connected.
Maybe it just gets it wrong.
In any case - if the camera is processing it's normal workload, it looks like there is still a fair overhead available.
I'd guess the workload is fairly steady, unlike what may be demanded of a general-purpose machine subject to variable user demand.

Here is a snapshot from a DS-2CD2087G2-L

Mem: 214236K used, 37748K free, 64380K shrd, 0K buff, 160696K cached
CPU0: 30.0% usr 16.3% sys  0.0% nic 44.7% idle  0.0% io  0.0% irq  8.9% sirq
CPU1: 55.2% usr 11.9% sys  0.0% nic 32.6% idle  0.0% io  0.0% irq  0.1% sirq
Load average: 6.28 6.68 6.44 2/287 17419
  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
  977     1 admin    S     360m146.4   1 48.3 {Dsp_Main} ./hikdsp
  796     1 admin    S <   386m157.1   1  8.7 /home/process/davinci
    3     2 admin    SW       0  0.0   0  0.6 [ksoftirqd/0]
  775     1 admin    S     6584  2.6   0  0.1 /home/process/daemon_fsp_app
17354 17353 admin    R     2924  1.1   0  0.1 top
17352   351 admin    S     2436  0.9   0  0.1 /usr/sbin/dropbear -R -I 1800
  963     2 admin    DW       0  0.0   1  0.1 [motor]
    7     2 admin    SW       0  0.0   0  0.1 [rcu_sched]
   22     2 admin    SWN      0  0.0   0  0.1 [ksmd]
  854     2 admin    SW       0  0.0   0  0.1 [irq/45-VI_CAP0]
  894     2 admin    DW       0  0.0   0  0.1 [Hi_VdecThread]
   14     2 admin    SW       0  0.0   1  0.1 [ksoftirqd/1]
  779     1 admin    S    22016  8.7   1  0.0 /home/process/net_process
  778     1 admin    S    20116  7.9   1  0.0 /home/process/database_process
    1     0 admin    S     2924  1.1   0  0.0 init
  792     1 admin    S     2924  1.1   1  0.0 init
  791     1 admin    S     2396  0.9   1  0.0 -/bin/psh
17353 17352 admin    S     2392  0.9   1  0.0 -psh
  351     1 admin    S     2308  0.9   1  0.0 /usr/sbin/dropbear -R -I 1800
  773     1 admin    S     1936  0.7   0  0.0 /bin/execSystemCmd
  121     1 admin    S <   1820  0.7   0  0.0 /usr/bin/udevd -d
  404     2 admin    SW       0  0.0   0  0.0 [ubi_bgt3d]

 

[flasher]

Load average: 6.28 6.68 6.44 2/287 17419

Hey,
Thanks for your reply. I'm using the latest firmware but don't have any weird stuff set up on the camera. I'll try resetting the camera to factory settings - I'll let you know if that helped anything. In the meantime, I'm attaching another screen shot after a full day of operation.

Update:
I have another idea. I have an SD card inserted into the camera and writing to it can generate a large load average.

 

[flasher]

I cannot update my previous post.

Here are the conclusions:
- disabling recording to SD card did not reduce load average
- restoring the camera to factory settings did not reduce load average.

If anyone has any other ideas - let me know.

 

[paulpeter]

probably the reason is that they use a lot of thread inside?

 

[watchful_ip]

As you may know, linux load average is not a direct reflection of CPU cores loading.

Idle % (in top) gives a better indication of that. While there's reasonable CPU idle capacity in normal operation, don't worry about load avg.

If there's little or no idle, and lots of processes/threads in the run queue or waiting for I/O etc then /proc/loadavg is handy for tracking system performance over time.

There's a general guide that if loadavg if more than number of CPU cores that may not be good - but it depends on what is running and how it's running. A 50 loadavg could mean a system will hardly respond at all due to resource saturation, or it might be fine. If your camera has good idle %, and responds to web interface requests in a few seconds not minutes - then you are fine

Here's some interesting info for anyone interested in this topic. Linux Load Averages: Solving the Mystery

 

[watchful_ip]

FYI a top output taken today from the same IPC_G5 range as yours - same kind of loadavg and it's running Oct 2023 firmware



It's on port 1 using 4.2V - it's night time here so IR is on.
That's less than the IPC_G3 on port 5 (4.5V) which has a loadavg of 4.78