IP(TS) ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು TSDuck ಅನ್ನು ಬಳಸುವುದು

ಇಂದು, ಐಪಿ(ಟಿಎಸ್) ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಸಿದ್ಧವಾದ (ಸ್ವಾಮ್ಯದ) ಪರಿಹಾರಗಳಿವೆ, ಉದಾಹರಣೆಗೆ VB и iQ, ಅವರು ಸಾಕಷ್ಟು ಶ್ರೀಮಂತ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಟಿವಿ ಸೇವೆಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುವ ದೊಡ್ಡ ನಿರ್ವಾಹಕರು ಅಂತಹ ಪರಿಹಾರಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ. ಈ ಲೇಖನವು ಮುಕ್ತ ಮೂಲ ಯೋಜನೆಯ ಆಧಾರದ ಮೇಲೆ ಪರಿಹಾರವನ್ನು ವಿವರಿಸುತ್ತದೆ TSDuck, CC(ಕಂಟಿನ್ಯೂಟಿ ಕೌಂಟರ್) ಕೌಂಟರ್ ಮತ್ತು ಬಿಟ್ರೇಟ್ ಮೂಲಕ IP(TS) ಸ್ಟ್ರೀಮ್‌ಗಳ ಕನಿಷ್ಠ ನಿಯಂತ್ರಣಕ್ಕಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಗುತ್ತಿಗೆ ಪಡೆದ L2 ಚಾನಲ್ ಮೂಲಕ ಪ್ಯಾಕೆಟ್‌ಗಳ ನಷ್ಟ ಅಥವಾ ಸಂಪೂರ್ಣ ಹರಿವನ್ನು ನಿಯಂತ್ರಿಸುವುದು ಒಂದು ಸಂಭವನೀಯ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ (ಉದಾಹರಣೆಗೆ, ಸರದಿಯಲ್ಲಿ ನಷ್ಟ ಕೌಂಟರ್‌ಗಳನ್ನು ಓದುವ ಮೂಲಕ ಇದನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುವುದಿಲ್ಲ).

TSDuck ಬಗ್ಗೆ ಬಹಳ ಸಂಕ್ಷಿಪ್ತವಾಗಿ

TSDuck ಎನ್ನುವುದು TS ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಕುಶಲತೆಯಿಂದ ನಿರ್ವಹಿಸಲು ಮುಕ್ತ ಮೂಲ (2-ಕ್ಲಾಸ್ BSD ಪರವಾನಗಿ) ಸಾಫ್ಟ್‌ವೇರ್ (ಕನ್ಸೋಲ್ ಉಪಯುಕ್ತತೆಗಳ ಒಂದು ಸೆಟ್ ಮತ್ತು ಕಸ್ಟಮ್ ಉಪಯುಕ್ತತೆಗಳು ಅಥವಾ ಪ್ಲಗಿನ್‌ಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಲೈಬ್ರರಿ). ಇನ್‌ಪುಟ್‌ನಂತೆ, ಇದು IP (ಮಲ್ಟಿಕಾಸ್ಟ್/ಯೂನಿಕಾಸ್ಟ್), http, hls, dvb ಟ್ಯೂನರ್‌ಗಳು, dektec dvb-asi demodulator ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು, ಆಂತರಿಕ TS-ಸ್ಟ್ರೀಮ್ ಜನರೇಟರ್ ಮತ್ತು ಫೈಲ್‌ಗಳಿಂದ ಓದುವಿಕೆ ಇದೆ. ಔಟ್‌ಪುಟ್ ಫೈಲ್, IP (ಮಲ್ಟಿಕಾಸ್ಟ್/ಯೂನಿಕಾಸ್ಟ್), hls, dektec dvb-asi ಮತ್ತು HiDes ಮಾಡ್ಯುಲೇಟರ್‌ಗಳು, ಪ್ಲೇಯರ್‌ಗಳು (mplayer, vlc, xine) ಮತ್ತು ಡ್ರಾಪ್‌ಗೆ ಬರೆಯಬಹುದು. ಇನ್‌ಪುಟ್ ಮತ್ತು ಔಟ್‌ಪುಟ್ ನಡುವೆ ವಿವಿಧ ಟ್ರಾಫಿಕ್ ಪ್ರೊಸೆಸರ್‌ಗಳನ್ನು ಸೇರಿಸಿಕೊಳ್ಳಬಹುದು, ಉದಾಹರಣೆಗೆ, PID ರೀಮ್ಯಾಪಿಂಗ್, ಸ್ಕ್ರಾಂಬ್ಲಿಂಗ್ / ಡಿಸ್ಕ್ರ್ಯಾಂಬ್ಲಿಂಗ್, CC ಕೌಂಟರ್ ವಿಶ್ಲೇಷಣೆ, ಬಿಟ್ರೇಟ್ ಲೆಕ್ಕಾಚಾರ ಮತ್ತು TS ಸ್ಟ್ರೀಮ್‌ಗಳಿಗಾಗಿ ಇತರ ವಿಶಿಷ್ಟ ಕಾರ್ಯಾಚರಣೆಗಳು.

