ਤੁਹਾਡੇ ਰਾਊਟਰ ਦੀ Wi-Fi ਰੇਟਿੰਗ VPN ਥ੍ਰੂਪੁਟ ਦੀ ਭਵਿੱਖਬਾਣੀ ਕਿਉਂ ਨਹੀਂ ਕਰਦੀ
ਇਸ਼ਤਿਹਾਰ ਕੀਤੀ Wi-Fi ਦਰ ਅਤੇ ਮਾਪੀ ਗਈ VPN ਦਰ ਵੱਖਰੀਆਂ ਪਰਤਾਂ ਦਾ ਵਰਣਨ ਕਰਦੀਆਂ ਹਨ। ਤੇਜ਼ ਰਾਊਟਰ ਖਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਕ੍ਰਮਬੱਧ ਜਾਂਚ ਪੂਰੀ ਕਰੋ।
3,000 Mbps ਦਾ Wi-Fi ਬੈਜ ਵਾਲਾ ਰਾਊਟਰ ਵੀ ਐਨਕ੍ਰਿਪਟ ਕੀਤੀ ਟ੍ਰੈਫਿਕ ਨੂੰ ਉਸ ਸੰਖਿਆ ਦੇ ਇੱਕ ਛੋਟੇ ਹਿੱਸੇ ਦੀ ਗਤੀ ਨਾਲ ਸਾਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਦੋਹਾਂ ਸੰਖਿਆਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਬੇਈਮਾਨ ਨਹੀਂ। ਰੇਡੀਓ ਰੇਟਿੰਗ ਉਸ ਵਾਇਰਲੈੱਸ ਲਿੰਕ ਦੇ ਸਭ ਤੋਂ ਵਧੀਆ ਮਾਡਿਊਲੇਸ਼ਨ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ ਜਿਸਨੂੰ ਚਿਪਸੈੱਟ ਸਹਾਇਤਾ ਦਿੰਦਾ ਹੈ; VPN ਸੰਖਿਆ ਦੱਸਦੀ ਹੈ ਕਿ ਇੱਕ ਯੰਤਰ ਐਨਕ੍ਰਿਪਟ ਕੀਤੇ ਪੈਕਟਾਂ ਨੂੰ ਰਾਊਟਰ ਦੇ ਪ੍ਰੋਸੈਸਰ ਰਾਹੀਂ ਅਤੇ ਤੁਹਾਡੇ ਪਹੁੰਚ ਸਰਕਟ ਤੋਂ ਬਾਹਰ ਕਿੰਨੀ ਤੇਜ਼ੀ ਨਾਲ ਧੱਕ ਸਕਦਾ ਹੈ। ਇਹ ਵੱਖਰੀਆਂ ਪਰਤਾਂ, ਵੱਖਰੇ ਪੈਕਟ ਆਕਾਰ ਅਤੇ ਵੱਖਰੇ ਮਾਪਣ ਤਰੀਕੇ ਹਨ। ਡੱਬੇ ਉੱਤੇ ਲਿਖੀ ਸੰਖਿਆ ਨੂੰ ਉਹ ਸੀਮਾ ਮੰਨੋ ਜਿੱਥੇ ਕੋਈ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਤੁਹਾਡੇ ਟਨਲ ਦੀ ਗਤੀ ਦੀ ਭਵਿੱਖਬਾਣੀ ਨਹੀਂ।
ਕਦਮ 1: ਸੰਖਿਆ ਨੂੰ ਸੀਮਿਤ ਕਰਨ ਵਾਲੀਆਂ ਚਾਰ ਪਰਤਾਂ ਦਾ ਨਕਸ਼ਾ ਬਣਾਓ
ਮੈਂ ਜਿਨ੍ਹਾਂ ਹੌਲੀ ਰਾਊਟਰਾਂ ਦੀ ਸ਼ਿਕਾਇਤ 'ਤੇ ਕੰਮ ਕੀਤਾ ਹੈ, ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਲਗਭਗ ਸਾਰੀਆਂ ਚਾਰ ਵਿੱਚੋਂ ਇੱਕ ਪੱਧਰ ਵਿੱਚ ਆਉਂਦੀਆਂ ਹਨ: ਵਾਇਰਲੈੱਸ ਲਿੰਕ, WAN ਪਹੁੰਚ ਦਰ, ਫਾਰਵਰਡਿੰਗ ਰਾਹ (NAT, ਫਾਇਰਵਾਲ, ਕਨੈਕਸ਼ਨ ਟ੍ਰੈਕਿੰਗ) ਜਾਂ VPN ਕ੍ਰਿਪਟੋ ਰਾਹ। ਇਹ ਇੱਕ-ਦੂਜੇ ਉੱਤੇ ਪਰਤਾਂ ਬਣਦੇ ਹਨ, ਅਤੇ ਸਭ ਤੋਂ ਹੌਲੀ ਪੱਧਰ ਨਤੀਜਾ ਤੈਅ ਕਰਦਾ ਹੈ। ਇਸ਼ਤਿਹਾਰ ਕੀਤੀ Wi-Fi ਦਰ ਸਿਰਫ਼ ਪਹਿਲੀ ਪਰਤ ਬਾਰੇ ਬੋਲਦੀ ਹੈ, ਅਤੇ ਉਸ ਬਾਰੇ ਖੁੱਲ੍ਹੇ ਦਿਲ ਨਾਲ ਬੋਲਦੀ ਹੈ।
ਉਹ ਸੰਖਿਆ ਸਟ੍ਰੀਮਾਂ ਦੀ ਗਿਣਤੀ ਗੁਣਾ ਚੈਨਲ ਚੌੜਾਈ ਗੁਣਾ ਉਸ ਸਭ ਤੋਂ ਉੱਚੇ ਮਾਡਿਊਲੇਸ਼ਨ ਤੋਂ ਆਉਂਦੀ ਹੈ ਜਿਸ 'ਤੇ ਚਿਪਸੈੱਟ ਗੱਲਬਾਤ ਕਰ ਸਕਦਾ ਹੈ। 5 GHz 'ਤੇ 80 MHz 'ਤੇ 1024-QAM ਵਾਲਾ 2x2 ਰੇਡੀਓ 1,200 Mbps ਦੇ ਨੇੜੇ ਇਸ਼ਤਿਹਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ Wi-Fi ਇੱਕ ਸਾਂਝਾ, ਅੱਧ-ਦੁਪਾਸੜ ਮਾਧਿਅਮ ਹੈ: ਕਲਾਇੰਟ ਵਾਰੀ-ਵਾਰੀ ਆਉਂਦੇ ਹਨ, ਦੁਬਾਰਾ ਭੇਜਣੇ ਅਤੇ ਪ੍ਰਬੰਧਨ ਟ੍ਰੈਫਿਕ ਹਵਾ ਦਾ ਸਮਾਂ ਸਾੜਦੇ ਹਨ, ਅਤੇ TCP ਆਪਣਾ ਵਾਧੂ ਭਾਰ ਜੋੜਦਾ ਹੈ। ਆਦਰਸ਼ ਹਾਲਾਤਾਂ ਵਿੱਚ ਸਭ ਤੋਂ ਉੱਚੀ ਦਰ 'ਤੇ ਗੱਲਬਾਤ ਕਰਨ ਵਾਲਾ ਕਲਾਇੰਟ ਆਮ ਤੌਰ 'ਤੇ ਉਸਦੇ ਅੱਧ ਤੋਂ ਬਹੁਤ ਘੱਟ ਮਾਪਦਾ ਹੈ, ਅਤੇ ਗੁਆਂਢੀ ਨੈੱਟਵਰਕ ਦਿਖਣ 'ਤੇ ਹੋਰ ਵੀ ਘੱਟ।
| Symptom | Tier to suspect first |
|---|---|
| Wired clients are slow too | WAN access or forwarding path |
| Only Wi-Fi clients are slow | Radio, airtime, or channel width |
| One stream is slow, four parallel streams add up | Per-connection CPU path, not the link |
| Every stream is slow and one core sits at 100% | Crypto path |
| Fast to LAN hosts, slow to the internet | WAN, not the tunnel |
ਜੇ ਸਾਰਣੀ ਰੇਡੀਓ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਪਹਿਲਾਂ ਵਾਇਰਲੈੱਸ ਪਾਸਾ ਠੀਕ ਕਰੋ: ਬੈਂਡ, ਚੈਨਲ ਚੌੜਾਈ, ਦੂਰੀ। ਜੇ ਇਹ ਰੇਡੀਓ ਤੋਂ ਹੇਠਾਂ ਇਸ਼ਾਰਾ ਕਰਦੀ ਹੈ, ਤਾਂ ਅਗਲੇ ਚਾਰ ਕਦਮ ਮਾਇਨੇ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਕਿੰਨੀ ਵੀ ਐਂਟੀਨਾ ਖਰੀਦੋ, ਇਹ ਨਹੀਂ ਬਦਲੇਗਾ।
ਕਦਮ 2: ਰੇਡੀਓ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਤਾਰ ਵਾਲੀ ਆਧਾਰ ਰੇਖਾ ਲਓ
ਲੈਪਟਾਪ ਨੂੰ Ethernet 'ਤੇ ਰੱਖੋ ਅਤੇ ਪਹਿਲਾਂ ਟਨਲ ਤੋਂ ਬਿਨਾਂ ਰਾਹ ਮਾਪੋ, ਕਿਉਂਕਿ ਇਸ ਨਾਲ ਤੁਹਾਨੂੰ ਹਰ ਮਿਲਦਾ ਹੈ। ਥ੍ਰੂਪੁਟ ਸਾਧਨ ਨੂੰ ਦੂਜੇ ਪਾਸੇ, VPN ਖਤਮ ਕਰਨ ਵਾਲੇ VPS ਜਾਂ ਘਰ ਦੇ ਸਰਵਰ 'ਤੇ ਚਲਾਓ, ਅਤੇ ਕਲਾਇੰਟ ਨੂੰ ਉਸਦੇ ਜਨਤਕ ਪਤੇ ਵੱਲ ਨਿਰਦੇਸ਼ਿਤ ਕਰੋ ਤਾਂ ਜੋ ਟ੍ਰੈਫਿਕ ਤੁਹਾਡੇ ਰਾਊਟਰ ਅਤੇ ਪਹੁੰਚ ਸਰਕਟ ਰਾਹੀਂ ਲੰਘੇ।
# on the far host (VPN endpoint)
iperf3 -s
# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30
# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4
ਉਸ ਬਲਾਕ ਦੀਆਂ ਦੋ ਸੰਖਿਆਵਾਂ ਦੋ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦੀਆਂ ਹਨ। ਇੱਕ ਸਟ੍ਰੀਮ ਪ੍ਰਤੀ-ਕਨੈਕਸ਼ਨ ਸੀਮਾ ਦਿਖਾਉਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ TCP ਵਿੰਡੋ ਦਾ ਵਿਵਹਾਰ ਅਤੇ ਰਾਹ 'ਤੇ ਕੋਈ ਵੀ ਪ੍ਰਤੀ-ਪ੍ਰਵਾਹ ਆਕਾਰ ਦੇਣਾ ਸ਼ਾਮਲ ਹੈ। ਚਾਰ ਸਟ੍ਰੀਮ ਦਿਖਾਉਂਦੀਆਂ ਹਨ ਕਿ ਲਿੰਕ ਵਿੱਚ ਤੁਹਾਡੀ ਨਾ ਵਰਤੀ ਗਈ ਸਮਰੱਥਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਕਿਉਂਕਿ ਸਮਾਨਾਂਤਰ ਪ੍ਰਵਾਹ ਉਹ ਪਾਈਪ ਭਰ ਸਕਦੇ ਹਨ ਜੋ ਇੱਕ ਪ੍ਰਵਾਹ ਨਹੀਂ ਭਰ ਸਕਦਾ।
ਇਸਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖੋ: ਉਹੀ ਹੋਸਟ, ਦਿਨ ਦਾ ਸਮਾਂ ਅਤੇ ਮਿਆਦ, ਘਰ ਵਿੱਚ ਹੋਰ ਕੁਝ ਸਟ੍ਰੀਮ ਨਾ ਹੋਵੇ। ਤੀਹ ਸਕਿੰਟ ਦੀ ਵੱਡੀ ਟ੍ਰਾਂਸਫਰ ਇੱਥੇ ਸਹੀ ਇਕਾਈ ਹੈ, ਅਤੇ RFC 6349, TCP ਥ੍ਰੂਪੁਟ ਜਾਂਚ ਦਾ ਢਾਂਚਾ, ਠੀਕ ਇਸੇ ਤਰਕ 'ਤੇ ਬਣਿਆ ਹੈ, ਕਿਉਂਕਿ ਛੋਟੇ ਧਮਾਕੇ ਅਤੇ ਛੋਟੀਆਂ ਬੇਨਤੀਆਂ ਲਿੰਕ ਨੂੰ ਵਧੀਆ ਦਿਖਾਉਂਦੀਆਂ ਹਨ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਆਧਾਰ ਰੇਖਾ ਲਿਖ ਲਓ।
ਕਦਮ 3: ਉਹੀ ਜਾਂਚ ਟਨਲ ਰਾਹੀਂ ਚਲਾਓ
ਹੁਣ ਇਸਨੂੰ ਅੰਤਿਮ ਬਿੰਦੂ ਦੇ ਟਨਲ ਪਤੇ ਦੇ ਸਾਮ੍ਹਣੇ ਦੁਹਰਾਓ, ਉਹੀ ਕਲਾਇੰਟ, ਮਿਆਦ ਅਤੇ ਸਟ੍ਰੀਮ ਗਿਣਤੀ ਨਾਲ, ਟਨਲ ਚਾਲੂ ਅਤੇ ਹੋਰ ਟ੍ਰੈਫਿਕ ਨਾ ਹੋਵੇ। ਦੋਵਾਂ ਨਤੀਜਿਆਂ ਦਾ ਅਨੁਪਾਤ ਤੁਹਾਨੂੰ ਦੱਸਦਾ ਹੈ ਕਿ ਉਸ ਹਾਰਡਵੇਅਰ 'ਤੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਐਨਕੈਪਸੂਲੇਸ਼ਨ ਕਿੰਨਾ ਖਰਚ ਕਰਦੇ ਹਨ; ਪੂਰੀ ਸੰਖਿਆ ਦੱਸਦੀ ਹੈ ਕਿ ਕੰਮ ਲਈ ਇਹ ਕਾਫ਼ੀ ਹੈ ਜਾਂ ਨਹੀਂ।
ਟ੍ਰਾਂਸਫਰ ਚੱਲਦਿਆਂ ਕਾਊਂਟਰ ਵੇਖੋ। WireGuard 'ਤੇ, wg show ਪ੍ਰਤੀ ਸਾਥੀ ਭੇਜੇ ਬਾਈਟ ਦੱਸਦਾ ਹੈ; OpenVPN 'ਤੇ, ਅੰਤਰਾਲ 'ਤੇ ਲਿਖੀ ਜਾਣ ਵਾਲੀ ਸਥਿਤੀ ਫਾਈਲ ਤੁਹਾਨੂੰ ਉਹੀ ਦ੍ਰਿਸ਼ ਦਿੰਦੀ ਹੈ।
watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status
ਜੇ ਟਨਲ ਦੀ ਸੰਖਿਆ ਤਾਰ ਵਾਲੀ ਆਧਾਰ ਰੇਖਾ ਦੇ ਨੇੜੇ ਹੈ, ਤਾਂ VPN ਤੁਹਾਡੀ ਰੁਕਾਵਟ ਨਹੀਂ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇਸਨੂੰ ਦੋਸ਼ ਦੇਣਾ ਬੰਦ ਕਰ ਸਕਦੇ ਹੋ। ਜੇ ਇਹ ਆਧਾਰ ਰੇਖਾ ਦਾ ਇੱਕ ਹਿੱਸਾ ਹੈ, ਤਾਂ ਨੁਕਸਾਨ ਰਾਊਟਰ ਦੇ ਐਨਕ੍ਰਿਪਸ਼ਨ ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਰਾਹ ਦੇ ਅੰਦਰ ਹੋਇਆ ਹੈ, ਅਤੇ ਅਗਲਾ ਕਦਮ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਹਿੱਸਾ।
ਇੱਕ ਚੇਤਾਵਨੀ: ਜਿਵੇਂ ਹੀ ਬਾਹਰ ਜਾਣ ਵਾਲਾ IP ਬਦਲਦਾ ਹੈ, ਕੁਝ ਗਤੀ ਜਾਂਚ ਸੇਵਾਵਾਂ ਚੁੱਪਚਾਪ ਦੂਜਾ ਮਾਪਣ ਸਰਵਰ ਚੁਣ ਲੈਂਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਤੁਸੀਂ ਅੰਤ ਵਿੱਚ ਦੋ ਵੱਖਰੀਆਂ ਮੰਜ਼ਿਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰਦੇ ਹੋ। ਸਰਵਰ ਦਾ ਪਤਾ ਆਪ ਪਿੰਨ ਕਰੋ।
ਕਦਮ 4: ਪ੍ਰੋਸੈਸਰ ਨੂੰ ਔਸਤ ਨਹੀਂ, ਰਾਹ ਵਜੋਂ ਪੜ੍ਹੋ
30 ਫ਼ੀਸਦੀ ਕੁੱਲ ਪ੍ਰੋਸੈਸਰ ਦਿਖਾਉਣ ਵਾਲਾ ਰਾਊਟਰ ਵੀ ਸੰਤ੍ਰਿਪਤ ਹੋ ਸਕਦਾ ਹੈ: ਇੱਕ ਟਨਲ ਦਾ ਕੰਮ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਕੋਰ, ਇੱਕ ਇੰਟਰਪਟ ਕਤਾਰ ਜਾਂ ਇੱਕ ਕਰਨਲ ਥ੍ਰੈਡ 'ਤੇ ਪੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਔਸਤ ਸੀਮਾ ਲੁਕਾਉਂਦੀ ਹੈ। ਡੈਸ਼ਬੋਰਡ ਗੇਜ ਦੀ ਥਾਂ ਪ੍ਰਤੀ-ਕੋਰ ਅਤੇ softirq ਸੰਖਿਆਵਾਂ ਵੇਖੋ।
mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfoਉਸ ਆਉਟਪੁੱਟ ਵਿੱਚ ਤਿੰਨ ਗੱਲਾਂ ਮਾਇਨੇ ਰੱਖਦੀਆਂ ਹਨ। ਇੱਕ ਕੋਰ ਦਾ 100 ਫ਼ੀਸਦੀ ਦੇ ਨੇੜੇ ਪਿੰਨ ਹੋਣਾ ਜਦੋਂ ਬਾਕੀ ਖਾਲੀ ਹਨ, ਪ੍ਰਤੀ-ਕਨੈਕਸ਼ਨ ਸੀਮਾ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਭਾਰੀ %soft ਜਾਂ ਇੱਕ ਪ੍ਰੋਸੈਸਰ 'ਤੇ ਰੁੱਝਿਆ ksoftirqd ਕਤਾਰਾਂ ਵਿੱਚ ਨਾ ਫੈਲਣ ਵਾਲੀ ਪ੍ਰਾਪਤੀ-ਪਾਸੇ ਪੈਕਟ ਪ੍ਰੋਸੈਸਿੰਗ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਹੈ। ਅਤੇ aes ਝੰਡਾ ਨਾ ਹੋਣ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਪ੍ਰੋਸੈਸਰ ਵਿੱਚ AES ਹਦਾਇਤਾਂ ਨਹੀਂ ਹਨ, ਇਸ ਲਈ ਸਮਮਿਤੀ ਐਨਕ੍ਰਿਪਸ਼ਨ ਸਾਫਟਵੇਅਰ ਵਿੱਚ ਚੱਲਦਾ ਹੈ ਅਤੇ ਪ੍ਰਤੀ ਪੈਕਟ ਬਹੁਤ ਵੱਧ ਖਰਚ ਕਰਦਾ ਹੈ।
ਲਾਗੂ ਕਰਨਾ ਵੀ ਮਾਇਨੇ ਰੱਖਦਾ ਹੈ। ਪਰੰਪਰਾਗਤ ਯੂਜ਼ਰ-ਸਪੇਸ OpenVPN ਇੰਸਟੈਂਸ ਇੱਕ ਟਨਲ ਦੇ ਪੈਕਟ ਬਹੁਤ ਹੱਦ ਤੱਕ ਇੱਕੋ ਥਾਂ ਪ੍ਰੋਸੈਸ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਤੇਜ਼ ਬਹੁ-ਕੋਰ ਡੱਬਾ ਉਸ ਟਨਲ ਲਈ ਇੱਕ-ਕੋਰ ਵਾਂਗ ਵਿਵਹਾਰ ਕਰ ਸਕਦਾ ਹੈ। ਕਰਨਲ ਵਿੱਚ WireGuard ਕੰਮ ਨੂੰ ਪ੍ਰੋਸੈਸਰਾਂ ਵਿੱਚ ਫੈਲਾਉਂਦਾ ਹੈ, ਅਤੇ OpenVPN ਦਾ ਡੇਟਾ ਚੈਨਲ ਆਫਲੋਡ ਪੈਕਟ ਸੰਭਾਲ ਨੂੰ ਕਰਨਲ ਵਿੱਚ ਵੀ ਲੈ ਜਾਂਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਬਿਲਡਾਂ ਅਤੇ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਜੋ ਇਸਨੂੰ ਸਹਾਇਤਾ ਦਿੰਦੇ ਹਨ। ਮਾਰਕੀਟਿੰਗ ਪੰਨੇ 'ਤੇ ਹਾਰਡਵੇਅਰ ਤੇਜ਼ ਕਰਨ ਦਾ ਦਾਅਵਾ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਨਹੀਂ ਕਿ ਤੁਸੀਂ ਚਲਾ ਰਹੇ ਕੋਡ ਰਾਹ ਇਸਨੂੰ ਵਰਤਦਾ ਹੈ।
ਕਦਮ 5: ਕੀ ਬਦਲਣਾ ਹੈ, ਇਸੇ ਕ੍ਰਮ ਵਿੱਚ ਤੈਅ ਕਰੋ
ਇਹ ਸੂਚੀ ਹੇਠਾਂ ਚੱਲੋ ਅਤੇ ਸੱਚੀ ਪਹਿਲੀ ਲਾਈਨ 'ਤੇ ਰੁਕੋ, ਕਿਉਂਕਿ ਇਸਦੇ ਹੇਠਾਂ ਕੁਝ ਵੀ ਬਦਲਣ ਨਾਲ ਸੰਖਿਆ ਨਹੀਂ ਹਿੱਲੇਗੀ।
1. ਤਾਰ ਵਾਲਾ ਸਿੱਧਾ ਥ੍ਰੂਪੁਟ ਤੁਹਾਡੇ ਦਿੱਤੇ ਨਾਲੋਂ ਘੱਟ ਹੈ: ਪ੍ਰਦਾਤਾ ਨਾਲ ਗੱਲ ਕਰੋ, ਕਿਉਂਕਿ ਪਹੁੰਚ ਸਰਕਟ ਜੋ ਨਹੀਂ ਦਿੰਦਾ, ਉਹ ਸਮਰੱਥਾ ਟਨਲ ਨਹੀਂ ਬਣਾ ਸਕਦਾ। 2. ਤਾਰ ਵਾਲਾ ਸਿੱਧਾ ਠੀਕ ਹੈ ਪਰ ਟਨਲ ਜਾਂਚ ਦੌਰਾਨ ਇੱਕ ਕੋਰ ਪਿੰਨ ਹੋ ਜਾਂਦਾ ਹੈ: ਰਾਊਟਰ ਦਾ ਕ੍ਰਿਪਟੋ ਰਾਹ ਹੀ ਸੀਮਾ ਹੈ। 3. ਪ੍ਰੋਸੈਸਰ ਨਿਸ਼ਕਿਰਿਆ ਹੈ ਪਰ ਟਨਲ ਹੌਲੀ ਹੈ: MTU ਅਤੇ ਟੁਕੜੇ ਹੋਣਾ ਜਾਂਚੋ, ਫਿਰ ਦੂਰ ਦੇ ਅੰਤਿਮ ਬਿੰਦੂ ਦੀ ਆਪਣੀ ਸਮਰੱਥਾ। 4. ਸਿਰਫ਼ Wi-Fi ਕਲਾਇੰਟ ਹੌਲੀ ਹਨ: ਬੈਂਡ ਜਾਂ ਚੈਨਲ ਚੌੜਾਈ ਬਦਲੋ, ਅਤੇ ਮੰਨੋ ਕਿ ਇਸ਼ਤਿਹਾਰ ਕੀਤੀ ਦਰ ਕਦੇ VPN ਸੰਖਿਆ ਨਹੀਂ ਸੀ।
ਜਦੋਂ ਰਾਊਟਰ ਸੱਚਮੁੱਚ ਸੀਮਾ ਹੋਵੇ, ਤਾਂ ਇਮਾਨਦਾਰ ਚੋਣਾਂ ਹਨ AES ਹਦਾਇਤਾਂ ਅਤੇ ਤੇਜ਼ ਫਾਰਵਰਡਿੰਗ ਰਾਹ ਵਾਲਾ ਯੰਤਰ, ਯੂਜ਼ਰ-ਸਪੇਸ ਦੀ ਥਾਂ WireGuard ਵਰਗਾ ਕਰਨਲ-ਪਾਸੇ ਟਨਲ, ਜਾਂ ਕਲਾਇੰਟ ਨੂੰ ਯੰਤਰ ਵਿੱਚ ਹੀ ਲੈ ਜਾਣਾ ਤਾਂ ਜੋ ਰਾਊਟਰ ਐਨਕ੍ਰਿਪਟ ਕਰਨਾ ਬੰਦ ਕਰ ਦੇਵੇ। ਬੈਂਚਮਾਰਕ ਜਿੱਤਣ ਲਈ ਪ੍ਰਮਾਣਿਤ ਐਨਕ੍ਰਿਪਸ਼ਨ ਬੰਦ ਕਰਨਾ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਹੀਂ ਹੈ; ਇਹ ਸੁਰੱਖਿਆ ਗੁਣ ਨੂੰ ਅਜਿਹੀ ਸੰਖਿਆ ਨਾਲ ਬਦਲਦਾ ਹੈ ਜੋ ਫਿਰ ਵੀ ਡੱਬੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਏਗੀ।
ਕੁਝ ਵੀ ਖਰੀਦਣ ਤੋਂ ਪਹਿਲਾਂ, ਉਸੇ ਸਰਵਰ ਅਤੇ ਮਿਆਦ ਨਾਲ ਨਵੇਂ ਯੰਤਰ 'ਤੇ ਕਦਮ 2 ਅਤੇ 3 ਦੁਬਾਰਾ ਚਲਾਓ, ਫਿਰ ਸਿਖਰਾਂ ਦੀ ਥਾਂ ਅਨੁਪਾਤਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ।