VPN ਰਾਹੀਂ ਅਸਲ-ਸਮਾਂ ਟ੍ਰੈਫਿਕ ਲਈ ਦੇਰੀ ਬਜਟ ਸੈੱਟ ਕਰੋ
ਐਪ ਨੂੰ ਪੂਰਾ ਕਰਨ ਵਾਲੀ ਆਖਰੀ ਮਿਆਦ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਫਿਰ ਦੱਸੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਇੱਕ-ਪਾਸੜ ਦੇਰੀ ਅਤੇ ਜਿਟਰ ਮਾਪੋ। ਦੇਰ ਨਾਲ ਆਏ ਪੈਕਟਾਂ ਦੀ ਸੀਮਾ ਤੋਂ ਬਿਨਾਂ ਔਸਤ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ।
ਅਸਲ-ਸਮਾਂ VPN ਦੀਆਂ ਸ਼ਿਕਾਇਤਾਂ ਨੂੰ ਅਸਫਲ ਹੋਣ ਲਈ ਇੱਕ ਮਿਆਦ ਚਾਹੀਦੀ ਹੈ, ਅਤੇ «ਘੱਟ ਦੇਰੀ» ਅਜਿਹੀ ਮਿਆਦ ਨਹੀਂ ਹੈ। ਤੈ ਕਰੋ ਕਿ ਗੱਲਬਾਤ ਜਾਂ ਦੂਰਸਥ ਸੈਸ਼ਨ ਨੂੰ ਕੀ ਦੇਣਾ ਹੈ, ਫਿਰ ਦੱਸੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਉਸ ਲੋੜ ਦੇ ਸਾਹਮਣੇ ਰਾਹ ਮਾਪੋ। ਦੇਰ ਨਾਲ ਆਏ ਪੈਕਟਾਂ ਦੀ ਸੀਮਾ ਤੋਂ ਬਿਨਾਂ ਹਰ ਨਤੀਜਾ ਵਿਵਾਦਪੂਰਨ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੀ ਵੰਡ ਇੱਕ ਡਿਜ਼ਾਈਨ ਫੈਸਲਾ ਹੈ, ਅਤੇ ਇਹ ਇਸ ਲਈ ਹੈ ਤਾਂ ਕਿ ਮਾਪ ਦੇ ਕੋਲ ਜਵਾਬ ਦੇਣ ਲਈ ਕੁਝ ਹੋਵੇ।
ਪ੍ਰੋਬ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਮਿਆਦ ਲਿਖੋ
ਮਿਆਦ ਐਪ ਅਤੇ ਇਸ ਦੇ ਵਰਤੋਂਕਾਰਾਂ ਤੋਂ ਆਉਂਦੀ ਹੈ, ਕਿਸੇ ਵਿਕਰੇਤਾ ਦੇ ਮਾਰਕੀਟਿੰਗ ਪੰਨੇ ਤੋਂ ਨਹੀਂ। ਲਾਈਵ ਆਵਾਜ਼ ਕਾਲ, ਦੂਰਸਥ ਡੈਸਕਟਾਪ ਸੈਸ਼ਨ ਅਤੇ ਰਾਤ ਦਾ ਬੈਕਅਪ ਬਿਲਕੁਲ ਵੱਖਰੇ ਇੰਤਜ਼ਾਰ ਸਮੇਂ ਸਹਿੰਦੇ ਹਨ, ਅਤੇ ਮਹੱਤਵਪੂਰਨ ਅਸਫਲਤਾ ਆਮ ਤੌਰ ਤੇ ਮੱਧਮਾਨ ਨਹੀਂ, ਪੂਛ ਹੁੰਦੀ ਹੈ। ਸੰਖਿਆ ਨੂੰ ਉਸ ਕੰਮ ਦੇ ਭਾਰ ਨਾਲ ਲਿਖੋ ਜਿਸ ਨਾਲ ਇਹ ਸੰਬੰਧਿਤ ਹੈ।
ਫਿਰ ਇਸ ਨੂੰ ਵੰਡੋ। ਕੈਪਚਰ ਅਤੇ ਪੈਕਟਾਈਜ਼ੇਸ਼ਨ ਬਜਟ ਦਾ ਇੱਕ ਹਿੱਸਾ ਖਰਚਦੇ ਹਨ, ਐਕਸੈਸ ਲਿੰਕ ਅਤੇ ਟਨਲ ਦੂਜਾ ਹਿੱਸਾ, ਪ੍ਰਾਪਤਕਰਤਾ ਦਾ ਡੀ-ਜਿਟਰ ਬਫਰ ਜਾਣ-ਬੁੱਝ ਕੇ ਪੈਕਟ ਰੋਕਦਾ ਹੈ, ਅਤੇ ਐਪ ਪ੍ਰੋਸੈਸਿੰਗ ਬਾਕੀ ਲੈਂਦੀ ਹੈ। ਇਹਨਾਂ ਪੜਾਵਾਂ ਨੂੰ ਨਾਮ ਦੇਣਾ ਟਨਲ ਐਨਕ੍ਰਿਪਸ਼ਨ ਨੂੰ ਹਰ ਹੌਲੀ ਪੈਕਟ ਲਈ ਡਿਫਾਲਟ ਸ਼ੱਕੀ ਬਣਾਉਣ ਦੀ ਬਜਾਏ ਅਨੁਪਾਤ ਵਿੱਚ ਰੱਖਦਾ ਹੈ।
ਅੰਤ ਵਿੱਚ ਮਾਪ ਦੇ ਇਕਰਾਰਨਾਮੇ ਨੂੰ ਚਾਰ ਲਾਈਨਾਂ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ: ਅੰਤ ਬਿੰਦੂ ਅਤੇ ਦਿਸ਼ਾ, ਟ੍ਰੈਫਿਕ ਦਾ ਆਕਾਰ, ਚੱਲਣ ਵੇਲੇ ਦੀਆਂ ਸਥਿਤੀਆਂ, ਅਤੇ ਨਤੀਜਾ ਜੋ ਤੁਸੀਂ ਰਿਪੋਰਟ ਕਰੋਗੇ। ਸ਼ਾਂਤ ਐਤਵਾਰ ਦਾ ਨਮੂਨਾ ਅਤੇ ਭਰਿਆ ਮੰਗਲਵਾਰ ਦਾ ਨਮੂਨਾ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਇਸ ਲਈ ਦੱਸੋ ਕਿ ਤੁਸੀਂ ਕਿਹੜਾ ਇਕੱਠਾ ਕੀਤਾ। ਜੇ ਤੁਸੀਂ ਚਾਰੇ ਲਾਈਨਾਂ ਨਹੀਂ ਭਰ ਸਕਦੇ, ਤਾਂ ਦੌੜ ਸ਼ੁਰੂ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਹੈ। ਉਹ ਚੈੱਕਲਿਸਟ ਹੀ ਮਹੀਨਿਆਂ ਬਾਅਦ ਦੋ ਰਿਪੋਰਟਾਂ ਨੂੰ ਤੁਲਨਾਯੋਗ ਬਣਾਉਂਦੀ ਹੈ, ਜਦੋਂ ਕਿਸੇ ਨੂੰ ਯਾਦ ਨਹੀਂ ਰਹਿੰਦਾ ਕਿ ਲਿੰਕ ਹੋਰ ਕੀ ਲੈ ਕੇ ਜਾ ਰਿਹਾ ਸੀ।
ਹਰ ਪੜਾਅ ਤੇ ਬਜਟ ਵੰਡੋ
ਸਾਰਣੀ ਯੋਜਨਾ ਦੀ ਸਹਾਇਕ ਹੈ, ਕੈਪਚਰ ਕੀਤਾ ਡੇਟਾ ਨਹੀਂ। ਪਹਿਲੇ ਪ੍ਰੋਬ ਤੋਂ ਪਹਿਲਾਂ ਹਰ ਕਤਾਰ ਦਾ ਮਾਲਕ ਭਰੋ, ਕਿਉਂਕਿ ਮਾਲਕ ਉਹ ਵਿਅਕਤੀ ਹੈ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਤਦ ਫੋਨ ਕਰਦੇ ਹੋ ਜਦੋਂ ਉਹ ਪੜਾਅ ਆਪਣਾ ਹਿੱਸਾ ਪਾਰ ਕਰਦਾ ਹੈ।
| Stage | What it contributes | Who owns it |
|---|---|---|
| Capture and packetization | Encoder frame size, aggregation | Application owner |
| Tunnel and transit | Encryption, queueing, path length | Network owner |
| Receiver buffer | Deliberate waiting to absorb variation | Application owner |
| Application processing | Decode and render time | Application owner |
ਦੋ ਕਤਾਰਾਂ ਆਮ ਤੌਰ ਤੇ ਲੋਕਾਂ ਨੂੰ ਹੈਰਾਨ ਕਰਦੀਆਂ ਹਨ। ਪ੍ਰਾਪਤਕਰਤਾ ਦਾ ਬਫਰ ਦੇਰੀ ਜੋੜਦਾ ਹੈ ਤਾਂ ਉਹ ਖਰਾਬੀ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਉਹ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਿਸ ਲਈ ਇਸ ਨੂੰ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਸੀ। ਅਤੇ ਟਨਲ ਦਾ ਹਿੱਸਾ ਅਕਸਰ ਇਸ ਦੇ ਸਾਹਮਣੇ ਦੀ ਕਤਾਰ ਤੋਂ ਛੋਟਾ ਹੁੰਦਾ ਹੈ, ਖਾਸ ਕਰਕੇ ਅਜਿਹੀ ਅਪਲਿੰਕ ਤੇ ਜੋ ਅੱਪਲੋਡ ਦੌਰਾਨ ਸੰਤ੍ਰਿਪਤ ਹੁੰਦੀ ਹੈ।
ਜੇ ਕਿਸੇ ਪੜਾਅ ਦਾ ਕੋਈ ਮਾਲਕ ਨਹੀਂ, ਤਾਂ ਬਜਟ ਕਾਲਪਨਿਕ ਹੈ। ਮਾਪਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਨਿਯੁਕਤ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਅਗਲੀ ਮੀਟਿੰਗ ਕਿਸ ਦਾ ਨੰਬਰ ਗਲਤ ਹੈ ਇਸ ਬਹਿਸ ਵਿੱਚ ਜਾਵੇਗੀ।
ਇਮਾਨਦਾਰ ਘੜੀ ਨਾਲ ਇੱਕ-ਪਾਸੜ ਦੇਰੀ ਮਾਪੋ
ਇੱਕ-ਪਾਸੜ ਦੇਰੀ ਉਹ ਸੰਖਿਆ ਹੈ ਜਿਸ ਦੀ ਮਿਆਦ ਨੂੰ ਪਰਵਾਹ ਹੈ, ਅਤੇ ਇਸ ਲਈ ਦੋਵੇਂ ਸਿਰਿਆਂ ਤੇ ਸਮਕਾਲੀ ਘੜੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਇੱਕ-ਪਾਸੜ ਦੇਰੀ ਦਾ ਮੈਟ੍ਰਿਕ ਮੰਗਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਨਤੀਜੇ ਨਾਲ ਸਮਕਾਲੀਕਰਨ ਢੰਗ, ਵਿਭੇਦਨ ਅਤੇ ਅਨੁਮਾਨਿਤ ਵਿਚਲਨ ਦੀ ਰਿਪੋਰਟ ਕਰੋ। ਦੋ ਅਸਮਕਾਲੀ ਹੋਸਟ ਗਲਤ ਮਾਤਰਾ ਲਈ ਬਹੁਤ ਸਹੀ ਸੰਖਿਆ ਦੇ ਸਕਦੇ ਹਨ।
ਮੁੱਠੀ ਭਰ ਦੀ ਬਜਾਏ ਕੁਝ ਸੌ ਪੈਕਟ ਫੜੋ, ਅਤੇ ਉਸੇ ਸਮੇਂ ਘੜੀ ਦੀ ਸਥਿਤੀ ਦਰਜ ਕਰੋ:
$ ntpq -p
$ owping -c 300 -i 0.2 10.90.0.1
$ ping -c 200 -i 0.2 10.90.0.1 | tail -n 3ਰਾਊਂਡ-ਟ੍ਰਿਪ ਸਮਾਂ ਇੱਕ ਵੱਖਰਾ ਮਾਪ ਹੈ, ਦੋ ਇੱਕ-ਪਾਸੜ ਮੁੱਲਾਂ ਦਾ ਜੋੜ ਨਹੀਂ। RTT ਨੂੰ ਅੱਧਾ ਕਰਨਾ ਸਮਮਿਤ ਰਾਹ ਅਤੇ ਸਮਮਿਤ ਕਤਾਰਾਂ ਮੰਨਦਾ ਹੈ, ਅਤੇ ਮੋਬਾਈਲ ਅਪਲਿੰਕ ਉੱਤੇ ਟਨਲ ਨਿਯਮਿਤ ਤੌਰ ਤੇ ਦੋਵੇਂ ਧਾਰਨਾਵਾਂ ਤੋੜਦਾ ਹੈ। RTT ਨੂੰ RTT ਵਜੋਂ ਰਿਪੋਰਟ ਕਰੋ ਅਤੇ ਇਸ ਨੂੰ ਇੱਕ-ਪਾਸੜ ਬਜਟ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।
ਪੂਛ ਅਤੇ ਦੇਰ ਨਾਲ ਆਏ ਪੈਕਟਾਂ ਦੀ ਰਿਪੋਰਟ ਕਰੋ
ਵੰਡ ਦਾ ਸਾਰ ਦਿਓ: ਮੱਧਮਾਨ, 95ਵਾਂ ਅਤੇ 99ਵਾਂ ਪ੍ਰਤੀਸ਼ਤਕ, ਸਭ ਤੋਂ ਖਰਾਬ ਸਥਿਤੀ, ਨੁਕਸਾਨ, ਅਤੇ ਉਹਨਾਂ ਪੈਕਟਾਂ ਦੀ ਗਿਣਤੀ ਜੋ ਮਿਆਦ ਦੀ ਆਗਿਆ ਨਾਲੋਂ ਦੇਰ ਨਾਲ ਪਹੁੰਚੇ। ਅਸਲ-ਸਮਾਂ ਕੰਮ ਦੇ ਭਾਰ ਲਈ ਔਸਤ ਉਹਨਾਂ ਸੰਖਿਆਵਾਂ ਵਿੱਚੋਂ ਸਭ ਤੋਂ ਘੱਟ ਲਾਭਦਾਇਕ ਹੈ, ਕਿਉਂਕਿ ਸਮਤਲ ਔਸਤ ਹਰ ਤੀਜੀ ਕਾਲ ਨੂੰ ਬਰਬਾਦ ਕਰਨ ਵਾਲੀ ਪੂਛ ਲੁਕਾ ਸਕਦੀ ਹੈ।
ਦੇਰੀ ਦੀ ਭਿੰਨਤਾ ਸਿੱਧੀ ਪ੍ਰਾਪਤਕਰਤਾ ਦੇ ਬਫਰ ਨੂੰ ਭੋਜਨ ਦਿੰਦੀ ਹੈ। ਵੱਧ ਬਫਰਿੰਗ ਭਿੰਨਤਾ ਲੁਕਾਉਂਦੀ ਹੈ ਅਤੇ ਇੰਤਜ਼ਾਰ ਜੋੜਦੀ ਹੈ, ਇਸ ਲਈ ਸਟ੍ਰੀਮ ਆਪਣੀ ਮਿਆਦ ਪਾਰ ਕਰਦਿਆਂ ਵੀ ਸਥਿਰ ਦਿਖ ਸਕਦੀ ਹੈ। ਭਿੰਨਤਾ ਲਈ ਇੱਕ ਫਾਰਮੂਲਾ ਚੁਣੋ, ਜਿਸ ਅੰਤਰਾਲ ਤੇ ਤੁਸੀਂ ਮਾਪਿਆ ਉਹ ਦੱਸੋ, ਅਤੇ ਦੌੜਾਂ ਵਿਚਕਾਰ ਇਸ ਨੂੰ ਇਕਸਾਰ ਰੱਖੋ।
ਪ੍ਰਤੀਨਿਧੀ ਕ੍ਰਾਸ-ਟ੍ਰੈਫਿਕ ਨਾਲ ਦੌੜ ਦੁਹਰਾਓ। ਜੋ ਰਾਹ ਨਿਸ਼ਕਿਰਿਆ ਹੁੰਦੇ ਬਜਟ ਪੂਰਾ ਕਰਦਾ ਹੈ ਅਤੇ ਬੈਕਅਪ ਵਿੰਡੋ ਦੌਰਾਨ ਇਸ ਨੂੰ ਖੁੰਝਾ ਦਿੰਦਾ ਹੈ, ਉਸ ਨੇ ਤੁਹਾਨੂੰ ਸ਼ੈਡਿਊਲਿੰਗ ਬਾਰੇ ਕੁਝ ਲਾਭਦਾਇਕ ਦੱਸਿਆ ਹੈ, ਜੋ ਕੋਈ ਵੀ ਇਕੱਲਾ ਸ਼ਾਂਤ ਮਾਪ ਪ੍ਰਗਟ ਨਹੀਂ ਕਰਦਾ। ਨਤੀਜੇ ਦੇ ਕੋਲ ਸਥਿਤੀਆਂ ਦਰਜ ਕਰੋ, ਨਹੀਂ ਤਾਂ ਅਗਲਾ ਇੰਜੀਨੀਅਰ ਉਹਨਾਂ ਦੋ ਨਮੂਨਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰੇਗਾ ਜੋ ਕਦੇ ਵੀ ਤੁਲਨਾਯੋਗ ਨਹੀਂ ਸਨ।
ਡਿਜ਼ਾਈਨ ਸਵੀਕਾਰ ਕਰੋ ਜਦੋਂ ਮਾਪੀ ਪੂਛ ਉਸ ਕੰਮ ਦੇ ਭਾਰ ਹੇਠ ਬਜਟ ਵਿੱਚ ਫਿੱਟ ਹੁੰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹੋ, ਅਤੇ ਰਿਪੋਰਟ ਵਿੱਚ ਪਾਰ ਕੀਤੇ ਪੜਾਅ ਦਾ ਨਾਮ ਲੈ ਕੇ ਇਸ ਨੂੰ ਰੱਦ ਕਰੋ।