ಈ ಲೇಖನದಲ್ಲಿ, ಐಪಿ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು (ಮಲ್ಟಿಕಾಸ್ಟ್) ಇನ್‌ಪುಟ್ ಆಗಿ ಬಳಸಲಾಗುತ್ತದೆ, ಪ್ರೊಸೆಸರ್‌ಗಳು ಬಿಟ್ರೇಟ್_ಮಾನಿಟರ್ (ಹೆಸರಿನಿಂದ ಅದು ಏನು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ) ಮತ್ತು ನಿರಂತರತೆ (ಸಿಸಿ ಕೌಂಟರ್‌ಗಳ ವಿಶ್ಲೇಷಣೆ) ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. TSDuck ಬೆಂಬಲಿಸುವ ಇನ್ನೊಂದು ಇನ್‌ಪುಟ್ ಪ್ರಕಾರದೊಂದಿಗೆ ನೀವು IP ಮಲ್ಟಿಕಾಸ್ಟ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಬದಲಾಯಿಸಬಹುದು.

ಇವೆ ಅಧಿಕೃತ ನಿರ್ಮಾಣಗಳು/ಪ್ಯಾಕೇಜುಗಳು ಹೆಚ್ಚಿನ ಪ್ರಸ್ತುತ ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಗಳಿಗೆ TSDuck. ಅವು ಡೆಬಿಯನ್‌ಗೆ ಲಭ್ಯವಿಲ್ಲ, ಆದರೆ ನಾವು ಅವುಗಳನ್ನು ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲದೆ ಡೆಬಿಯನ್ 8 ಮತ್ತು ಡೆಬಿಯನ್ 10 ಅಡಿಯಲ್ಲಿ ನಿರ್ಮಿಸಲು ನಿರ್ವಹಿಸುತ್ತಿದ್ದೇವೆ.

ಮುಂದೆ, ಆವೃತ್ತಿ TSDuck 3.19-1520 ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ, ಲಿನಕ್ಸ್ ಅನ್ನು OS ಆಗಿ ಬಳಸಲಾಗುತ್ತದೆ (ಪರಿಹಾರವನ್ನು ತಯಾರಿಸಲು debian 10 ಅನ್ನು ಬಳಸಲಾಗಿದೆ, CentOS 7 ಅನ್ನು ನೈಜ ಬಳಕೆಗಾಗಿ ಬಳಸಲಾಗಿದೆ)

TSDuck ಮತ್ತು OS ಅನ್ನು ಸಿದ್ಧಪಡಿಸಲಾಗುತ್ತಿದೆ

ನೈಜ ಹರಿವುಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ಮೊದಲು, TSDuck ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಕಾರ್ಡ್ ಅಥವಾ OS (ಸಾಕೆಟ್) ಮಟ್ಟದಲ್ಲಿ ಯಾವುದೇ ಹನಿಗಳಿಲ್ಲ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಅಥವಾ "ಸರ್ವರ್ ಒಳಗೆ" - ಹನಿಗಳು ಎಲ್ಲಿ ಸಂಭವಿಸಿದವು ಎಂಬುದನ್ನು ನಂತರ ಊಹಿಸದಿರಲು ಇದು ಅಗತ್ಯವಿದೆ. ನೀವು ethtool -S ethX ಕಮಾಂಡ್‌ನೊಂದಿಗೆ ನೆಟ್‌ವರ್ಕ್ ಕಾರ್ಡ್ ಮಟ್ಟದಲ್ಲಿ ಡ್ರಾಪ್‌ಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು, ಟ್ಯೂನಿಂಗ್ ಅನ್ನು ಅದೇ ethtool ನಿಂದ ಮಾಡಲಾಗುತ್ತದೆ (ಸಾಮಾನ್ಯವಾಗಿ, ನೀವು RX ಬಫರ್ (-G) ಅನ್ನು ಹೆಚ್ಚಿಸಬೇಕು ಮತ್ತು ಕೆಲವೊಮ್ಮೆ ಕೆಲವು ಆಫ್‌ಲೋಡ್‌ಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಕು (-K)). ಸಾಮಾನ್ಯ ಶಿಫಾರಸಿನಂತೆ, ವಿಶ್ಲೇಷಿಸಿದ ದಟ್ಟಣೆಯನ್ನು ಸ್ವೀಕರಿಸಲು ಪ್ರತ್ಯೇಕ ಪೋರ್ಟ್ ಅನ್ನು ಬಳಸಲು ಸಲಹೆ ನೀಡಬಹುದು, ಸಾಧ್ಯವಾದರೆ, ಇತರ ದಟ್ಟಣೆಯ ಉಪಸ್ಥಿತಿಯಿಂದಾಗಿ ವಿಶ್ಲೇಷಕ ಪೋರ್ಟ್‌ನಲ್ಲಿ ಡ್ರಾಪ್ ನಿಖರವಾಗಿ ಸಂಭವಿಸಿದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಸಂಬಂಧಿಸಿದ ತಪ್ಪು ಧನಾತ್ಮಕತೆಯನ್ನು ಇದು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಇದು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ (ಒಂದು ಪೋರ್ಟ್‌ನೊಂದಿಗೆ ಮಿನಿ-ಕಂಪ್ಯೂಟರ್/ಎನ್‌ಯುಸಿಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ), ನಂತರ ವಿಶ್ಲೇಷಕವನ್ನು ಸಂಪರ್ಕಿಸಿರುವ ಸಾಧನದಲ್ಲಿ ಉಳಿದವುಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ವಿಶ್ಲೇಷಿಸಿದ ದಟ್ಟಣೆಯ ಆದ್ಯತೆಯನ್ನು ಹೊಂದಿಸಲು ಇದು ಹೆಚ್ಚು ಅಪೇಕ್ಷಣೀಯವಾಗಿದೆ. ವರ್ಚುವಲ್ ಪರಿಸರಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ, ಇಲ್ಲಿ ನೀವು ಜಾಗರೂಕರಾಗಿರಬೇಕು ಮತ್ತು ಭೌತಿಕ ಪೋರ್ಟ್‌ನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ವರ್ಚುವಲ್ ಯಂತ್ರದೊಳಗಿನ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುವ ಪ್ಯಾಕೆಟ್ ಡ್ರಾಪ್‌ಗಳನ್ನು ಕಂಡುಹಿಡಿಯಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಹೋಸ್ಟ್ ಒಳಗೆ ಸ್ಟ್ರೀಮ್ನ ಉತ್ಪಾದನೆ ಮತ್ತು ಸ್ವಾಗತ

