로컬 네트워크의 여러 장치에 대해 일부 감시 기능을 수행하는 작은 Atom 기반 Micro-ATX 상자에서 실행되는 셸 스크립트가 있습니다. 이 기능 중 하나는 중요한 변경 사항이 있는지 일부 비디오 피드(가상 머신의 스크린샷 및 보안 카메라 피드)를 모니터링하는 것입니다. 데이터를 캡처하는 것은 문제가 되지 않는 것 같지만 이미지를 비교하여 변경 사항이 중요한지 확인하는 것은 상자를 죽이는 것입니다.
현재 설정에서 시간이 걸리는 유일한 것은 ImageMagick의 compare
명령입니다. 이 명령은 다음과 같이 실행됩니다.
compare -metric PHASH previous.png current.png null:
이는 이미지가 얼마나 유사한지 판단하는 데 상당히 유용한 숫자를 제공하지만영원히달리기. AE
다른 설정 등 다른 측정항목도 시도해 보았지만 -fuzz
런타임 차이는 미미한 것 같습니다.
저는 60K 640x480 이미지 한 쌍을 조작하고 있는데 명령을 실행하는 데 약 30초가 걸립니다. 몇 GB의 여유 RAM이 있으면 확실히 CPU가 정지됩니다. 명령을 실행하는 동안 4개의 코어가 모두 일시 중지됩니다. 비교를 위해 내 fatso 데스크탑에서 동일한 이미지를 시도했는데 실행 시간은 거의 2초였습니다. 이는 제가 달성하려는 작업에 비해 터무니없는 양의 CPU 시간입니다.
썸네일을 생성하고 얼마나 바뀌었는지 확인할 수 있다는 좋은 아이디어가 떠올랐습니다. 간단합니다. 일치하는 64x48 썸네일을 생성하고 compare
실행합니다. 결과는 평균 약 25초로 거의 구별할 수 없었습니다. 6x4 픽셀 이미지로 더 압축해도 프로세스 속도가 크게 향상되지는 않았지만 여전히 실행하는 데 약 25초가 걸렸습니다.
제가 잘못 구성했을 수도 있나요? 이 작업이 리소스를 많이 사용하는 이유는 무엇이며 이미지 크기가 중요하지 않은 이유는 무엇입니까? 두 개의 이미지가 특정 임계값을 초과하여 유출되는지 확인하는 다른 방법이 있습니까? (스크린샷 데이터는 픽셀 수를 강하게 변경하는 것이 트릭이기 때문에 더 쉽습니다. 그러나 비디오 데이터는 정적이며 차이 숫자를 파악하려면 블러링이 필요합니다.)
답변1
이는 S/W 문제도 아니고 Atom 문제도 아닌 것으로 보입니다. 나는 Arch Linux를 실행하는 호스트(D945GCLF2)로 Atom 330을 가지고 있습니다. 방금 이 테스트를 수행했습니다.
ttsiod@home ~/tmp
$ wget i.stack.imgur.com/fWwyu.png
--2014-10-29 14:30:08-- https://i.stack.imgur.com/fWwyu.png
Resolving i.stack.imgur.com (i.stack.imgur.com)... 103.31.7.31...
Connecting to i.stack.imgur.com (i.stack.imgur.com)|103.31.7.31|:80...
HTTP request sent, awaiting response... 200 OK
Length: 28576 (28K) [image/png]
Saving to: `fWwyu.png'
100%[==============================>] 28,576 --.-K/s in 0.06s
2014-10-29 14:30:09 (446 KB/s) - `fWwyu.png' saved [28576/28576]
ttsiod@home ~/tmp
$ wget https://i.stack.imgur.com/KQiJX.png
--2014-10-29 14:30:16-- https://i.stack.imgur.com/KQiJX.png
Resolving i.stack.imgur.com (i.stack.imgur.com)... 103.31.6.184
Connecting to i.stack.imgur.com (i.stack.imgur.com)|103.31.6.184|:80...
HTTP request sent, awaiting response... 200 OK
Length: 28212 (28K) [image/png]
Saving to: `KQiJX.png'
100%[==============================>] 28,212 --.-K/s in 0.06s
2014-10-29 14:30:17 (431 KB/s) - `KQiJX.png' saved [28212/28212]
ttsiod@home ~/tmp
$ identify KQiJX.png
KQiJX.png PNG 640x400 640x400+0+0 8-bit sRGB 28.2KB 0.000u 0:00.000
ttsiod@home ~/tmp
$ time compare -metric PHASH fWwyu.png KQiJX.png null:
0.191664
real 0m1.029s
user 0m2.863s
sys 0m0.177s
ttsiod@home ~/tmp
$ time compare -metric PHASH fWwyu.png fWwyu.png null:
0
real 0m1.027s
user 0m2.843s
sys 0m0.190s
compare
따라서 Atom330에서 두 개의 640x400 이미지를 생성하는 데 필요한 시간은 1초입니다. 이는 25초보다 훨씬 빠릅니다.
실행 중에 로그 출력이 없으면 strace -f
내가 추측할 수 있는 유일한 것은... 하드웨어 불량(아마도 수동으로 냉각된 CPU, 화재를 피하기 위해 속도가 느려진 것일까요?) 또는 잘못 컴파일된 바이너리(예: MMX/SSE를 사용하지 않음) 확장입니다. .
그런데 커널이 제한하지 않도록 하려면 루트로 먼저 다음을 수행하십시오.
for i in /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor ; do
echo performance > $i
done
그런 다음 테스트 중에 CPU 온도/주파수를 모니터링하려고 합니다. 잊어버릴 때까지 속도가 느려질 것 같습니다...
compare
완전성을 위해 위 테스트에서 사용한 커널과 버전은 다음과 같습니다 .
ttsiod@home ~/tmp
$ egrep '^model.na|^flags' /proc/cpuinfo | sort -u
model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz
flags : fpu vme de tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat clflush dts acpi
mmx fxsr sse sse2 ss ht tm pbe syscall
nx lm constant_tsc arch_perfmon pebs
bts nopl aperfmperf pni dtes64 monitor
ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe
lahf_lm dtherm
ttsiod@home ~/tmp
$ uname -a
Linux home 3.16.3-1-ARCH #1 SMP PREEMPT Wed Sep 17 21:54:13
CEST 2014 x86_64 GNU/Linux
ttsiod@home ~/tmp
$ compare --version
Version: ImageMagick 6.8.9-9 Q16 x86_64 2014-10-26 http://www.imagemagick.o
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC HDRI Modules OpenCL OpenMP
Delegates: bzlib cairo fontconfig freetype gslib jng jp2 jpeg lcms lqr ltdl
lzma pangocairo png ps rsvg tiff webp wmf x xml zlib