தாமதம், ஜிட்டர், பாக்கெட் இழப்பு: ஒவ்வொன்றும் எதைக் குறிக்கிறது

பதிவிறக்க வேகம் அதிகமாக இருப்பதால் மட்டும் அழைப்போ கேமோ தடங்கலின்றி இயங்கும் என்று உத்தரவாதம் இல்லை. ஊடாடும் போக்குவரத்து தாமதம், அந்தத் தாமதத்தில் ஏற்படும் ஏற்ற இறக்கமான ஜிட்டர், பாக்கெட் இழப்பு ஆகியவற்றையும் சார்ந்திருக்கிறது. இவை ஒவ்வொன்றும் இணைப்பின் வெவ்வேறு அம்சத்தைக் காட்டுகின்றன; எனவே சாதனத்தை மாற்றுவதற்கோ சர்வரைக் குறைசொல்வதற்கோ முன், இவற்றைத் தனித்தனியாக அளவிடுங்கள்.

மூன்று அளவீடுகள், மூன்று வெவ்வேறு கேள்விகள்

இரண்டு புள்ளிகளுக்கு இடையே தரவு பயணிக்க எடுக்கும் நேரமே தாமதம். ping முடிவு பொதுவாகச் சுற்றுப் பயண நேரத்தை (RTT) காட்டுகிறது: சோதனைப் பாக்கெட்டை அனுப்பியதிலிருந்து அதன் பதில் வரும் வரையிலான இடைவெளி. அடுத்தடுத்த தாமதங்களுக்கு இடையிலான மாறுபாட்டை ஜிட்டர் விவரிக்கிறது. 20, 21, 90, 18 மில்லிவினாடிகளில் வரும் பதில்களின் சராசரி ஏற்கத்தக்கதாகத் தோன்றலாம்; ஆனாலும் அவற்றில் இடையூறு செய்யும் ஒரு திடீர் உயர்வு இருக்கிறது. பாக்கெட் இழப்பு என்றால், சோதனைப் பாக்கெட்டோ அதன் பதிலோ சோதனையின் நேர வரம்புக்குள் வந்துசேரவில்லை. நெரிசல் அதற்கு ஒரு காரணமாக இருக்கலாம்; கண்டறிதல் போக்குவரத்தை வேண்டுமென்றே வடிகட்டுவது இன்னொரு காரணம்.

இந்த அளவீடுகள் ஒன்றையொன்று பாதிக்கின்றன; ஆனால் ஒன்றுக்குப் பதிலாக மற்றொன்றைப் பயன்படுத்த முடியாது. பெரிய கோப்பை வேகமாக அனுப்பக்கூடிய இணைப்பில், பதிவேற்றத்தின்போது ரவுட்டரில் வரிசை உருவாகி, அழைப்புக்குப் பயன்படும் சிறிய பாக்கெட்டுகள் தாமதமாகலாம். இடையில் உள்ள ஒரு ரவுட்டர் ஒருமுறை மெதுவாகப் பதிலளித்தது என்பது முனைக்கு முனை சிக்கல் இருக்கிறது என்பதற்குப் பலவீனமான சான்று மட்டுமே: ரவுட்டர்கள் வழக்கமான போக்குவரத்தை முன்னனுப்பிக்கொண்டே ICMP பதில்களுக்குக் குறைந்த முன்னுரிமை தரலாம்.

நடைமுறைச் சோதனை வரிசை

ping/traceroute அணுகல் சரிபார்ப்பு கருவியைப் பயன்படுத்தி, ஒரே இலக்குக்குத் தொடர்ச்சியாகச் சோதனைப் பாக்கெட்டுகளை அனுப்புங்கள். இலக்கு, நேரம், குறைந்தபட்ச, அதிகபட்ச RTT, பதில் வராத பாக்கெட்டுகள் ஆகியவற்றைக் குறித்துக்கொள்ளுங்கள். Ethernet வழியாகவோ வேறொரு நெட்வொர்க்கிலோ மீண்டும் செய்யுங்கள். இணைய வேகச் சோதனையை தனியாக இயக்குங்கள்; செயல்திறனும் தாமதமும் வெவ்வேறு கேள்விகளுக்கான பதில்கள். Ethernet-இல் இல்லாத திடீர் உயர்வுகள் Wi-Fi-இல் மட்டும் இருந்தால், முதலில் சிக்னல் தரம், குறுக்கீடு, உள்ளூர் நெட்வொர்க்கில் உள்ள பிற சாதனங்கள் ஆகியவற்றை ஆராயுங்கள்.

நிலைமைகளை ஒப்பிடக்கூடியவையாக வைத்திருங்கள்: அதே சர்வர், அதே சாதனம், அதே முறை, ஏறக்குறைய நாளின் அதே நேரம். இணைப்பு சும்மா இருக்கும்போதும், பெரிய பதிவேற்றம் நடக்கும்போதும் — இரண்டு நிலைகளிலும் சோதியுங்கள். சுமையின் கீழ் RTT பெருமளவு உயர்ந்தால், அது வரிசைப்படுத்தலை (queueing) நோக்கிச் சுட்டுகிறது; DNS-ஐ மட்டும் மாற்றுவதால் அது சரியாக வாய்ப்பில்லை. விளக்கமில்லாத ஒரு திடீர் உயர்வின்போது எடுத்த ஒற்றை ஸ்கிரீன்ஷாட்டைவிட, காலப்போக்கில் செய்த பல சிறு சோதனைகள் அதிகப் பயன் தரும்.

செயலியின் கோணத்தில் முடிவுகளைப் புரிந்துகொள்ளுங்கள்

எல்லா கேம்களையும் அழைப்புகளையும் சிறப்பாக்கும் பொதுவான ஜிட்டர் வரம்பு என்று எதுவும் இல்லை. ஒலியைப் பஃபர் செய்வதிலும், இழப்பிலிருந்து மீள்வதிலும், நெட்வொர்க் பாதைகளைத் தேர்வு செய்வதிலும் செயலிகள் வேறுபடுகின்றன. ICMP பதில்கள் தொலைந்தன என்பதால் மீடியா பாக்கெட்டுகளும் தொலைந்தன என்று பொருளில்லை. ஒரே ஒரு சேவையில் மட்டும் சிக்கல் என்றால், அந்தச் சேவையின் சொந்தப் புள்ளிவிவரங்களையும் நிலையையும் பாருங்கள். பாதைத் தடமறிதல் ஒரு போக்கைக் கண்டறிய உதவலாம்; ஆனால் அதன் சோதனைப் பாக்கெட்டுகள் செயலியின் பாதையிலிருந்து வேறுபட்ட பாதையில் செல்லக்கூடும்.

ping பொதுவாகப் பயன்படுத்தும் ICMP Echo செய்திகளை RFC 792 விவரிக்கிறது. அது இயங்குமுறையை வரையறுக்கிறது; எல்லாச் செயலிகளுக்கும் பொருந்தும் ஒற்றைத் தர மதிப்பெண்ணை அல்ல. மீண்டும் மீண்டும் எடுத்த முடிவுகளை, பயனர்கள் உண்மையில் உணரும் அறிகுறிகளுடன் ஒப்பிடுங்கள்.