TSDuck ಅನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಮೊದಲ ಹಂತವಾಗಿ, ನಾವು netns ಅನ್ನು ಬಳಸಿಕೊಂಡು ಒಂದೇ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ ಮತ್ತು ಸ್ವೀಕರಿಸುತ್ತೇವೆ.

ಪರಿಸರವನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು:

ip netns add P #создаём netns P, в нём будет происходить анализ трафика
ip link add type veth #создаём veth-пару - veth0 оставляем в netns по умолчанию (в этот интерфейс будет генерироваться трафик)
ip link set dev veth1 netns P #veth1 - помещаем в netns P (на этом интерфейсе будет приём трафика)
ip netns exec P ifconfig veth1 192.0.2.1/30 up #поднимаем IP на veth1, не имеет значения какой именно
ip netns exec P ip ro add default via 192.0.2.2 #настраиваем маршрут по умолчанию внутри nents P
sysctl net.ipv6.conf.veth0.disable_ipv6=1 #отключаем IPv6 на veth0 - это делается для того, чтобы в счётчик TX не попадал посторонний мусор
ifconfig veth0 up #поднимаем интерфейс veth0
ip route add 239.0.0.1 dev veth0 #создаём маршрут, чтобы ОС направляла трафик к 239.0.0.1 в сторону veth0

ಪರಿಸರ ಸಿದ್ಧವಾಗಿದೆ. ನಾವು ಸಂಚಾರ ವಿಶ್ಲೇಷಕವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ:

ip netns exec P tsp --realtime -t 
 -I ip 239.0.0.1:1234 
 -P continuity 
 -P bitrate_monitor -p 1 -t 1 
 -O drop

ಅಲ್ಲಿ "-p 1 -t 1" ಎಂದರೆ ನೀವು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಬಿಟ್ರೇಟ್ ಅನ್ನು ಲೆಕ್ಕ ಹಾಕಬೇಕು ಮತ್ತು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಬಿಟ್ರೇಟ್ ಬಗ್ಗೆ ಮಾಹಿತಿಯನ್ನು ಪ್ರದರ್ಶಿಸಬೇಕು
ನಾವು 10Mbps ವೇಗದಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಜನರೇಟರ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ:

tsp -I craft 
 -P regulate -b 10000000 
 -O ip -p 7 -e --local-port 6000 239.0.0.1:1234

ಅಲ್ಲಿ "-p 7 -e" ಎಂದರೆ ನೀವು 7 TS ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು 1 IP ಪ್ಯಾಕೆಟ್‌ಗೆ ಪ್ಯಾಕ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹಾರ್ಡ್ (-e), ಅಂದರೆ. IP ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸುವ ಮೊದಲು ಯಾವಾಗಲೂ ಕೊನೆಯ ಪ್ರೊಸೆಸರ್‌ನಿಂದ 7 TS ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನಿರೀಕ್ಷಿಸಿ.

ವಿಶ್ಲೇಷಕವು ನಿರೀಕ್ಷಿತ ಸಂದೇಶಗಳನ್ನು ಔಟ್ಪುಟ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ:

* 2020/01/03 14:55:44 - bitrate_monitor: 2020/01/03 14:55:44, TS bitrate: 9,970,016 bits/s
* 2020/01/03 14:55:45 - bitrate_monitor: 2020/01/03 14:55:45, TS bitrate: 10,022,656 bits/s
* 2020/01/03 14:55:46 - bitrate_monitor: 2020/01/03 14:55:46, TS bitrate: 9,980,544 bits/s

ಈಗ ಕೆಲವು ಹನಿಗಳನ್ನು ಸೇರಿಸಿ:

ip netns exec P iptables -I INPUT -d 239.0.0.1 -m statistic --mode random --probability 0.001 -j DROP

ಮತ್ತು ಈ ರೀತಿಯ ಸಂದೇಶಗಳು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ:

* 2020/01/03 14:57:11 - continuity: packet index: 80,745, PID: 0x0000, missing 7 packets
* 2020/01/03 14:57:11 - continuity: packet index: 83,342, PID: 0x0000, missing 7 packets 

ನಿರೀಕ್ಷಿಸಲಾಗಿದೆ. ಪ್ಯಾಕೆಟ್ ನಷ್ಟವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ (ip netns exec P iptables -F) ಮತ್ತು ಜನರೇಟರ್ ಬಿಟ್ರೇಟ್ ಅನ್ನು 100Mbps ಗೆ ಹೆಚ್ಚಿಸಲು ಪ್ರಯತ್ನಿಸಿ. ವಿಶ್ಲೇಷಕವು ಸಿಸಿ ದೋಷಗಳ ಗುಂಪನ್ನು ಮತ್ತು 75 ರ ಬದಲಿಗೆ ಸುಮಾರು 100 Mbps ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಯಾರನ್ನು ದೂರುವುದು ಎಂದು ನಾವು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ - ಜನರೇಟರ್‌ಗೆ ಸಮಯವಿಲ್ಲ ಅಥವಾ ಸಮಸ್ಯೆ ಅದರಲ್ಲಿಲ್ಲ, ಇದಕ್ಕಾಗಿ ನಾವು ಸ್ಥಿರ ಸಂಖ್ಯೆಯನ್ನು ಉತ್ಪಾದಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ ಪ್ಯಾಕೆಟ್‌ಗಳು (700000 TS ಪ್ಯಾಕೆಟ್‌ಗಳು = 100000 IP ಪ್ಯಾಕೆಟ್‌ಗಳು):

