ਇੱਕੋ ਟਨਲ ਉੱਤੇ ਦੋ VPN ਸਪੀਡ ਟੈਸਟ ਵੱਖ ਕਿਉਂ ਪੈਂਦੇ ਹਨ
ਨਵਾਂ ਐਗਜ਼ਿਟ ਟੈਸਟ ਸਰਵਰ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਹੌਲੀ ਸ਼ੁਰੂਆਤ ਨਤੀਜਾ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਮੰਜ਼ਿਲ ਤੈਅ ਕਰੋ, ਸਟ੍ਰੀਮਾਂ ਦੀ ਗਿਣਤੀ ਮਿਲਾਓ ਅਤੇ ਪ੍ਰੋਸੈਸਰ ਦੀ ਲਾਗਤ ਨੂੰ ਲਿੰਕ ਦੀ ਸਮਰੱਥਾ ਤੋਂ ਵੱਖ ਕਰੋ।
ਦੋ ਦੌੜਾਂ, ਇੱਕ ਟਨਲ, ਅਤੇ ਸੰਖਿਆਵਾਂ ਤਿੰਨ ਗੁਣਾ ਵੱਖ ਹਨ। ਉਹਨਾਂ ਵਿਚਕਾਰ ਟਨਲ ਬਦਲੀ ਨਹੀਂ। ਜੋ ਬਦਲਿਆ ਉਹ ਮਾਪ ਹੈ: ਤੁਹਾਡੀ ਦਿਸਦੀ ਥਾਂ ਦੇ ਆਧਾਰ ’ਤੇ ਸਰਵਰ ਚੁਣਨ ਵਾਲੀ ਟੈਸਟ ਸਾਈਟ, ਸਟ੍ਰੀਮਾਂ ਦੀ ਗਿਣਤੀ ਜੋ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਪਾਈਪ ਇੱਕ ਹੌਲੀ ਸ਼ੁਰੂਆਤ ਭਰਦੀ ਹੈ ਜਾਂ ਛੇ, ਅਤੇ ਇੰਨੀ ਛੋਟੀ ਮਿਆਦ ਕਿ ਰਾਹ ਦੇ ਠੀਕ ਤਰ੍ਹਾਂ ਵਰਤੇ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਮੁੱਕ ਜਾਵੇ। ਸਪੀਡ ਟੈਸਟ ਗਲਤ ਨਹੀਂ ਹਨ, ਪਰ ਉਹ ਲੋਕਾਂ ਵੱਲੋਂ ਪੁੱਛੇ ਸਵਾਲ ਨਾਲੋਂ ਸੰਕੁਚਿਤ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ।
ਨਵਾਂ ਐਗਜ਼ਿਟ ਪਤਾ ਟੈਸਟ ਦੀ ਮੰਜ਼ਿਲ ਬਦਲ ਦਿੰਦਾ ਹੈ
ਬਹੁਤੀਆਂ ਟੈਸਟ ਸਾਈਟਾਂ ਆਪਣੇ ਆਪ ਮਾਪ ਸਰਵਰ ਚੁਣਦੀਆਂ ਹਨ, ਅਤੇ ਇਸਨੂੰ ਕੁਝ ਹੱਦ ਤੱਕ ਇਹ ਦੇਖ ਕੇ ਚੁਣਦੀਆਂ ਹਨ ਕਿ ਤੁਹਾਡਾ ਕਨੈਕਸ਼ਨ ਕਿੱਥੋਂ ਆਉਂਦਾ ਦਿਸਦਾ ਹੈ। ਟਨਲ ਚਾਲੂ ਕਰੋ ਅਤੇ ਤੁਹਾਡਾ ਦਿਸਦਾ ਦੇਸ਼ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਚੁਣਿਆ ਸਰਵਰ ਬਦਲ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਤੁਲਨਾ ਹੁਣ ਦੋ ਵੱਖਰੇ ਹੋਸਟਾਂ ਤੱਕ ਦੇ ਦੋ ਵੱਖਰੇ ਰਾਹਾਂ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ।
ਨਤੀਜਾ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ VPN ਦਾ ਮਾਪ ਨਹੀਂ ਹੈ। ਇਹ ਤੁਹਾਡੇ ਉਸ ਸਰਵਰ ਤੱਕ ਦੇ ਰਾਹ ਦਾ ਮਾਪ ਹੈ ਜੋ ਤੁਸੀਂ ਨਹੀਂ ਚੁਣਿਆ, ਅਤੇ ਦੋ ਦੌੜਾਂ ਵਿਚਕਾਰਲਾ ਫ਼ਰਕ ਟਨਲ ਦੇ ਕੀਤੇ ਕਿਸੇ ਕੰਮ ਨਾਲੋਂ ਉਸ ਸਰਵਰ ਦੀ ਪੀਅਰਿੰਗ ਕਰਕੇ ਹੋ ਸਕਦਾ ਹੈ।
ਹੋਰ ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮੰਜ਼ਿਲ ਤੈਅ ਕਰੋ। ਹਰ ਭਰੋਸੇਯੋਗ ਸਾਧਨ ਤੁਹਾਨੂੰ ਸਪਸ਼ਟ ਤੌਰ ’ਤੇ ਸਰਵਰ ਚੁਣਨ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਨਹੀਂ ਦਿੰਦਾ ਤਾਂ ਨਤੀਜਾ ਪੰਨਾ ਆਮ ਤੌਰ ’ਤੇ ਵਰਤੇ ਗਏ ਸਰਵਰ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ, ਜੋ ਇਹ ਵੇਖਣ ਲਈ ਕਾਫ਼ੀ ਹੈ ਕਿ ਦੋਵੇਂ ਦੌੜਾਂ ਤੁਲਨਾਯੋਗ ਨਹੀਂ। ਸਾਈਟ ਨੇ ਕੀ ਵੇਖਿਆ, ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰੋ, ਉਸਦੀ ਚੋਣ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ:
curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'ਜੇ ਦੌੜਾਂ ਵਿਚਕਾਰ ਦੇਸ਼ ਬਦਲਿਆ, ਤਾਂ ਟੈਸਟ ਨੇ ਬਾਅਦ ਵਿੱਚ ਜੋ ਵੀ ਚੁਣਿਆ ਉਹ ਵੀ ਬਦਲ ਗਿਆ। ਹਰ ਨਤੀਜੇ ਦੇ ਕੋਲ ਦਿਸਿਆ ਐਗਜ਼ਿਟ ਲਿਖੋ ਅਤੇ ਉਲਝਣ ਬਹੁਤ ਹੱਦ ਤੱਕ ਮਿਟ ਜਾਂਦੀ ਹੈ।
ਹੌਲੀ ਸ਼ੁਰੂਆਤ ਬਹੁਤੇ ਛੋਟੇ ਟੈਸਟ ਮੁੱਕਣ ਤੋਂ ਬਾਅਦ ਮੁੱਕਦੀ ਹੈ
TCP ਕਨੈਕਸ਼ਨ ਲਿੰਕ ਦੀ ਗਤੀ ਨਾਲ ਸ਼ੁਰੂ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ ਛੋਟੀ ਕੰਜੈਸ਼ਨ ਵਿੰਡੋ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਲਗਭਗ ਹਰ ਰਾਊਂਡ ਟ੍ਰਿਪ ’ਤੇ ਇਸਨੂੰ ਦੁੱਗਣਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਕਈ ਰਾਊਂਡ ਟ੍ਰਿਪਾਂ ਤੋਂ ਬਾਅਦ ਹੀ ਰਾਹ ਦੀ ਸਮਰੱਥਾ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ। ਵੱਧ ਲੇਟੈਂਸੀ ਵਾਲੇ ਰਾਹ ’ਤੇ ਦਸ ਸਕਿੰਟ ਦਾ ਟੈਸਟ ਆਪਣੀ ਜ਼ਿੰਦਗੀ ਦਾ ਕਾਫ਼ੀ ਹਿੱਸਾ ਉਸ ਚੜ੍ਹਾਈ ਵਿੱਚ ਬਿਤਾ ਸਕਦਾ ਹੈ।
ਇਸੇ ਲਈ ਵੱਧ ਲੇਟੈਂਸੀ ਵਾਲਾ ਟਨਲ ਛੋਟੇ ਟੈਸਟ ਵਿੱਚ ਲਾਇਕ ਤੋਂ ਮਾੜੇ ਅੰਕ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਲੰਮੀ ਦੌੜ ਅਕਸਰ ਕੋਈ ਵੀ ਸੈਟਿੰਗ ਬਦਲੇ ਬਿਨਾਂ ਵੱਧ ਸੰਖਿਆ ਦੱਸਦੀ ਹੈ। RFC 6349 ਥਰੂਪੁਟ ਢਾਂਚਾ ਇਸਨੂੰ ਸਪਸ਼ਟ ਤੌਰ ’ਤੇ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਗੰਭੀਰ ਮਾਪ ਸਥਿਰ ਹਾਲਤ ਤੱਕ ਪਹੁੰਚਣ ਲਈ ਕਾਫ਼ੀ ਲੰਮੇ ਚੱਲਦੇ ਹਨ। ਸੈਟੇਲਾਈਟ ਰਾਹ ’ਤੇ ਪੰਜ ਸਕਿੰਟ ਦੀ ਦੌੜ ਰਾਹ ਨਹੀਂ, ਤਵਰਕ ਮਾਪਦੀ ਹੈ।
ਇੱਕੋ ਸੰਖਿਆ ’ਤੇ ਭਰੋਸਾ ਕਰਨ ਦੀ ਥਾਂ ਕਨੈਕਸ਼ਨ ਦੇ ਪੜਾਅ ਵੇਖੋ। Curl ਹਰ ਪੜਾਅ ਵੱਖਰਾ ਦੱਸਦਾ ਹੈ, ਇਸ ਲਈ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ ਕਿ ਸਮਾਂ ਹੈਂਡਸ਼ੇਕ ਵਿੱਚ ਜਾ ਰਿਹਾ ਹੈ, ਚੜ੍ਹਾਈ ਵਿੱਚ ਜਾਂ ਟਰਾਂਸਫਰ ਵਿੱਚ:
curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
https://mirror.example.net/testfile.binਇਸਨੂੰ ਉਸੇ ਮੰਜ਼ਿਲ ਵੱਲ ਲਗਾਤਾਰ ਦੋ ਵਾਰ ਚਲਾਓ। ਜੇ ਦੂਜੀ ਦੌੜ ਬਹੁਤ ਤੇਜ਼ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਰਾਹ ਨਹੀਂ, ਚੜ੍ਹਾਈ ਮਾਪ ਰਹੇ ਸੀ, ਅਤੇ ਸਿਰਫ਼ ਪਹਿਲੀ ਦੌੜ ਵਰਤਣ ਵਾਲੀ ਕੋਈ ਵੀ ਤੁਲਨਾ ਸ਼ੱਕੀ ਹੈ।
ਇੱਕ ਸਟ੍ਰੀਮ ਅਤੇ ਛੇ ਸਟ੍ਰੀਮਾਂ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਮਾਪਦੀਆਂ ਹਨ
ਇੱਕ TCP ਸਟ੍ਰੀਮ ਉਸ ਵਿੰਡੋ ਨਾਲ ਸੀਮਿਤ ਹੁੰਦੀ ਹੈ ਜੋ ਇਹ ਉਡਾਣ ਵਿੱਚ ਰੱਖ ਸਕਦੀ ਹੈ, ਜੋ ਲਗਭਗ ਰਾਊਂਡ ਟ੍ਰਿਪ ਸਮਾਂ ਗੁਣਾ ਦਰ ਹੈ। ਲੰਮੇ ਰਾਹ ’ਤੇ ਉਹ ਗੁਣਨਫਲ ਇੱਕ ਸਟ੍ਰੀਮ ਦੇ ਵਰਤਣ ਨਾਲੋਂ ਵੱਧ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਇੱਕ ਡਾਊਨਲੋਡ ਮੌਜੂਦ ਸਮਰੱਥਾ ਨੂੰ ਘੱਟ ਦੱਸਦਾ ਹੈ। ਛੇ ਸਮਾਨਾਂਤਰ ਸਟ੍ਰੀਮਾਂ ਇਹ ਖਾਲੀ ਥਾਂ ਭਰਦੀਆਂ ਹਨ ਅਤੇ ਵੱਡੀ ਸੰਖਿਆ ਦਿੰਦੀਆਂ ਹਨ।
iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.netਦੋਵੇਂ ਸੰਖਿਆਵਾਂ ਸੱਚ ਹਨ। ਇੱਕ ਸਟ੍ਰੀਮ ਦੀ ਸੰਖਿਆ ਦੱਸਦੀ ਹੈ ਕਿ ਇੱਕ ਡਾਊਨਲੋਡ ਕੀ ਕਰੇਗਾ, ਜੋ ਆਮ ਤੌਰ ’ਤੇ ਬਰਾਊਜ਼ਰ ਟੈਬ ਨੂੰ ਮਿਲਦਾ ਹੈ। ਸਮਾਨਾਂਤਰ ਸੰਖਿਆ ਦੱਸਦੀ ਹੈ ਕਿ ਰਾਹ ਕੁੱਲ ਮਿਲਾ ਕੇ ਕੀ ਢੋ ਸਕਦਾ ਹੈ, ਜੋ ਟੋਰੈਂਟ ਜਾਂ ਬਹੁ-ਭਾਗ ਡਾਊਨਲੋਡ ਵਰਤ ਸਕਦਾ ਹੈ। ਇੱਕ ਨੂੰ ਦੂਜੇ ਵਾਂਗ ਦੱਸਣਾ ਹੀ ਸਿਹਤਮੰਦ ਟਨਲ ਨੂੰ ਬਿਨਾਂ ਕਾਰਨ ਬਦਲਣ ਦਾ ਤਰੀਕਾ ਹੈ।
ਸਮਾਨਾਂਤਰ ਨਤੀਜੇ ਦੀ ਤੁਲਨਾ ਇੱਕ ਸਟ੍ਰੀਮ ਦੇ ਨਤੀਜੇ ਨਾਲ ਕਰਨਾ ਉਹ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਲੋਕ ਇਹ ਸਿੱਟਾ ਕੱਢਦੇ ਹਨ ਕਿ VPN ਨੇ ਉਹਨਾਂ ਦੀ ਗਤੀ ਅੱਧੀ ਕਰ ਦਿੱਤੀ। ਢੰਗ ਮਿਲਾਓ, ਫਿਰ ਤੁਲਨਾ ਕਰੋ। ਤੀਜੇ ਹੁਕਮ ਦਾ ਨਿਸ਼ਾਨ ਗੁੰਮ ਸੰਦਰਭ ਜੋੜਦਾ ਹੈ: ਵੱਧ ਜਿਟਰ ਵਾਲਾ ਰਾਹ ਦੋਵੇਂ ਢੰਗਾਂ ਵਿੱਚ ਅਸੰਗਤ ਨਤੀਜੇ ਦੇਵੇਗਾ, ਅਤੇ ਕੋਈ ਸਟ੍ਰੀਮ ਗਿਣਤੀ ਇਸਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰਦੀ।
ਐਨਕ੍ਰਿਪਸ਼ਨ ਪ੍ਰੋਸੈਸਰ ਦਾ ਸਮਾਂ ਲੈਂਦਾ ਹੈ, ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਬਾਈਟ ਲੈਂਦਾ ਹੈ
ਲਿੰਕ ਕਿੰਨਾ ਵੀ ਤੇਜ਼ ਹੋਵੇ, ਹਰ ਪੈਕੇਟ ’ਤੇ ਦੋ ਕਾਰਜ-ਵਿਧੀਆਂ ਚੱਲਦੀਆਂ ਹਨ। ਐਨਕ੍ਰਿਪਸ਼ਨ ਪ੍ਰਤੀ ਬਾਈਟ ਪ੍ਰੋਸੈਸਰ ਖਰਚਦਾ ਹੈ, ਅਤੇ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਹੈਡਰ ਬਾਈਟ ਜੋੜਦਾ ਹੈ ਜੋ ਲਿੰਕ ਨੂੰ ਅਜੇ ਵੀ ਢੋਣੇ ਪੈਂਦੇ ਹਨ। ਦੋਵੇਂ ਸੀਮਾ ਵਾਂਗ ਦਿਸਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਦੇ ਲੱਛਣ ਵੱਖਰੇ ਹਨ।
ਪ੍ਰੋਸੈਸਰ ਦੀ ਸੀਮਾ ਪਠਾਰ ਵਾਂਗ ਦਿਸਦੀ ਹੈ: ਤੁਸੀਂ ਕਿੰਨੀਆਂ ਵੀ ਸਟ੍ਰੀਮਾਂ ਜੋੜੋ, ਥਰੂਪੁਟ ਵਧਣਾ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਲਿੰਕ ਖਾਲੀ ਹੁੰਦਿਆਂ ਮਸ਼ੀਨ ਦਾ ਪ੍ਰੋਸੈਸਰ ਰੁੱਝਿਆ ਹੁੰਦਾ ਹੈ। ਛੋਟੇ ਰਾਊਟਰ ਜਾਂ ਫ਼ੋਨ ’ਤੇ ਇਹੀ ਅਕਸਰ ਅਸਲ ਹੱਦ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਤੇਜ਼ ਲਾਈਨ ਵੀ ਸਾਧਾਰਨ ਟਨਲ ਦੇ ਸਕਦੀ ਹੈ।
ਬਾਈਟ ਦੀ ਲਾਗਤ ਘੱਟ ਪਰ ਸਥਿਰ ਹੈ। ਵਾਧੂ ਹੈਡਰ ਦਾ ਮਤਲਬ ਪ੍ਰਤੀ ਪੈਕੇਟ ਘੱਟ ਪੇਲੋਡ ਹੈ, ਅਤੇ ਤੈਅ ਅਧਿਕਤਮ ਟ੍ਰਾਂਸਮਿਸ਼ਨ ਇਕਾਈ ਵਾਲੇ ਰਾਹ ’ਤੇ ਉਹ ਵੱਡੇ ਟਰਾਂਸਫਰਾਂ ਵਿੱਚ ਹੌਲੀ ਔਸਤ ਵਾਂਗ ਨਹੀਂ, ਰੁਕਾਵਟ ਵਾਂਗ ਦਿਸਣ ਵਾਲੀ ਫ੍ਰੈਗਮੈਂਟੇਸ਼ਨ ਜਾਂ ਕਾਲਾ ਟੋਆ ਵੀ ਪੈਦਾ ਕਰ ਸਕਦੇ ਹਨ।
| Observation | Likely mechanism | What to measure |
|---|---|---|
| Throughput flat as streams increase | CPU per packet on one core | Per-core utilisation during the test |
| Fast small transfers, stalled large ones | MTU and fragmentation | Payload size at which it breaks |
| Good average, unusable calls | Queueing delay behind a full buffer | Latency under load |
ਇਹ ਤਿੰਨ ਅਕਸਰ ਰਲਾ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਕਿਉਂਕਿ ਵਰਤੋਂਕਾਰ ਇਹਨਾਂ ਸਭਨਾਂ ਨੂੰ «VPN ਹੌਲੀ ਹੈ» ਕਹਿੰਦੇ ਹਨ। ਸਿਰਫ਼ ਪਹਿਲਾ ਵੱਡੀ ਮਸ਼ੀਨ ’ਤੇ ਪ੍ਰਤੀਕਿਰਿਆ ਦਿੰਦਾ ਹੈ, ਸਿਰਫ਼ ਦੂਜਾ ਛੋਟੇ MTU ’ਤੇ, ਅਤੇ ਸਿਰਫ਼ ਤੀਜਾ ਕਤਾਰ ਪ੍ਰਬੰਧਨ ’ਤੇ।
ਢੰਗ ਨੂੰ ਰਿਕਾਰਡ ਵਿੱਚ ਲਿਖੋ
ਰੱਖਣਯੋਗ ਨਤੀਜਾ ਡਿਵਾਈਸ, ਐਕਸੈਸ ਨੈੱਟਵਰਕ, ਐਗਜ਼ਿਟ, ਮਾਪ ਸਰਵਰ, ਦਿਸ਼ਾ, ਸਟ੍ਰੀਮ ਗਿਣਤੀ ਅਤੇ ਮਿਆਦ ਦਾ ਨਾਮ ਦੱਸਦਾ ਹੈ। ਇਹਨਾਂ ਤੋਂ ਬਿਨਾਂ ਦੋ ਸੰਖਿਆਵਾਂ ਦੀ ਤੁਲਨਾ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਅਤੇ ਇੱਕ ਸੰਖਿਆ ਵਾਲਾ ਟਿਕਟ ਅਸਲ ਵਿੱਚ ਇੱਕ ਮੂਡ ਹੈ।
ਮਾੜੀਆਂ ਦੌੜਾਂ ਵੀ ਰੱਖੋ। ਜਿਸ ਲੜੀ ਵਿੱਚ ਇੱਕ ਐਗਜ਼ਿਟ ਹਰ ਵਾਰ ਰੁਕਾਵਟ ਪੈਦਾ ਕਰਦਾ ਹੈ ਉਹ ਔਸਤ ਨਾਲੋਂ ਕਿਤੇ ਵੱਧ ਜਾਣਕਾਰੀਪੂਰਨ ਹੈ, ਅਤੇ ਰੁਕਾਵਟਾਂ ਹੀ ਉਹ ਚੀਜ਼ ਹਨ ਜੋ ਔਸਤ ਲੁਕਾਉਂਦੇ ਹਨ।
ਫਿਰ ਉਹ ਚੀਜ਼ ਪਰਖੋ ਜੋ ਸੱਚਮੁੱਚ ਤੁਹਾਡੇ ਲਈ ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ। ਜੇ ਟੀਚਾ ਵੱਡਾ ਡਾਊਨਲੋਡ ਹੈ ਤਾਂ ਫਾਈਲ ਡਾਊਨਲੋਡ ਕਰੋ। ਜੇ ਟੀਚਾ ਕਾਲ ਹੈ ਤਾਂ ਨਿਸ਼ਕਿਰਿਆ ਥਰੂਪੁਟ ਦੀ ਥਾਂ ਭਾਰ ਹੇਠ ਲੇਟੈਂਸੀ ਮਾਪੋ, ਕਿਉਂਕਿ ਟਨਲ ਸਪੀਡ ਟੈਸਟ ਵਿੱਚ ਚੰਗੇ ਅੰਕ ਲੈ ਸਕਦਾ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਹਰ ਮੀਟਿੰਗ ਨੂੰ ਸੁਣਨਯੋਗ ਨਾ ਰਹਿਣ ਦੇ ਸਕਦਾ ਹੈ।