VPN ਕਾਲ ਵਿੱਚ ਜਿਟਰ ਅਤੇ ਪੈਕਟ ਲੌਸ: ਕੀ ਤੁਲਨਾ ਕਰੀਏ
ਦੇਰ ਨਾਲ ਪਰ ਸੁਚਾਰੂ ਬੋਲੀ ਅਤੇ ਖਾਲੀ ਥਾਵਾਂ ਵਿੱਚ ਟੁੱਟਣ ਵਾਲੀ ਬੋਲੀ ਦੋ ਵੱਖਰੇ ਨੁਕਸ ਹਨ। ਐਪ ਦੇ ਆਪਣੇ ਅੰਕੜੇ, ਸਥਾਨਕ ਰੇਡੀਓ ਅਤੇ ਇੱਕ ਭਾਰਾ ਹੋਇਆ ਰਾਹ ਤੁਲਨਾ ਕਰੋ।
ਰੋਬੋਟ ਵਰਗੀ ਬੋਲੀ ਅਤੇ ਡਿੱਗੇ ਹੋਏ ਉਚਾਰਨ ਵੱਖਰੇ ਸੁਣਾਈ ਦਿੰਦੇ ਹਨ ਕਿਉਂਕਿ ਇਹ ਵੱਖਰੇ ਨੁਕਸ ਹਨ। ਜਿਟਰ ਬਦਲਦਾ ਹੈ ਕਿ ਪੈਕਟ ਕਦੋਂ ਆਉਂਦੇ ਹਨ; ਲੌਸ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਉਹ ਬਿਲਕੁਲ ਨਹੀਂ ਆਉਂਦੇ। ਦੋਵੇਂ ਤਦ ਹੋ ਸਕਦੇ ਹਨ ਜਦੋਂ ਸਪੀਡ ਟੈਸਟ ਸਿਹਤਮੰਦ ਡਾਊਨਲੋਡ ਦੱਸਦਾ ਹੈ, ਕਿਉਂਕਿ ਥ੍ਰੂਪੁਟ ਅਤੇ ਸਮੇਂ ਸਿਰ ਡਿਲੀਵਰੀ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਮਾਪਦੇ ਹਨ। ਕੋਈ ਵੀ ਸੈਟਿੰਗ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸਬੂਤ ਨੂੰ ਆਵਾਜ਼ ਨਾਲ ਮਿਲਾਓ।
ਦੇਰ ਨਾਲ ਆਉਣ ਵਾਲੇ ਅਤੇ ਗੁੰਮ ਪੈਕਟ ਵੱਖਰੇ ਕਿਉਂ ਸੁਣਾਈ ਦਿੰਦੇ ਹਨ
ਮੀਡੀਆ ਭੇਜਣ ਵਾਲੇ ਤੋਂ ਸਥਿਰ ਦਰ ਨਾਲ ਨਿਕਲਦਾ ਹੈ, ਅਤੇ ਅਸਲ ਨੈੱਟਵਰਕ ਇਸਨੂੰ ਅਸਮਾਨ ਅੰਤਰਾਲਾਂ ਵਿੱਚ ਪਹੁੰਚਾਉਂਦੇ ਹਨ। ਐਪਾਂ ਥੋੜ੍ਹਾ ਬਫਰ ਕਰਕੇ ਇਸਨੂੰ ਸੁਚਾਰੂ ਬਣਾਉਂਦੀਆਂ ਹਨ, ਦੇਰੀ ਦੇ ਬਦਲੇ ਨਿਰੰਤਰਤਾ ਖਰੀਦਦੀਆਂ ਹਨ: ਬਫਰ ਵਧਾਓ ਤਾਂ ਗੱਲਬਾਤ ਹੌਲੀ ਲੱਗਦੀ ਹੈ, ਘਟਾਓ ਤਾਂ ਖਾਲੀ ਥਾਵਾਂ ਦਿਖਦੀਆਂ ਹਨ। ਪਲੇਆਉਟ ਸਮਾਂ-ਸੀਮਾ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲਾ ਪੈਕਟ ਕਦੇ ਵੀ ਸੁੱਟਿਆ ਨਾ ਗਿਆ ਹੋਣ ਦੇ ਬਾਵਜੂਦ ਅਸਲ ਵਿੱਚ ਗੁੰਮ ਹੈ। ਇਸੇ ਲਈ ਇੱਕੋ ਬੈਂਡਵਿਡਥ ਵਾਲੇ ਦੋ ਕਨੈਕਸ਼ਨ ਬਹੁਤ ਵੱਖਰੀਆਂ ਕਾਲਾਂ ਦੇ ਸਕਦੇ ਹਨ।
ਦਿਸ਼ਾ ਵੀ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਆਉਂਦਾ ਅਤੇ ਜਾਂਦਾ ਮੀਡੀਆ ਵੱਖਰੇ ਰਾਹ ਲੈ ਸਕਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਇੱਕ ਧਿਰ ਮੋਬਾਈਲ ਨੈੱਟਵਰਕ ਉੱਤੇ ਹੋਵੇ।
ਮਾੜੇ ਸਮੇਂ ਵਿੱਚ ਪੜ੍ਹਨ ਵਾਲੇ ਅੰਕੜੇ
ਐਪ ਆਪਣੇ ਅੰਕੜੇ ਜਿੱਥੇ ਦਿੰਦੀ ਹੈ ਉੱਥੇ ਵਰਤੋ, ਅਤੇ ਕਾਲ ਖਤਮ ਹੋਣ ਤੋਂ ਬਾਅਦ ਨਹੀਂ, ਕਾਲ ਮਾੜੀ ਹੋਣ ਵੇਲੇ ਪੜ੍ਹੋ। ਮੀਡੀਆ ਰਿਲੇ ਅਕਸਰ ਸੇਵਾ ਦੀ ਵੈੱਬਸਾਈਟ ਤੋਂ ਵੱਖਰਾ ਹੋਸਟ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਹੋਮਪੇਜ ਨੂੰ ping ਉਹ ਰਾਹ ਮਾਪਦਾ ਹੈ ਜੋ ਕਾਲ ਨਹੀਂ ਵਰਤਦੀ। ਲੌਸ ਦੀ ਪ੍ਰਤੀਸ਼ਤਤਾ, ਰਾਊਂਡ-ਟ੍ਰਿਪ ਸਮਾਂ ਅਤੇ ਜਿਟਰ ਵੱਖਰੇ ਦੇਖੋ, ਅਤੇ ਨੋਟ ਕਰੋ ਕਿ ਕਲਾਇੰਟ ਸਮੱਸਿਆ ਭੇਜ ਰਿਹਾ ਹੈ ਜਾਂ ਲੈ ਰਿਹਾ ਹੈ। ਕਾਲ ਦੌਰਾਨ VPN ਦਾ ਦੁਬਾਰਾ ਜੁੜਨਾ ਤੀਜੀ ਘਟਨਾ ਹੈ ਜੋ ਦਰਜ ਕਰਨੀ ਹੈ, ਦੂਜਿਆਂ ਵਿੱਚ ਨਹੀਂ ਮਿਲਾਉਣੀ।
ਅੰਕੜਿਆਂ ਦੇ ਪੈਨਲ ਦੇ ਸਕ੍ਰੀਨਸ਼ਾਟ ਕਾਲ ਦੀ ਯਾਦ ਤੋਂ ਬਿਹਤਰ ਹਨ, ਕਿਉਂਕਿ ਅੰਕੜਿਆਂ ਦੀ ਤੁਲਨਾ ਬਾਅਦ ਵਿੱਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਵੀਹ ਸਕਿੰਟ ਦੀ ਲੌਸ ਪ੍ਰਤੀਸ਼ਤਤਾ ਦੱਸਦੀ ਹੈ ਕਿ ਰਾਹ ਹੁਣ ਪੈਕਟ ਸੁੱਟ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਪਰ ਇਹ ਨਹੀਂ ਕਿ ਲੌਸ ਝੁੰਡਾਂ ਵਿੱਚ ਆਉਂਦਾ ਹੈ ਜਾਂ ਕਦੋਂ ਸ਼ੁਰੂ ਹੋਇਆ।
ਇਸ ਲਈ ਇੱਕ ਵਿੰਡੋ ਨੂੰ ਫੈਸਲਾ ਮੰਨ ਕੇ ਪੜ੍ਹਨ ਦੀ ਥਾਂ ਦੂਜੀ ਸ਼ਰਤ ਹੇਠ ਮਾਪ ਦੁਹਰਾਓ। ਵੱਖਰੀਆਂ ਸ਼ਰਤਾਂ ਹੇਠ ਲਈਆਂ ਦੋ ਵਿੰਡੋਾਂ ਕਿਸੇ ਵੀ ਸ਼ਰਤ ਤੋਂ ਬਿਨਾਂ ਲਈ ਇੱਕ ਲੰਮੀ ਵਿੰਡੋ ਤੋਂ ਵੱਧ ਕਹਿੰਦੀਆਂ ਹਨ।
ਜਿਟਰ ਬਫਰ ਸਮਾਂ-ਸੀਮਾ ਨਾਲ ਕੀ ਕਰਦਾ ਹੈ
ਜਿਟਰ ਬਫਰ ਆਉਂਦੇ ਪੈਕਟਾਂ ਨੂੰ ਥੋੜ੍ਹੀ ਦੇਰ ਰੋਕ ਕੇ ਰੱਖਦਾ ਹੈ, ਤਾਂ ਜੋ ਅਸਮਾਨ ਆਗਮਨ — ਜੋ ਦੇਰੀ-ਬਦਲਾਅ RFC 3393 ਮਾਪਦੰਡ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ — ਨਿਯਮਿਤ ਘੜੀ ਉੱਤੇ ਵਜਾਇਆ ਜਾ ਸਕੇ। ਬਫਰ ਦਾ ਆਕਾਰ ਪਲੇਆਉਟ ਸਮਾਂ-ਸੀਮਾ ਤੈਅ ਕਰਦਾ ਹੈ: ਉਸ ਸੀਮਾ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲਾ ਹਰ ਪੈਕਟ, ਉਸਦੀ ਸਮੱਗਰੀ ਕੁਝ ਵੀ ਹੋਵੇ, ਸੁੱਟ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਕੋਡੈਕ ਵੱਖਰੇ ਹਨ ਕਿ ਉਹ ਕਿੰਨਾ ਲੁਕਾ ਸਕਦੇ ਹਨ, ਅਤੇ ਗੁੰਮ ਫਰੇਮ ਨੂੰ ਇੰਟਰਪੋਲੇਟ ਕਰਨ ਵਾਲਾ ਕੋਡੈਕ ਇੱਕ ਲੌਸ ਲੁਕਾ ਸਕਦਾ ਹੈ, ਪਰ ਉਹਨਾਂ ਦੀ ਲੜੀ ਨਹੀਂ। ਇਸੇ ਲਈ ਇੱਕੋ ਲੌਸ ਪ੍ਰਤੀਸ਼ਤਤਾ ਵੱਖਰੇ ਕੋਡੈਕ ਉੱਤੇ ਵੱਖਰੀ ਕਾਲ ਗੁਣਵੱਤਾ ਦਿੰਦੀ ਹੈ।
ਬਫਰ ਟਿਊਨ ਕਰਨਾ ਵਟਾਂਦਰਾ ਹੈ, ਸੁਧਾਰ ਨਹੀਂ। ਵੱਡਾ ਬਫਰ ਗੱਲਬਾਤ ਦੀ ਦੇਰੀ ਦੀ ਕੀਮਤ ਉੱਤੇ ਨਿਰੰਤਰਤਾ ਖਰੀਦਦਾ ਹੈ, ਅਤੇ ਸਮਾਂ-ਸੀਮਾ ਤੋਂ ਬਾਅਦ ਆਉਣ ਵਾਲੇ ਪੈਕਟ ਉਹ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਸਕਦਾ।
ਬਾਹਰ ਨਿਕਲਣ ਤੋਂ ਪਹਿਲਾਂ ਰੇਡੀਓ ਅਤੇ ਭਾਰ ਦੀ ਤੁਲਨਾ ਕਰੋ
ਐਗਜ਼ਿਟ ਅਤੇ ਐਪ ਸਥਿਰ ਰੱਖੋ ਅਤੇ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਸਥਾਨਕ ਸ਼ਰਤ ਬਦਲੋ। ਮਜ਼ਬੂਤ ਸਿਗਨਲ ਆਈਕਨ ਚੈਨਲ ਦੀ ਭੀੜ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਦੱਸਦਾ। ਜੇ ਸਮੱਸਿਆ ਇੱਕ ਕਮਰੇ ਜਾਂ ਇੱਕ ਐਕਸੈਸ ਪੁਆਇੰਟ ਦਾ ਪਿੱਛਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਅਗਲੀ ਜਾਂਚ ਰੇਡੀਓ ਹੈ।
ping -c 50 -i 0.2 203.0.113.9
mtr -rw -c 20 203.0.113.9
ping ਲੌਸ ਦੀ ਗਿਣਤੀ ਅਤੇ ਸ਼ਰਤਾਂ ਵਿਚਕਾਰ ਤੁਲਨਾ ਯੋਗ ਫੈਲਾਅ ਦਿੰਦਾ ਹੈ, ਅਤੇ mtr ਰਾਹ ਉੱਤੇ ਹਰ ਹੌਪ ਉੱਤੇ ਲੌਸ ਦਿਖਾਉਂਦਾ ਹੈ। ਵਿਚਕਾਰਲੇ ਹੌਪ ਫੇਲ ਹੋਣ ਪਰ ਅੱਗੇ ਵਾਲੇ ਜਵਾਬ ਦੇਣ, ਤਾਂ ਆਮ ਤੌਰ ਉੱਤੇ ਵਰਤੋਂਕਾਰ ਟ੍ਰੈਫਿਕ ਸੁੱਟਣ ਦੀ ਥਾਂ ICMP ਨੂੰ ਘੱਟ ਤਰਜੀਹ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਨਿਯੰਤਰਿਤ ਅੱਪਲੋਡ ਚੱਲਦਿਆਂ ਦੋਵੇਂ ਦੁਹਰਾਓ, ਕਿਉਂਕਿ ਵਿਹਲੇ ਸਮੇਂ ਠੀਕ ਅਤੇ ਭਾਰ ਹੇਠ ਬੇਕਾਰ ਲਿੰਕ VPN ਨਹੀਂ, ਕਤਾਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਜੇ ਸਿਰਫ ਇੱਕ ਸ਼ਰਤ ਸਮੱਸਿਆ ਦੁਹਰਾਉਂਦੀ ਹੈ, ਤਾਂ ਦੂਜੀ ਸ਼ਰਤ ਹੁਣੇ ਬਾਹਰ ਹੋ ਗਈ।
ਤੁਲਨਾ ਜਿਸਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ ਸਿਰਫ ਉਹੀ ਸੁਧਾਰੋ
ਹਰ ਤੁਲਨਾ ਇੱਕ ਸੁਧਾਰ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਇੱਕੋ ਵੇਲੇ ਕਈ ਕਰਨ ਨਾਲ ਸਬੂਤ ਨਸ਼ਟ ਹੋ ਜਾਂਦਾ ਹੈ। ਕਮਜ਼ੋਰ ਸਥਾਨਕ ਰਾਹ ਨੂੰ ਵਧੀਆ ਚੈਨਲ ਜਾਂ Ethernet ਚਾਹੀਦਾ ਹੈ, ਮੁਕਾਬਲੇ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਸ਼ਡਿਊਲਿੰਗ ਜਾਂ ਕਤਾਰ-ਅਨੁਸ਼ਾਸਨ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਮਾੜੇ ਐਗਜ਼ਿਟ ਨੂੰ ਉਹਨਾਂ ਹੀ ਸ਼ਰਤਾਂ ਹੇਠ ਦੂਜੇ ਐਗਜ਼ਿਟ ਦੀ ਤੁਲਨਾ ਚਾਹੀਦੀ ਹੈ। VPN ਟਰਾਂਸਪੋਰਟ ਬਦਲਦਿਆਂ ਪ੍ਰੋਫਾਈਲ ਵੈਧ ਰੱਖੋ ਅਤੇ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇੱਕ ਚਰ ਬਦਲੋ। ਸਪੀਡ-ਟੈਸਟ ਸਕੋਰ ਵਧਿਆ ਕਿ ਨਹੀਂ ਇਸ ਨਾਲ ਸਫਲਤਾ ਮਾਪਣ ਦੀ ਥਾਂ ਆਮ ਬੈਕਗਰਾਊਂਡ ਸਰਗਰਮੀ ਨਾਲ ਉਹੀ ਗੱਲਬਾਤ ਦੁਬਾਰਾ ਜਾਂਚੋ।
ਦਿਸ਼ਾ, ਲੌਸ, ਜਿਟਰ, ਰਾਊਂਡ-ਟ੍ਰਿਪ ਸਮਾਂ ਅਤੇ ਹਰ ਇੱਕ ਕਿਹੜੀ ਸ਼ਰਤ ਹੇਠ ਮਾਪਿਆ ਗਿਆ, ਲਿਖ ਕੇ ਰੱਖੋ। ਉਹ ਰਿਕਾਰਡ ਕਾਲ ਗੁਣਵੱਤਾ ਬਾਰੇ ਅਸਪਸ਼ਟ ਸ਼ਿਕਾਇਤ ਨੂੰ ਅਜਿਹੀ ਖੋਜ ਵਿੱਚ ਬਦਲਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਕੋਈ ਕਾਰਵਾਈ ਕਰ ਸਕੇ। ਇਸਨੂੰ ਟਿਕਟ ਨਾਲ ਰੱਖੋ ਤਾਂ ਜੋ ਅਗਲੀ ਤੁਲਨਾ ਉਸੇ ਆਧਾਰ ਰੇਖਾ ਤੋਂ ਸ਼ੁਰੂ ਹੋਵੇ।