# ifconfig veth0 | grep TX
       TX packets 151825460  bytes 205725459268 (191.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
# tsp -I craft -c 700000 -P regulate -b 100000000 -P count -O ip -p 7 -e --local-port 6000 239.0.0.1:1234
* count: PID    0 (0x0000):    700,000 packets
# ifconfig veth0 | grep TX
        TX packets 151925460  bytes 205861259268 (191.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ನೀವು ನೋಡುವಂತೆ, ನಿಖರವಾಗಿ 100000 IP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ (151925460-151825460). ಆದ್ದರಿಂದ ವಿಶ್ಲೇಷಕದೊಂದಿಗೆ ಏನಾಗುತ್ತಿದೆ ಎಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ, ಇದಕ್ಕಾಗಿ ನಾವು veth1 ನಲ್ಲಿ RX ಕೌಂಟರ್‌ನೊಂದಿಗೆ ಪರಿಶೀಲಿಸುತ್ತೇವೆ, ಇದು veth0 ನಲ್ಲಿ TX ಕೌಂಟರ್‌ಗೆ ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಸಮಾನವಾಗಿರುತ್ತದೆ, ನಂತರ ನಾವು ಸಾಕೆಟ್ ಮಟ್ಟದಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡುತ್ತೇವೆ:

# ip netns exec P cat /proc/net/udp                                                                                                           
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops             
  133: 010000EF:04D2 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 72338 2 00000000e0a441df 24355 

ಇಲ್ಲಿ ನೀವು ಡ್ರಾಪ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ನೋಡಬಹುದು = 24355. TS ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ, ಇದು 170485 ಅಥವಾ 24.36 ರಲ್ಲಿ 700000% ಆಗಿದೆ, ಆದ್ದರಿಂದ ಕಳೆದುಹೋದ ಬಿಟ್ರೇಟ್‌ನ ಅದೇ 25% ನಷ್ಟು udp ಸಾಕೆಟ್‌ನಲ್ಲಿ ಡ್ರಾಪ್‌ಗಳನ್ನು ನಾವು ನೋಡುತ್ತೇವೆ. UDP ಸಾಕೆಟ್‌ನಲ್ಲಿನ ಹನಿಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಬಫರ್ ಕೊರತೆಯಿಂದಾಗಿ ಸಂಭವಿಸುತ್ತವೆ, ಡೀಫಾಲ್ಟ್ ಸಾಕೆಟ್ ಬಫರ್ ಗಾತ್ರ ಮತ್ತು ಗರಿಷ್ಠ ಸಾಕೆಟ್ ಬಫರ್ ಗಾತ್ರವನ್ನು ನೋಡಿ:

# sysctl net.core.rmem_default
net.core.rmem_default = 212992
# sysctl net.core.rmem_max
net.core.rmem_max = 212992

ಹೀಗಾಗಿ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಬಫರ್ ಗಾತ್ರವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ವಿನಂತಿಸದಿದ್ದರೆ, ಸಾಕೆಟ್‌ಗಳನ್ನು 208 KB ಬಫರ್‌ನೊಂದಿಗೆ ರಚಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅವರು ಹೆಚ್ಚಿನದನ್ನು ವಿನಂತಿಸಿದರೆ, ಅವರು ಇನ್ನೂ ವಿನಂತಿಸಿದ್ದನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ. IP ಇನ್‌ಪುಟ್ (-ಬಫರ್-ಗಾತ್ರ) ಗಾಗಿ ನೀವು ಬಫರ್ ಗಾತ್ರವನ್ನು tsp ನಲ್ಲಿ ಹೊಂದಿಸಬಹುದಾದ ಕಾರಣ, ನಾವು ಡೀಫಾಲ್ಟ್ ಸಾಕೆಟ್ ಗಾತ್ರವನ್ನು ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ, ಆದರೆ ಗರಿಷ್ಠ ಸಾಕೆಟ್ ಬಫರ್ ಗಾತ್ರವನ್ನು ಮಾತ್ರ ಹೊಂದಿಸುತ್ತೇವೆ ಮತ್ತು tsp ಆರ್ಗ್ಯುಮೆಂಟ್‌ಗಳ ಮೂಲಕ ಬಫರ್ ಗಾತ್ರವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ:

sysctl net.core.rmem_max=8388608
ip netns exec P tsp --realtime -t -I ip 239.0.0.1:1234 -b 8388608 -P continuity -P bitrate_monitor -p 1 -t 1 -O drop

ಸಾಕೆಟ್ ಬಫರ್‌ನ ಈ ಟ್ಯೂನಿಂಗ್‌ನೊಂದಿಗೆ, ಈಗ ವರದಿ ಮಾಡಲಾದ ಬಿಟ್‌ರೇಟ್ ಸುಮಾರು 100Mbps ಆಗಿದೆ, ಯಾವುದೇ CC ದೋಷಗಳಿಲ್ಲ.

tsp ಅಪ್ಲಿಕೇಶನ್ ಸ್ವತಃ CPU ಬಳಕೆಯ ಪ್ರಕಾರ. ಒಂದು ಕೋರ್ i5-4260U CPU @ 1.40GHz ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ, 10Mbps ಹರಿವಿನ ವಿಶ್ಲೇಷಣೆಗೆ 3-4% CPU, 100Mbps - 25%, 200Mbps - 46% ಅಗತ್ಯವಿರುತ್ತದೆ. % ಪ್ಯಾಕೆಟ್ ನಷ್ಟವನ್ನು ಹೊಂದಿಸುವಾಗ, CPU ಮೇಲಿನ ಲೋಡ್ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಹೆಚ್ಚಾಗುವುದಿಲ್ಲ (ಆದರೆ ಕಡಿಮೆಯಾಗಬಹುದು).

ಹೆಚ್ಚು ಉತ್ಪಾದಕ ಯಂತ್ರಾಂಶದಲ್ಲಿ, ಯಾವುದೇ ತೊಂದರೆಗಳಿಲ್ಲದೆ 1Gb / s ಗಿಂತ ಹೆಚ್ಚಿನ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸಲು ಮತ್ತು ವಿಶ್ಲೇಷಿಸಲು ಸಾಧ್ಯವಾಯಿತು.

ನೈಜ ನೆಟ್‌ವರ್ಕ್ ಕಾರ್ಡ್‌ಗಳಲ್ಲಿ ಪರೀಕ್ಷೆ

ವೆಥ್ ಜೋಡಿಯನ್ನು ಪರೀಕ್ಷಿಸಿದ ನಂತರ, ನೀವು ಒಂದು ಹೋಸ್ಟ್‌ನ ಎರಡು ಹೋಸ್ಟ್‌ಗಳು ಅಥವಾ ಎರಡು ಪೋರ್ಟ್‌ಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬೇಕು, ಪೋರ್ಟ್‌ಗಳನ್ನು ಒಂದಕ್ಕೊಂದು ಸಂಪರ್ಕಿಸಬೇಕು, ಜನರೇಟರ್ ಅನ್ನು ಒಂದರಿಂದ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಎರಡನೆಯದರಲ್ಲಿ ವಿಶ್ಲೇಷಕ. ಇಲ್ಲಿ ಯಾವುದೇ ಆಶ್ಚರ್ಯಗಳು ಇರಲಿಲ್ಲ, ಆದರೆ ವಾಸ್ತವವಾಗಿ ಇದು ಎಲ್ಲಾ ಕಬ್ಬಿಣದ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ, ದುರ್ಬಲವಾಗಿರುತ್ತದೆ, ಅದು ಇಲ್ಲಿ ಹೆಚ್ಚು ಆಸಕ್ತಿಕರವಾಗಿರುತ್ತದೆ.

ಮಾನಿಟರಿಂಗ್ ಸಿಸ್ಟಮ್ (ಝಬ್ಬಿಕ್ಸ್) ಮೂಲಕ ಸ್ವೀಕರಿಸಿದ ಡೇಟಾವನ್ನು ಬಳಸುವುದು

tsp SNMP ಅಥವಾ ಅಂತಹುದೇ ಯಾವುದೇ ಯಂತ್ರ-ಓದಬಲ್ಲ API ಅನ್ನು ಹೊಂದಿಲ್ಲ. CC ಸಂದೇಶಗಳನ್ನು ಕನಿಷ್ಠ 1 ಸೆಕೆಂಡ್‌ಗೆ ಒಟ್ಟುಗೂಡಿಸಬೇಕು (ಹೆಚ್ಚಿನ ಶೇಕಡಾವಾರು ಪ್ಯಾಕೆಟ್ ನಷ್ಟದೊಂದಿಗೆ, ಬಿಟ್‌ರೇಟ್ ಅನ್ನು ಅವಲಂಬಿಸಿ ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ನೂರಾರು/ಸಾವಿರ/ಹತ್ತಾರು ಸಾವಿರಗಳು ಇರಬಹುದು).

ಹೀಗಾಗಿ, ಮಾಹಿತಿಯನ್ನು ಉಳಿಸಲು ಮತ್ತು CC ದೋಷಗಳು ಮತ್ತು ಬಿಟ್ರೇಟ್ಗಾಗಿ ಗ್ರಾಫ್ಗಳನ್ನು ಸೆಳೆಯಲು ಮತ್ತು ಕೆಲವು ರೀತಿಯ ಅಪಘಾತಗಳನ್ನು ಮಾಡಲು, ಈ ಕೆಳಗಿನ ಆಯ್ಕೆಗಳು ಇರಬಹುದು:

1. tsp ನ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಪಾರ್ಸ್ ಮಾಡಿ ಮತ್ತು ಒಟ್ಟುಗೂಡಿಸಿ (CC ಮೂಲಕ), ಅಂದರೆ. ಅದನ್ನು ಬಯಸಿದ ರೂಪಕ್ಕೆ ಪರಿವರ್ತಿಸಿ.
2. tsp ಸ್ವತಃ ಮತ್ತು/ಅಥವಾ ಪ್ರೊಸೆಸರ್ ಪ್ಲಗಿನ್‌ಗಳನ್ನು bitrate_monitor ಮತ್ತು ನಿರಂತರತೆಯನ್ನು ಮುಗಿಸಿ ಇದರಿಂದ ಫಲಿತಾಂಶವನ್ನು ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗೆ ಸೂಕ್ತವಾದ ಯಂತ್ರ-ಓದಬಲ್ಲ ರೂಪದಲ್ಲಿ ನೀಡಲಾಗುತ್ತದೆ.
3. tsduck ಲೈಬ್ರರಿಯ ಮೇಲೆ ನಿಮ್ಮ ಅರ್ಜಿಯನ್ನು ಬರೆಯಿರಿ.

ನಿಸ್ಸಂಶಯವಾಗಿ, ಪ್ರಯತ್ನದ ವಿಷಯದಲ್ಲಿ ಆಯ್ಕೆ 1 ಸುಲಭವಾಗಿದೆ, ವಿಶೇಷವಾಗಿ tsduck ಸ್ವತಃ ಕಡಿಮೆ-ಮಟ್ಟದ (ಆಧುನಿಕ ಮಾನದಂಡಗಳ ಮೂಲಕ) ಭಾಷೆಯಲ್ಲಿ (C ++) ಬರೆಯಲಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಿ.

10Mbps ಸ್ಟ್ರೀಮ್ ಮತ್ತು 50% ಪ್ಯಾಕೆಟ್ ನಷ್ಟದಲ್ಲಿ (ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ), ಬ್ಯಾಷ್ ಪ್ರಕ್ರಿಯೆಯು tsp ಪ್ರಕ್ರಿಯೆಗಿಂತ 3-4 ಪಟ್ಟು ಹೆಚ್ಚು CPU ಅನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಸರಳವಾದ ಬ್ಯಾಷ್ ಪಾರ್ಸರ್ + ಅಗ್ರಿಗೇಟರ್ ಮೂಲಮಾದರಿಯು ತೋರಿಸಿದೆ. ಈ ಸನ್ನಿವೇಶವು ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲ. ವಾಸ್ತವವಾಗಿ ಈ ಮೂಲಮಾದರಿಯ ಒಂದು ತುಣುಕು ಕೆಳಗೆ

ಮೇಲ್ಭಾಗದಲ್ಲಿ ನೂಡಲ್ಸ್

#!/usr/bin/env bash

missingPackets=0
ccErrorSeconds=0
regexMissPackets='^* (.+) - continuity:.*missing ([0-9]+) packets$'
missingPacketsTime=""

ip netns exec P tsp --realtime -t -I ip -b 8388608 "239.0.0.1:1234" -O drop -P bitrate_monitor -p 1 -t 1  -P continuity 2>&1 | 
while read i
do
    #line example:* 2019/12/28 23:41:14 - continuity: packet index: 6,078, PID: 0x0100, missing 5 packets
    #line example 2: * 2019/12/28 23:55:11 - bitrate_monitor: 2019/12/28 23:55:11, TS bitrate: 4,272,864 bits/s
    if [[ "$i" == *continuity:* ]] 
    then
        if [[ "$i" =~ $regexMissPackets ]]
        then
            missingPacketsTimeNew="${BASH_REMATCH[1]}" #timestamp (seconds)
            if [[ "$missingPacketsTime" != "$missingPacketsTimeNew" ]] #new second with CC error
            then
                ((ccErrorSeconds += 1))
            fi
            missingPacketsTime=$missingPacketsTimeNew
            packets=${BASH_REMATCH[2]} #TS missing packets
            ((missingPackets += packets))
        fi
    elif [[ "$i" == *bitrate_monitor:* ]]
    then
        : #...
    fi
done

ಸ್ವೀಕಾರಾರ್ಹವಲ್ಲದ ನಿಧಾನಗತಿಯ ಜೊತೆಗೆ, ಬ್ಯಾಷ್‌ನಲ್ಲಿ ಯಾವುದೇ ಸಾಮಾನ್ಯ ಥ್ರೆಡ್‌ಗಳಿಲ್ಲ, ಬ್ಯಾಷ್ ಕೆಲಸಗಳು ಪ್ರತ್ಯೇಕ ಪ್ರಕ್ರಿಯೆಗಳಾಗಿವೆ ಮತ್ತು ನಾನು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಬರುವ ಬಿಟ್ರೇಟ್ ಸಂದೇಶಗಳನ್ನು ಸ್ವೀಕರಿಸುವಾಗ ಅಡ್ಡ ಪರಿಣಾಮದ ಮೇಲೆ ಮಿಸ್ಸಿಂಗ್ ಪ್ಯಾಕೆಟ್‌ಗಳ ಮೌಲ್ಯವನ್ನು ಸೆಕೆಂಡಿಗೆ ಒಮ್ಮೆ ಬರೆಯಬೇಕಾಗಿತ್ತು. ಪರಿಣಾಮವಾಗಿ, ಬ್ಯಾಷ್ ಏಕಾಂಗಿಯಾಗಿ ಉಳಿದಿದೆ ಮತ್ತು ಗೋಲಾಂಗ್‌ನಲ್ಲಿ ಹೊದಿಕೆಯನ್ನು (ಪಾರ್ಸರ್ + ಅಗ್ರಿಗೇಟರ್) ಬರೆಯಲು ನಿರ್ಧರಿಸಲಾಯಿತು. ಇದೇ ರೀತಿಯ ಗೋಲಾಂಗ್ ಕೋಡ್‌ನ CPU ಬಳಕೆಯು tsp ಪ್ರಕ್ರಿಯೆಗಿಂತ 4-5 ಪಟ್ಟು ಕಡಿಮೆಯಾಗಿದೆ. ಗೋಲಾಂಗ್ನೊಂದಿಗೆ ಬ್ಯಾಷ್ ಅನ್ನು ಬದಲಿಸುವುದರಿಂದ ಹೊದಿಕೆಯ ವೇಗವು ಸುಮಾರು 16 ಬಾರಿ ಹೊರಹೊಮ್ಮಿತು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಫಲಿತಾಂಶವು ಸ್ವೀಕಾರಾರ್ಹವಾಗಿದೆ (ಕೆಟ್ಟ ಸಂದರ್ಭದಲ್ಲಿ 25% ರಷ್ಟು CPU ಓವರ್ಹೆಡ್). ಗೋಲಾಂಗ್ ಮೂಲ ಫೈಲ್ ಇದೆ ಇಲ್ಲಿ.

ಹೊದಿಕೆಯನ್ನು ರನ್ ಮಾಡಿ

ಹೊದಿಕೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು, systemd ಗಾಗಿ ಸರಳವಾದ ಸೇವಾ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ತಯಾರಿಸಲಾಯಿತು (ಇಲ್ಲಿ) ಹೊದಿಕೆಯನ್ನು ಸ್ವತಃ ಬೈನರಿ ಫೈಲ್ ಆಗಿ ಕಂಪೈಲ್ ಮಾಡಲಾಗುವುದು (go build tsduck-stat.go) /opt/tsduck-stat/ ನಲ್ಲಿ ಇದೆ. ನೀವು ಏಕತಾನತೆಯ ಗಡಿಯಾರ (>=1.9) ಬೆಂಬಲದೊಂದಿಗೆ ಗೋಲಾಂಗ್ ಅನ್ನು ಬಳಸುತ್ತಿರುವಿರಿ ಎಂದು ಊಹಿಸಲಾಗಿದೆ.

ಸೇವೆಯ ನಿದರ್ಶನವನ್ನು ರಚಿಸಲು, ನೀವು systemctl ಸಕ್ರಿಯಗೊಳಿಸುವ ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸಬೇಕು [ಇಮೇಲ್ ರಕ್ಷಿಸಲಾಗಿದೆ]:1234 ನಂತರ systemctl ಪ್ರಾರಂಭದೊಂದಿಗೆ ರನ್ ಮಾಡಿ [ಇಮೇಲ್ ರಕ್ಷಿಸಲಾಗಿದೆ]: 1234.

Zabbix ನಿಂದ ಅನ್ವೇಷಣೆ

ಚಾಲನೆಯಲ್ಲಿರುವ ಸೇವೆಗಳನ್ನು ಅನ್ವೇಷಿಸಲು Zabbix ಗಾಗಿ, ಇದನ್ನು ಮಾಡಲಾಗುತ್ತದೆ ಗುಂಪು ಪಟ್ಟಿ ಜನರೇಟರ್ (discovery.sh), Zabbix ಅನ್ವೇಷಣೆಗೆ ಅಗತ್ಯವಿರುವ ಸ್ವರೂಪದಲ್ಲಿ, ಅದು ಅದೇ ಸ್ಥಳದಲ್ಲಿ ಇದೆ ಎಂದು ಊಹಿಸಲಾಗಿದೆ - /opt/tsduck-stat. zabbix-agent ಮೂಲಕ ಅನ್ವೇಷಣೆಯನ್ನು ಚಲಾಯಿಸಲು, ನೀವು ಸೇರಿಸುವ ಅಗತ್ಯವಿದೆ .conf ಫೈಲ್ ಬಳಕೆದಾರ ನಿಯತಾಂಕವನ್ನು ಸೇರಿಸಲು zabbix-ಏಜೆಂಟ್ ಕಾನ್ಫಿಗರೇಶನ್ ಡೈರೆಕ್ಟರಿಗೆ.

Zabbix ಟೆಂಪ್ಲೇಟ್

ಟೆಂಪ್ಲೇಟ್ ರಚಿಸಲಾಗಿದೆ (tsduck_stat_template.xml) ಸ್ವಯಂ ಅನ್ವೇಷಣೆ ನಿಯಮ, ಐಟಂ ಮೂಲಮಾದರಿಗಳು, ಗ್ರಾಫ್‌ಗಳು ಮತ್ತು ಟ್ರಿಗ್ಗರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ.

ಸಂಕ್ಷಿಪ್ತ ಪರಿಶೀಲನಾಪಟ್ಟಿ (ಸರಿ, ಯಾರಾದರೂ ಅದನ್ನು ಬಳಸಲು ನಿರ್ಧರಿಸಿದರೆ ಏನು)

1. "ಆದರ್ಶ" ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ tsp ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಬಿಡುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ (ಜನರೇಟರ್ ಮತ್ತು ವಿಶ್ಲೇಷಕವನ್ನು ನೇರವಾಗಿ ಸಂಪರ್ಕಿಸಲಾಗಿದೆ), ಹನಿಗಳು ಇದ್ದರೆ, ಪ್ಯಾರಾಗ್ರಾಫ್ 2 ಅಥವಾ ಈ ವಿಷಯದ ಕುರಿತು ಲೇಖನದ ಪಠ್ಯವನ್ನು ನೋಡಿ.
2. ಗರಿಷ್ಠ ಸಾಕೆಟ್ ಬಫರ್ ಅನ್ನು ಟ್ಯೂನಿಂಗ್ ಮಾಡಿ (net.core.rmem_max=8388608).
3. tsduck-stat.go ಅನ್ನು ಕಂಪೈಲ್ ಮಾಡಿ (ಬಿಲ್ಡ್ tsduck-stat.go).
4. ಸೇವಾ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು /lib/systemd/system ನಲ್ಲಿ ಹಾಕಿ.
5. systemctl ನೊಂದಿಗೆ ಸೇವೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿ, ಕೌಂಟರ್‌ಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಲು ಪ್ರಾರಂಭಿಸಿವೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ (grep "" /dev/shm/tsduck-stat/*). ಮಲ್ಟಿಕಾಸ್ಟ್ ಸ್ಟ್ರೀಮ್‌ಗಳ ಸಂಖ್ಯೆಯಿಂದ ಸೇವೆಗಳ ಸಂಖ್ಯೆ. ಇಲ್ಲಿ ನೀವು ಮಲ್ಟಿಕಾಸ್ಟ್ ಗುಂಪಿಗೆ ಒಂದು ಮಾರ್ಗವನ್ನು ರಚಿಸಬೇಕಾಗಬಹುದು, ಬಹುಶಃ rp_filter ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ಅಥವಾ ಮೂಲ ip ಗೆ ಮಾರ್ಗವನ್ನು ರಚಿಸಿ.
6. Discovery.sh ಅನ್ನು ರನ್ ಮಾಡಿ, ಅದು json ಅನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ.
7. Zabbix ಏಜೆಂಟ್ ಸಂರಚನೆಯನ್ನು ಸೇರಿಸಿ, zabbix ಏಜೆಂಟ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ.
8. ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು zabbix ಗೆ ಅಪ್‌ಲೋಡ್ ಮಾಡಿ, ಅದನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲಾಗುತ್ತಿರುವ ಹೋಸ್ಟ್‌ಗೆ ಅನ್ವಯಿಸಿ ಮತ್ತು zabbix-ಏಜೆಂಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ, ಸುಮಾರು 5 ನಿಮಿಷ ಕಾಯಿರಿ, ಹೊಸ ಐಟಂಗಳು, ಗ್ರಾಫ್‌ಗಳು ಮತ್ತು ಟ್ರಿಗ್ಗರ್‌ಗಳು ಇವೆಯೇ ಎಂದು ನೋಡಿ.

ಪರಿಣಾಮವಾಗಿ

ಪ್ಯಾಕೆಟ್ ನಷ್ಟವನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಕಾರ್ಯಕ್ಕಾಗಿ, ಇದು ಬಹುತೇಕ ಸಾಕಾಗುತ್ತದೆ, ಕನಿಷ್ಠ ಇದು ಯಾವುದೇ ಮೇಲ್ವಿಚಾರಣೆಗಿಂತ ಉತ್ತಮವಾಗಿದೆ.

ವಾಸ್ತವವಾಗಿ, ವೀಡಿಯೊ ತುಣುಕುಗಳನ್ನು ವಿಲೀನಗೊಳಿಸುವಾಗ ಸಿಸಿ “ನಷ್ಟಗಳು” ಸಂಭವಿಸಬಹುದು (ನನಗೆ ತಿಳಿದಿರುವಂತೆ, ರಷ್ಯಾದ ಒಕ್ಕೂಟದ ಸ್ಥಳೀಯ ಟಿವಿ ಕೇಂದ್ರಗಳಲ್ಲಿ ಒಳಸೇರಿಸುವಿಕೆಯನ್ನು ಹೀಗೆ ಮಾಡಲಾಗುತ್ತದೆ, ಅಂದರೆ ಸಿಸಿ ಕೌಂಟರ್ ಅನ್ನು ಮರು ಲೆಕ್ಕಾಚಾರ ಮಾಡದೆ), ಇದನ್ನು ನೆನಪಿನಲ್ಲಿಡಬೇಕು. ಸ್ವಾಮ್ಯದ ಪರಿಹಾರಗಳು SCTE-35 ಲೇಬಲ್‌ಗಳನ್ನು ಪತ್ತೆಹಚ್ಚುವ ಮೂಲಕ ಈ ಸಮಸ್ಯೆಯನ್ನು ಭಾಗಶಃ ತಪ್ಪಿಸುತ್ತವೆ (ಸ್ಟ್ರೀಮ್ ಜನರೇಟರ್‌ನಿಂದ ಸೇರಿಸಿದರೆ).

ಸಾರಿಗೆ ಗುಣಮಟ್ಟದ ಮಾನಿಟರಿಂಗ್ ವಿಷಯದಲ್ಲಿ, ಜಿಟ್ಟರ್ ಮಾನಿಟರಿಂಗ್ (ಐಎಟಿ) ಕೊರತೆಯಿದೆ. ಟಿವಿ ಉಪಕರಣಗಳು (ಅದು ಮಾಡ್ಯುಲೇಟರ್‌ಗಳು ಅಥವಾ ಅಂತಿಮ ಸಾಧನಗಳಾಗಿರಬಹುದು) ಈ ಪ್ಯಾರಾಮೀಟರ್‌ಗೆ ಅಗತ್ಯತೆಗಳನ್ನು ಹೊಂದಿದೆ ಮತ್ತು ಜಿಟ್‌ಬಫರ್ ಅನ್ನು ಅನಂತಕ್ಕೆ ಹೆಚ್ಚಿಸುವುದು ಯಾವಾಗಲೂ ಸಾಧ್ಯವಿಲ್ಲ. ಮತ್ತು ದೊಡ್ಡ ಬಫರ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಉಪಕರಣಗಳನ್ನು ಸಾರಿಗೆಯಲ್ಲಿ ಬಳಸಿದಾಗ ಮತ್ತು QoS ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡದಿದ್ದಾಗ ಅಥವಾ ಅಂತಹ ನೈಜ-ಸಮಯದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ರವಾನಿಸಲು ಸಾಕಷ್ಟು ಕಾನ್ಫಿಗರ್ ಮಾಡದಿದ್ದಾಗ ದಿಗ್ಭ್ರಮೆಯು ತೇಲುತ್ತದೆ.

ಮೂಲ: www.habr.com