IP(TS) ਵਹਾਅ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ TSDuck ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਅੱਜ, ਉਦਾਹਰਨ ਲਈ, IP(TS) ਦੇ ਪ੍ਰਵਾਹ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤੇ (ਮਾਲਕੀਅਤ) ਹੱਲ ਹਨ VB и iQ, ਉਹਨਾਂ ਕੋਲ ਫੰਕਸ਼ਨਾਂ ਦਾ ਕਾਫ਼ੀ ਅਮੀਰ ਸਮੂਹ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਟੀਵੀ ਸੇਵਾਵਾਂ ਨਾਲ ਕੰਮ ਕਰਨ ਵਾਲੇ ਵੱਡੇ ਓਪਰੇਟਰਾਂ ਕੋਲ ਸਮਾਨ ਹੱਲ ਹੁੰਦੇ ਹਨ। ਇਹ ਲੇਖ ਇੱਕ ਓਪਨ ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਹੱਲ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ TSDuck, CC (ਨਿਰੰਤਰਤਾ ਕਾਊਂਟਰ) ਕਾਊਂਟਰ ਅਤੇ ਬਿੱਟਰੇਟ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ IP(TS) ਵਹਾਅ ਦੇ ਨਿਊਨਤਮ ਨਿਯੰਤਰਣ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਇੱਕ ਸੰਭਾਵਿਤ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਲੀਜ਼ਡ L2 ਚੈਨਲ ਦੁਆਰਾ ਪੈਕਟਾਂ ਦੇ ਨੁਕਸਾਨ ਜਾਂ ਪੂਰੇ ਪ੍ਰਵਾਹ ਦੀ ਨਿਗਰਾਨੀ ਕਰ ਰਹੀ ਹੈ (ਜਿਸ ਦੀ ਆਮ ਤੌਰ 'ਤੇ ਨਿਗਰਾਨੀ ਨਹੀਂ ਕੀਤੀ ਜਾ ਸਕਦੀ, ਉਦਾਹਰਨ ਲਈ, ਕਤਾਰਾਂ ਵਿੱਚ ਨੁਕਸਾਨ ਦੇ ਕਾਊਂਟਰਾਂ ਨੂੰ ਪੜ੍ਹ ਕੇ)।

TSDuck ਬਾਰੇ ਬਹੁਤ ਸੰਖੇਪ ਵਿੱਚ

TSDuck ਇੱਕ ਓਪਨ ਸੋਰਸ (2-ਕਲਾਜ਼ BSD ਲਾਇਸੈਂਸ) ਸੌਫਟਵੇਅਰ ਹੈ (ਕੰਸੋਲ ਉਪਯੋਗਤਾਵਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਅਤੇ ਤੁਹਾਡੀਆਂ ਆਪਣੀਆਂ ਉਪਯੋਗਤਾਵਾਂ ਜਾਂ ਪਲੱਗਇਨਾਂ ਨੂੰ ਵਿਕਸਤ ਕਰਨ ਲਈ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ) TS ਸਟ੍ਰੀਮਾਂ ਨੂੰ ਹੇਰਾਫੇਰੀ ਕਰਨ ਲਈ। ਇੱਕ ਇੰਪੁੱਟ ਦੇ ਰੂਪ ਵਿੱਚ, ਇਹ IP (ਮਲਟੀਕਾਸਟ/ਯੂਨੀਕਾਸਟ), http, hls, dvb ਟਿਊਨਰ, dektec dvb-asi demodulator ਨਾਲ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਇੱਕ ਅੰਦਰੂਨੀ TS ਸਟ੍ਰੀਮ ਜਨਰੇਟਰ ਹੈ ਅਤੇ ਫਾਈਲਾਂ ਤੋਂ ਰੀਡਿੰਗ ਹੈ। ਆਉਟਪੁੱਟ ਇੱਕ ਫਾਈਲ, IP (ਮਲਟੀਕਾਸਟ/ਯੂਨੀਕਾਸਟ), hls, dektec dvb-asi ਅਤੇ HiDes ਮੋਡਿਊਲੇਟਰ, ਪਲੇਅਰ (mplayer, vlc, xine) ਅਤੇ ਡ੍ਰੌਪ ਲਈ ਰਿਕਾਰਡਿੰਗ ਹੋ ਸਕਦੀ ਹੈ। ਇਨਪੁਟ ਅਤੇ ਆਉਟਪੁੱਟ ਦੇ ਵਿਚਕਾਰ, ਤੁਸੀਂ ਵੱਖ-ਵੱਖ ਟ੍ਰੈਫਿਕ ਪ੍ਰੋਸੈਸਰਾਂ ਨੂੰ ਸਮਰੱਥ ਕਰ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਪੀਆਈਡੀ ਨੂੰ ਰੀਮੈਪ ਕਰਨਾ, ਸਕ੍ਰੈਂਬਲਿੰਗ/ਡੈਸਕ੍ਰੈਂਬਲਿੰਗ ਕਰਨਾ, ਸੀਸੀ ਕਾਊਂਟਰਾਂ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ, ਬਿੱਟਰੇਟ ਦੀ ਗਣਨਾ ਕਰਨਾ ਅਤੇ TS ਸਟ੍ਰੀਮਾਂ ਲਈ ਖਾਸ ਹੋਰ ਕਾਰਵਾਈਆਂ।

ਇਸ ਲੇਖ ਵਿੱਚ, IP ਸਟ੍ਰੀਮਜ਼ (ਮਲਟੀਕਾਸਟ) ਨੂੰ ਇਨਪੁਟ ਦੇ ਤੌਰ 'ਤੇ ਵਰਤਿਆ ਜਾਵੇਗਾ, ਬਿੱਟਰੇਟ_ਮੋਨੀਟਰ ਪ੍ਰੋਸੈਸਰ (ਨਾਮ ਤੋਂ ਇਹ ਸਪੱਸ਼ਟ ਹੈ ਕਿ ਇਹ ਕੀ ਹੈ) ਅਤੇ ਨਿਰੰਤਰਤਾ (CC ਕਾਊਂਟਰ ਵਿਸ਼ਲੇਸ਼ਣ) ਪ੍ਰੋਸੈਸਰਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਵੇਗੀ। ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ, ਤੁਸੀਂ IP ਮਲਟੀਕਾਸਟ ਨੂੰ TSDuck ਦੁਆਰਾ ਸਮਰਥਿਤ ਕਿਸੇ ਹੋਰ ਇਨਪੁਟ ਕਿਸਮ ਨਾਲ ਬਦਲ ਸਕਦੇ ਹੋ।

ਉਪਲੱਬਧ ਅਧਿਕਾਰਤ ਬਿਲਡ/ਪੈਕੇਜ ਜ਼ਿਆਦਾਤਰ ਮੌਜੂਦਾ OS ਲਈ TSDuck. ਡੇਬੀਅਨ ਲਈ ਕੋਈ ਵੀ ਨਹੀਂ ਹੈ, ਪਰ ਅਸੀਂ ਉਨ੍ਹਾਂ ਨੂੰ ਡੇਬੀਅਨ 8 ਅਤੇ ਡੇਬੀਅਨ 10 ਲਈ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਕੰਪਾਇਲ ਕਰਨ ਵਿੱਚ ਕਾਮਯਾਬ ਰਹੇ।

ਅੱਗੇ, TSDuck ਸੰਸਕਰਣ 3.19-1520 ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ, ਲੀਨਕਸ ਨੂੰ OS ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ (ਡੈਬੀਅਨ 10 ਹੱਲ ਤਿਆਰ ਕਰਨ ਲਈ ਵਰਤਿਆ ਗਿਆ ਸੀ, CentOS 7 ਅਸਲ ਵਰਤੋਂ ਲਈ ਵਰਤਿਆ ਗਿਆ ਸੀ)

TSDuck ਅਤੇ OS ਦੀ ਤਿਆਰੀ

ਅਸਲ ਵਹਾਅ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ ਕਿ TSDuck ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਇਹ ਬੂੰਦਾਂ ਨੈੱਟਵਰਕ ਕਾਰਡ ਜਾਂ OS (ਸਾਕੇਟ) ਪੱਧਰ 'ਤੇ ਨਹੀਂ ਆਉਂਦੀਆਂ ਹਨ। ਇਹ ਇਸ ਲਈ ਲੋੜੀਂਦਾ ਹੈ ਤਾਂ ਜੋ ਤੁਹਾਨੂੰ ਬਾਅਦ ਵਿੱਚ ਇਹ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਦੀ ਲੋੜ ਨਾ ਪਵੇ ਕਿ ਬੂੰਦਾਂ ਕਿੱਥੇ ਆਈਆਂ - ਨੈੱਟਵਰਕ 'ਤੇ ਜਾਂ "ਸਰਵਰ ਦੇ ਅੰਦਰ।" ਤੁਸੀਂ ethtool -S ethX ਕਮਾਂਡ ਨਾਲ ਨੈੱਟਵਰਕ ਕਾਰਡ ਪੱਧਰ 'ਤੇ ਬੂੰਦਾਂ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ, ਟਿਊਨਿੰਗ ਉਸੇ ਈਥਟੂਲ ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਆਮ ਤੌਰ 'ਤੇ ਤੁਹਾਨੂੰ RX ਬਫਰ (-G) ਵਧਾਉਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕਈ ਵਾਰ ਕੁਝ ਔਫਲੋਡ (-K) ਨੂੰ ਅਸਮਰੱਥ ਬਣਾਉਣਾ ਹੁੰਦਾ ਹੈ)। ਇੱਕ ਆਮ ਸਿਫ਼ਾਰਸ਼ ਦੇ ਤੌਰ 'ਤੇ, ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੱਕ ਵੱਖਰੀ ਪੋਰਟ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ, ਜੇਕਰ ਸੰਭਵ ਹੋਵੇ, ਤਾਂ ਇਹ ਇਸ ਤੱਥ ਦੇ ਕਾਰਨ ਗਲਤ ਸਕਾਰਾਤਮਕਤਾ ਨੂੰ ਘੱਟ ਕਰੇਗਾ ਕਿ ਦੂਜੀ ਟ੍ਰੈਫਿਕ ਦੀ ਮੌਜੂਦਗੀ ਦੇ ਕਾਰਨ ਵਿਸ਼ਲੇਸ਼ਕ ਪੋਰਟ 'ਤੇ ਇੱਕੋ ਸਮੇਂ ਵਿੱਚ ਗਿਰਾਵਟ ਆਈ ਹੈ। ਜੇ ਇਹ ਸੰਭਵ ਨਹੀਂ ਹੈ (ਤੁਸੀਂ ਇੱਕ ਪੋਰਟ ਦੇ ਨਾਲ ਇੱਕ ਮਿੰਨੀ-ਕੰਪਿਊਟਰ/NUC ਵਰਤ ਰਹੇ ਹੋ), ਤਾਂ ਇਹ ਬਹੁਤ ਸਲਾਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਵਿਸ਼ਲੇਸ਼ਣ ਕੀਤੇ ਟ੍ਰੈਫਿਕ ਦੀ ਤਰਜੀਹ ਨੂੰ ਉਸ ਡਿਵਾਈਸ ਦੇ ਬਾਕੀ ਦੇ ਸਬੰਧ ਵਿੱਚ ਕੌਂਫਿਗਰ ਕਰੋ ਜਿਸ ਵਿੱਚ ਵਿਸ਼ਲੇਸ਼ਕ ਕਨੈਕਟ ਕੀਤਾ ਗਿਆ ਹੈ। ਵਰਚੁਅਲ ਵਾਤਾਵਰਨ ਦੇ ਸੰਬੰਧ ਵਿੱਚ, ਇੱਥੇ ਤੁਹਾਨੂੰ ਸਾਵਧਾਨ ਰਹਿਣ ਦੀ ਲੋੜ ਹੈ ਅਤੇ ਭੌਤਿਕ ਪੋਰਟ ਤੋਂ ਸ਼ੁਰੂ ਹੋ ਕੇ ਅਤੇ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਦੇ ਅੰਦਰ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਨਾਲ ਖਤਮ ਹੋਣ ਵਾਲੇ ਪੈਕੇਟ ਬੂੰਦਾਂ ਨੂੰ ਲੱਭਣ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਹੋਸਟ ਦੇ ਅੰਦਰ ਇੱਕ ਸਟ੍ਰੀਮ ਤਿਆਰ ਕਰਨਾ ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਨਾ

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" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਹਰ ਸਕਿੰਟ ਬਿੱਟਰੇਟ ਦੀ ਗਣਨਾ ਕਰਨ ਅਤੇ ਹਰ ਸਕਿੰਟ ਬਿੱਟਰੇਟ ਬਾਰੇ ਜਾਣਕਾਰੀ ਦਿਖਾਉਣ ਦੀ ਲੋੜ ਹੈ
ਅਸੀਂ 10 Mbit/s ਦੀ ਸਪੀਡ ਨਾਲ ਇੱਕ ਟ੍ਰੈਫਿਕ ਜਨਰੇਟਰ ਲਾਂਚ ਕਰਦੇ ਹਾਂ:

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) ਨੂੰ ਅਯੋਗ ਕਰਦੇ ਹਾਂ ਅਤੇ ਜਨਰੇਟਰ ਬਿੱਟਰੇਟ ਨੂੰ 100 Mbit/s ਤੱਕ ਵਧਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ। ਵਿਸ਼ਲੇਸ਼ਕ 75 ਦੀ ਬਜਾਏ CC ਗਲਤੀਆਂ ਅਤੇ ਲਗਭਗ 100 Mbit/s ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਇਹ ਪਤਾ ਲਗਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰ ਰਹੇ ਹਾਂ ਕਿ ਕੌਣ ਦੋਸ਼ੀ ਹੈ - ਜਨਰੇਟਰ ਚਾਲੂ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਸਮੱਸਿਆ ਇਸ ਵਿੱਚ ਨਹੀਂ ਹੈ, ਅਜਿਹਾ ਕਰਨ ਲਈ ਅਸੀਂ ਇੱਕ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹਾਂ। ਪੈਕੇਟਾਂ ਦੀ ਸਥਿਰ ਸੰਖਿਆ (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 ਬਫਰ ਨਾਲ ਬਣਾਏ ਜਾਂਦੇ ਹਨ, ਪਰ ਜੇਕਰ ਉਹ ਹੋਰ ਬੇਨਤੀ ਕਰਦੇ ਹਨ, ਤਾਂ ਵੀ ਉਹ ਪ੍ਰਾਪਤ ਨਹੀਂ ਕਰਨਗੇ ਜੋ ਉਹਨਾਂ ਨੇ ਬੇਨਤੀ ਕੀਤੀ ਹੈ। ਕਿਉਂਕਿ tsp ਵਿੱਚ ਤੁਸੀਂ IP ਇੰਪੁੱਟ (--buffer-size) ਲਈ ਬਫਰ ਸਾਈਜ਼ ਸੈਟ ਕਰ ਸਕਦੇ ਹੋ, ਅਸੀਂ ਡਿਫਾਲਟ ਸਾਕਟ ਸਾਈਜ਼ ਨੂੰ ਨਹੀਂ ਛੂਹਾਂਗੇ, ਪਰ ਸਿਰਫ ਵੱਧ ਤੋਂ ਵੱਧ ਸਾਕਟ ਬਫਰ ਸਾਈਜ਼ ਸੈੱਟ ਕਰਾਂਗੇ ਅਤੇ 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 ਦੇ ਸਬੰਧ ਵਿੱਚ, ਇੱਕ 10Mbit/s ਪ੍ਰਵਾਹ ਦਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨ ਲਈ, CPU ਦੇ 3-4% ਦੀ ਲੋੜ ਹੋਵੇਗੀ, 100Mbit/s - 25%, 200Mbit/s - 46%। ਜਦੋਂ % ਪੈਕੇਟ ਨੁਕਸਾਨ ਸੈੱਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ CPU ਲੋਡ ਅਮਲੀ ਤੌਰ 'ਤੇ ਨਹੀਂ ਵਧਦਾ (ਪਰ ਘਟ ਸਕਦਾ ਹੈ)।

ਵਧੇਰੇ ਉਤਪਾਦਕ ਹਾਰਡਵੇਅਰ 'ਤੇ, ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ 1Gb/s ਤੋਂ ਵੱਧ ਦੀਆਂ ਸਟ੍ਰੀਮਾਂ ਨੂੰ ਬਣਾਉਣਾ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰਨਾ ਸੰਭਵ ਸੀ।

ਅਸਲੀ ਨੈੱਟਵਰਕ ਕਾਰਡ 'ਤੇ ਟੈਸਟਿੰਗ

ਵੈਥ ਜੋੜਾ 'ਤੇ ਟੈਸਟ ਕਰਨ ਤੋਂ ਬਾਅਦ, ਤੁਹਾਨੂੰ ਇੱਕ ਹੋਸਟ ਦੇ ਦੋ ਹੋਸਟ ਜਾਂ ਦੋ ਪੋਰਟਾਂ ਲੈਣ ਦੀ ਲੋੜ ਹੈ, ਪੋਰਟਾਂ ਨੂੰ ਇੱਕ ਦੂਜੇ ਨਾਲ ਜੋੜਨਾ, ਇੱਕ 'ਤੇ ਜਨਰੇਟਰ ਚਲਾਉਣਾ, ਅਤੇ ਦੂਜੇ 'ਤੇ ਵਿਸ਼ਲੇਸ਼ਕ. ਇੱਥੇ ਕੋਈ ਹੈਰਾਨੀ ਨਹੀਂ ਸੀ, ਪਰ ਅਸਲ ਵਿੱਚ ਇਹ ਸਭ ਹਾਰਡਵੇਅਰ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਇਹ ਜਿੰਨਾ ਕਮਜ਼ੋਰ ਹੈ, ਓਨਾ ਹੀ ਦਿਲਚਸਪ ਹੋਵੇਗਾ.

ਮਾਨੀਟਰਿੰਗ ਸਿਸਟਮ (ਜ਼ੈਬਿਕਸ) ਦੁਆਰਾ ਪ੍ਰਾਪਤ ਕੀਤੇ ਡੇਟਾ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

tsp ਕੋਲ ਕੋਈ ਵੀ ਮਸ਼ੀਨ-ਪੜ੍ਹਨ ਯੋਗ API ਨਹੀਂ ਹੈ ਜਿਵੇਂ ਕਿ SNMP ਜਾਂ ਸਮਾਨ। CC ਸੁਨੇਹਿਆਂ ਨੂੰ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ 1 ਸਕਿੰਟ ਇਕੱਠੇ ਕੀਤੇ ਜਾਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ (ਪੈਕੇਟ ਦੇ ਨੁਕਸਾਨ ਦੀ ਉੱਚ ਪ੍ਰਤੀਸ਼ਤਤਾ ਦੇ ਨਾਲ, ਬਿੱਟਰੇਟ ਦੇ ਆਧਾਰ 'ਤੇ, ਸੈਂਕੜੇ/ਹਜ਼ਾਰਾਂ/ਹਜ਼ਾਰਾਂ ਪ੍ਰਤੀ ਸਕਿੰਟ ਹੋ ਸਕਦੇ ਹਨ)।

ਇਸ ਤਰ੍ਹਾਂ, ਜਾਣਕਾਰੀ ਨੂੰ ਬਚਾਉਣ ਅਤੇ CC ਗਲਤੀਆਂ ਅਤੇ ਬਿੱਟਰੇਟ ਲਈ ਗ੍ਰਾਫ ਖਿੱਚਣ ਅਤੇ ਹੋਰ ਦੁਰਘਟਨਾਵਾਂ ਕਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਕਲਪ ਹੋ ਸਕਦੇ ਹਨ:

1. tsp ਆਉਟਪੁੱਟ ਨੂੰ ਪਾਰਸ ਅਤੇ ਐਗਰੀਗੇਟ (CC ਦੁਆਰਾ) ਕਰੋ, i.e. ਇਸ ਨੂੰ ਲੋੜੀਂਦੇ ਰੂਪ ਵਿੱਚ ਬਦਲੋ.
2. tsp ਆਪਣੇ ਆਪ ਅਤੇ/ਜਾਂ bitrate_monitor ਅਤੇ ਨਿਰੰਤਰਤਾ ਪ੍ਰੋਸੈਸਰ ਪਲੱਗਇਨ ਸ਼ਾਮਲ ਕਰੋ ਤਾਂ ਕਿ ਨਤੀਜਾ ਨਿਗਰਾਨੀ ਪ੍ਰਣਾਲੀ ਲਈ ਢੁਕਵੇਂ ਮਸ਼ੀਨ-ਪੜ੍ਹਨ ਯੋਗ ਰੂਪ ਵਿੱਚ ਆਉਟਪੁੱਟ ਹੋਵੇ।
3. ਆਪਣੀ ਅਰਜ਼ੀ tsduck ਲਾਇਬ੍ਰੇਰੀ ਦੇ ਸਿਖਰ 'ਤੇ ਲਿਖੋ।

ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਲੇਬਰ ਦੀ ਲਾਗਤ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਵਿਕਲਪ 1 ਸਭ ਤੋਂ ਸਰਲ ਹੈ, ਖਾਸ ਤੌਰ 'ਤੇ ਇਹ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਕਿ tsduck ਆਪਣੇ ਆਪ ਨੂੰ ਇੱਕ ਘੱਟ-ਪੱਧਰ (ਆਧੁਨਿਕ ਮਿਆਰਾਂ ਦੁਆਰਾ) ਭਾਸ਼ਾ (C++) ਵਿੱਚ ਲਿਖਿਆ ਗਿਆ ਹੈ।

ਬੈਸ਼ ਵਿੱਚ ਇੱਕ ਪਾਰਸਰ + ਐਗਰੀਗੇਟਰ ਦੇ ਇੱਕ ਸਧਾਰਨ ਪ੍ਰੋਟੋਟਾਈਪ ਨੇ ਦਿਖਾਇਆ ਕਿ 10 Mbit/s ਦੇ ਇੱਕ ਪ੍ਰਵਾਹ ਅਤੇ 50% ਪੈਕੇਟ ਨੁਕਸਾਨ (ਸਭ ਤੋਂ ਮਾੜੀ ਸਥਿਤੀ) 'ਤੇ, bash ਪ੍ਰਕਿਰਿਆ ਨੇ 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

ਇਸ ਤੱਥ ਤੋਂ ਇਲਾਵਾ ਕਿ ਇਹ ਅਸਵੀਕਾਰਨਯੋਗ ਤੌਰ 'ਤੇ ਹੌਲੀ-ਹੌਲੀ ਕੰਮ ਕਰਦਾ ਹੈ, bash ਵਿੱਚ ਕੋਈ ਆਮ ਥ੍ਰੈੱਡ ਨਹੀਂ ਹਨ, bash ਨੌਕਰੀਆਂ ਸੁਤੰਤਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਨ ਅਤੇ ਮੈਨੂੰ ਸਾਈਡ ਇਫੈਕਟ (ਜਦੋਂ ਬਿੱਟਰੇਟ ਸੁਨੇਹੇ ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ ਜੋ ਹਰ ਸਕਿੰਟ ਵਿੱਚ ਆਉਂਦੇ ਹਨ) 'ਤੇ ਇੱਕ ਸਕਿੰਟ ਵਿੱਚ ਇੱਕ ਵਾਰ ਗੁੰਮ ਪੈਕੇਟ ਮੁੱਲ ਲਿਖਣਾ ਪੈਂਦਾ ਸੀ। ਨਤੀਜੇ ਵਜੋਂ, ਬਾਸ਼ ਨੂੰ ਇਕੱਲਾ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਅਤੇ ਗੋਲੰਗ ਵਿੱਚ ਇੱਕ ਰੈਪਰ (ਪਾਰਸਰ + ਐਗਰੀਗੇਟਰ) ਲਿਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਗਿਆ। ਗੋਲਾਂਗ ਵਿੱਚ ਸਮਾਨ ਕੋਡ ਦੀ CPU ਖਪਤ tsp ਪ੍ਰਕਿਰਿਆ ਤੋਂ 4-5 ਗੁਣਾ ਘੱਟ ਹੈ। ਬੈਸ਼ ਨੂੰ ਗੋਲੰਗ ਨਾਲ ਬਦਲ ਕੇ ਰੈਪਰ ਦਾ ਪ੍ਰਵੇਗ ਲਗਭਗ 16 ਗੁਣਾ ਸੀ ਅਤੇ ਕੁੱਲ ਮਿਲਾ ਕੇ ਨਤੀਜਾ ਸਵੀਕਾਰਯੋਗ ਹੈ (ਸਭ ਤੋਂ ਮਾੜੀ ਸਥਿਤੀ ਵਿੱਚ CPU ਓਵਰਹੈੱਡ 25%)। ਗੋਲੰਗ ਸਰੋਤ ਫਾਈਲ ਸਥਿਤ ਹੈ ਇੱਥੇ.

ਰੈਪਰ ਲਾਂਚ ਕੀਤਾ ਜਾ ਰਿਹਾ ਹੈ

ਰੈਪਰ ਨੂੰ ਲਾਂਚ ਕਰਨ ਲਈ, systemd ਲਈ ਇੱਕ ਸਧਾਰਨ ਸੇਵਾ ਟੈਂਪਲੇਟ ਬਣਾਇਆ ਗਿਆ ਸੀ (ਇੱਥੇ). ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਰੈਪਰ ਨੂੰ ਖੁਦ ਇੱਕ ਬਾਈਨਰੀ ਫਾਈਲ (go build tsduck-stat.go) ਵਿੱਚ ਕੰਪਾਇਲ ਕੀਤਾ ਗਿਆ ਹੈ, ਜੋ /opt/tsduck-stat/ ਵਿੱਚ ਸਥਿਤ ਹੈ। ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਗੋਲੰਗ ਦੀ ਵਰਤੋਂ ਮੋਨੋਟੋਨਿਕ ਕਲਾਕ ਸਪੋਰਟ (>=1.9) ਨਾਲ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

ਇੱਕ ਸੇਵਾ ਉਦਾਹਰਨ ਬਣਾਉਣ ਲਈ ਤੁਹਾਨੂੰ systemctl enable ਕਮਾਂਡ ਚਲਾਉਣ ਦੀ ਲੋੜ ਹੈ [ਈਮੇਲ ਸੁਰੱਖਿਅਤ]:1234, ਫਿਰ systemctl ਸਟਾਰਟ ਨਾਲ ਚਲਾਓ [ਈਮੇਲ ਸੁਰੱਖਿਅਤ]: 1234

ਜ਼ੈਬਿਕਸ ਤੋਂ ਖੋਜ

ਤਾਂ ਜੋ ਜ਼ੈਬਿਕਸ ਚੱਲ ਰਹੀਆਂ ਸੇਵਾਵਾਂ ਦੀ ਖੋਜ ਕਰ ਸਕੇ, ਸਮੂਹ ਸੂਚੀ ਜਨਰੇਟਰ (discovery.sh), Zabbix ਖੋਜ ਲਈ ਲੋੜੀਂਦੇ ਫਾਰਮੈਟ ਵਿੱਚ, ਇਹ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਕਿ ਇਹ ਉਸੇ ਥਾਂ 'ਤੇ ਸਥਿਤ ਹੈ - /opt/tsduck-stat ਵਿੱਚ। ਜ਼ੈਬਿਕਸ-ਏਜੰਟ ਦੁਆਰਾ ਖੋਜ ਨੂੰ ਚਲਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਜੋੜਨ ਦੀ ਲੋੜ ਹੈ .conf ਫਾਈਲ ਇੱਕ ਉਪਭੋਗਤਾ ਪੈਰਾਮੀਟਰ ਜੋੜਨ ਲਈ zabbix-agent ਸੰਰਚਨਾ ਨਾਲ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ.

ਜ਼ੈਬਿਕਸ ਟੈਮਪਲੇਟ

ਟੈਮਪਲੇਟ ਬਣਾਇਆ (tsduck_stat_template.xml) ਵਿੱਚ ਆਟੋਡਿਸਕਵਰੀ ਨਿਯਮ, ਤੱਤ, ਗ੍ਰਾਫ, ਅਤੇ ਟ੍ਰਿਗਰ ਪ੍ਰੋਟੋਟਾਈਪ ਸ਼ਾਮਲ ਹਨ।

ਇੱਕ ਛੋਟੀ ਚੈਕਲਿਸਟ (ਕੀ ਹੋਵੇਗਾ ਜੇਕਰ ਕੋਈ ਇਸਨੂੰ ਵਰਤਣ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ)

1. ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰੋ ਕਿ tsp "ਆਦਰਸ਼" ਸਥਿਤੀਆਂ (ਜਨਰੇਟਰ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਕ ਸਿੱਧੇ ਜੁੜੇ ਹੋਏ ਹਨ) ਦੇ ਅਧੀਨ ਪੈਕੇਟਾਂ ਨੂੰ ਨਹੀਂ ਛੱਡਦਾ, ਜੇਕਰ ਬੂੰਦਾਂ ਹਨ, ਤਾਂ ਪੁਆਇੰਟ 2 ਜਾਂ ਇਸ ਮਾਮਲੇ 'ਤੇ ਲੇਖ ਦਾ ਪਾਠ ਵੇਖੋ।
2. ਵੱਧ ਤੋਂ ਵੱਧ ਸਾਕਟ ਬਫਰ ਦੀ ਟਿਊਨਿੰਗ ਕਰੋ (net.core.rmem_max=8388608)।
3. ਕੰਪਾਇਲ tsduck-stat.go (go build tsduck-stat.go)।
4. ਸਰਵਿਸ ਟੈਂਪਲੇਟ ਨੂੰ /lib/systemd/system ਵਿੱਚ ਰੱਖੋ।
5. systemctl ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੇਵਾਵਾਂ ਸ਼ੁਰੂ ਕਰੋ, ਜਾਂਚ ਕਰੋ ਕਿ ਕਾਊਂਟਰ ਦਿਖਾਈ ਦੇਣ ਲੱਗੇ ਹਨ (grep "" /dev/shm/tsduck-stat/*)। ਮਲਟੀਕਾਸਟ ਸਟ੍ਰੀਮ ਦੀ ਸੰਖਿਆ ਦੁਆਰਾ ਸੇਵਾਵਾਂ ਦੀ ਸੰਖਿਆ। ਇੱਥੇ ਤੁਹਾਨੂੰ ਮਲਟੀਕਾਸਟ ਸਮੂਹ ਲਈ ਇੱਕ ਰੂਟ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ, ਸ਼ਾਇਦ rp_filter ਨੂੰ ਅਯੋਗ ਕਰੋ ਜਾਂ ਸਰੋਤ ip ਲਈ ਇੱਕ ਰੂਟ ਬਣਾਓ।
6. Discovery.sh ਚਲਾਓ, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ json ਤਿਆਰ ਕਰਦਾ ਹੈ।
7. ਜ਼ੈਬਿਕਸ ਏਜੰਟ ਸੰਰਚਨਾ ਰੱਖੋ, ਜ਼ੈਬਿਕਸ ਏਜੰਟ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰੋ।
8. ਟੈਂਪਲੇਟ ਨੂੰ ਜ਼ੈਬਿਕਸ 'ਤੇ ਅਪਲੋਡ ਕਰੋ, ਇਸ ਨੂੰ ਹੋਸਟ 'ਤੇ ਲਾਗੂ ਕਰੋ ਜਿਸ 'ਤੇ ਨਿਗਰਾਨੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਜ਼ੈਬਿਕਸ-ਏਜੰਟ ਸਥਾਪਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਲਗਭਗ 5 ਮਿੰਟ ਉਡੀਕ ਕਰੋ, ਦੇਖੋ ਕਿ ਨਵੇਂ ਡੇਟਾ ਤੱਤ, ਗ੍ਰਾਫ ਅਤੇ ਟਰਿਗਰ ਦਿਖਾਈ ਦਿੱਤੇ ਹਨ।

ਇਸ ਦਾ ਨਤੀਜਾ

ਪੈਕੇਟ ਦੇ ਨੁਕਸਾਨ ਦੀ ਪਛਾਣ ਕਰਨ ਦੇ ਕੰਮ ਲਈ, ਇਹ ਲਗਭਗ ਕਾਫ਼ੀ ਹੈ, ਘੱਟੋ ਘੱਟ ਇਹ ਬਿਨਾਂ ਨਿਗਰਾਨੀ ਤੋਂ ਬਿਹਤਰ ਹੈ.

ਵਾਸਤਵ ਵਿੱਚ, CC "ਨੁਕਸਾਨ" ਉਦੋਂ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਵਿਡੀਓ ਦੇ ਟੁਕੜਿਆਂ ਨੂੰ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ (ਜਿੱਥੋਂ ਤੱਕ ਮੈਨੂੰ ਪਤਾ ਹੈ, ਰੂਸੀ ਫੈਡਰੇਸ਼ਨ ਵਿੱਚ ਸਥਾਨਕ ਟੈਲੀਵਿਜ਼ਨ ਕੇਂਦਰਾਂ ਵਿੱਚ ਇਸ ਤਰ੍ਹਾਂ ਸੰਮਿਲਨ ਕੀਤੇ ਜਾਂਦੇ ਹਨ, ਭਾਵ CC ਕਾਊਂਟਰ ਦੀ ਮੁੜ ਗਣਨਾ ਕੀਤੇ ਬਿਨਾਂ), ਇਸ ਨੂੰ ਯਾਦ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ। ਮਲਕੀਅਤ ਦੇ ਹੱਲਾਂ ਵਿੱਚ, ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਅੰਸ਼ਕ ਤੌਰ 'ਤੇ SCTE-35 ਟੈਗਸ (ਜੇ ਉਹ ਸਟ੍ਰੀਮ ਜਨਰੇਟਰ ਦੁਆਰਾ ਜੋੜਿਆ ਗਿਆ ਹੈ) ਦਾ ਪਤਾ ਲਗਾ ਕੇ ਰੋਕਿਆ ਜਾਂਦਾ ਹੈ।

ਆਵਾਜਾਈ ਦੀ ਗੁਣਵੱਤਾ ਦੀ ਨਿਗਰਾਨੀ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਜਿਟਰ ਨਿਗਰਾਨੀ (ਆਈਏਟੀ) ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਟੀਵੀ ਸਾਜ਼ੋ-ਸਾਮਾਨ (ਭਾਵੇਂ ਮੋਡਿਊਲੇਟਰ ਜਾਂ ਅੰਤਮ ਉਪਕਰਣ) ਲਈ ਇਸ ਪੈਰਾਮੀਟਰ ਲਈ ਲੋੜਾਂ ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਜੀਤਬਫਰ ਨੂੰ ਅਣਮਿੱਥੇ ਸਮੇਂ ਲਈ ਵਧਾਉਣਾ ਹਮੇਸ਼ਾ ਸੰਭਵ ਨਹੀਂ ਹੁੰਦਾ। ਅਤੇ ਜਿਟਰ ਫਲੋਟ ਹੋ ਸਕਦਾ ਹੈ ਜਦੋਂ ਟ੍ਰਾਂਜ਼ਿਟ ਵੱਡੇ ਬਫਰਾਂ ਵਾਲੇ ਸਾਜ਼ੋ-ਸਾਮਾਨ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ ਅਤੇ QoS ਨੂੰ ਸੰਰਚਿਤ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ ਜਾਂ ਅਜਿਹੇ ਰੀਅਲਟਾਈਮ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੰਚਾਰਿਤ ਕਰਨ ਲਈ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੌਂਫਿਗਰ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਹੈ।

ਸਰੋਤ: www.habr.com