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મું ટકાવારી, સૌથી ખરાબ સ્થિતિ, નુકસાન, અને સમયમર્યાદા પરવાનગી આપે તેના કરતાં મોડા પહોંચેલા પેકેટની સંખ્યા. રિયલ-ટાઇમ કાર્યભાર માટે સરેરાશ એ સંખ્યાઓમાં સૌથી ઓછું ઉપયોગી છે, કારણ કે સરળ સરેરાશ એવી પૂંછડી છુપાવી શકે છે જે દર ત્રીજા કૉલને બગાડે છે.
વિલંબની વિવિધતા સીધી પ્રાપ્તકર્તાના બફરને ખોરાક આપે છે. વધુ બફરિંગ વિવિધતા છુપાવે છે અને પ્રતીક્ષા ઉમેરે છે, તેથી સ્ટ્રીમ તેની સમયમર્યાદા વટાવતી વખતે પણ સ્થિર દેખાઈ શકે છે. વિવિધતા માટે સૂત્ર પસંદ કરો, તમે જે અંતરાલ પર માપ્યું તે જણાવો, અને ચાલો વચ્ચે તેને સુસંગત રાખો.
પ્રતિનિધિ ક્રોસ-ટ્રાફિક સાથે ચાલનું પુનરાવર્તન કરો. નિષ્ક્રિય હોય ત્યારે બજેટ પૂરું કરતો અને બેકઅપ વિન્ડો દરમિયાન ચૂકી જતો માર્ગ તમને શેડ્યુલિંગ વિશે ઉપયોગી કંઈક કહ્યું છે, જે કોઈ એકલું શાંત માપન જાહેર ન કરે. પરિણામની બાજુમાં પરિસ્થિતિઓ નોંધો, નહીં તો આગલો ઇજનેર એવા બે નમૂનાઓની સરખામણી કરશે જે ક્યારેય સરખાવી શકાય તેવા ન હતા.
ડિઝાઇન સ્વીકારો જ્યારે માપેલી પૂંછડી તમે ખરેખર ચલાવો છો તે કાર્યભાર હેઠળ બજેટમાં ફિટ થાય, અને અહેવાલમાં જે તબક્કો વટાવ્યો તેનું નામ આપીને તેને નકારો.