मैं वाईफ़ाई राउटर के लिए उच्च पिंग समय का निदान और कल्पना कैसे कर सकता हूं?


65

मैं अपने वाईफाई राउटर के लिए अनिश्चित और कभी-कभी बहुत लंबे पिंग बार देख रहा हूं जो कि सिर्फ एक हॉप दूर है। पिंग करना 192.168.1.1कभी कभी 400-800ms सुप्तावस्था के हिस्सों देता है।

कोशिश करने के लिए बहुत सारी चीजें हैं (फर्मवेयर, राउटर प्लेसमेंट, एपी चैनल, आदि), लेकिन मैं इस समस्या पर थोड़ा और प्रभावी तरीके से हमला करना चाहूंगा:

  • सबसे पहले, मैं अपने नेटवर्क के प्रदर्शन की कल्पना कैसे कर सकता हूं ?
  • फिर, मैं किसी दिए गए कॉन्फ़िगरेशन के प्रदर्शन को कैसे बेंच सकता हूं , ताकि मैं समायोजन करने के बाद मज़बूती से तुलना कर सकूं?

राउटर और / या ऑन-बोर्ड राउटर सॉफ्टवेयर क्या आप उपयोग कर रहे हैं यदि यह स्टॉक स्थापित नहीं है?
जेफ क्लेटन

@JeffClayton Linksys WRT54GSv2 (पुराने स्कूल) टमाटर (शिब्बी) चला रहा है। डीडी-डब्ल्यूआरटी चलाने के लिए उपयोग किया जाता है, लेकिन यह छोटी गाड़ी है और बनाए रखने के लिए भ्रमित है।
पॉल आयरिश

1
क्या आपको वास्तविक समस्या है या यह पूरी तरह से एक कॉस्मेटिक मुद्दा है? वाईफाई राउटर आमतौर पर सुपर-फास्ट पिंग उत्तरदाताओं के लिए डिज़ाइन नहीं किए जाते हैं, उनके पास असली काम करना है।
डेविड श्वार्ट्ज

1
@DavidSchwartz हम एक पूर्ण एपी के लिए एक वाईफ़ाई एपी में 10ms के तहत पूरा करने में सक्षम होना चाहिए, नहीं? यदि आपका इंट्रा-वाईफाई विलंबता 500ms से ऊपर है, तो हर बार आप वेब / इंटरनेट से खींचते हैं, इस विलंबता से भी ग्रस्त है। यह हत्यारा है।
पॉल आयरिश

1
@PaulIrish सब सच है, लेकिन इसका पिंग बार से कोई लेना-देना नहीं है। पिंग नेटवर्क लेटेंसी के योग को मापता है और पिंग रिस्पांस लेटेंसी को ही। SoHo WiFi राउटर कुशल पिंग उत्तरदाता नहीं हैं, इसलिए नेटवर्क विलंबता मापने के लिए पिंग का उपयोग करने की अनुशंसा नहीं की जाती है।
डेविड श्वार्ट्ज

जवाबों:


78

इस सर्वरफॉल्ट उत्तर का क्या करना है, इस पर अच्छा उच्च-स्तरीय मार्गदर्शन है - इसलिए उसी से शुरुआत करें। हालांकि यह आखिरी कदम एक वास्तविक ख़ुशी है: संभवतः आप (मेरा मतलब है, मेरे लिए) इसके लिए समर्पित हार्डवेयर में निवेश नहीं करना चाहते हैं ...

नीचे कुछ अच्छे उपकरण दिए गए हैं, पहले स्थानीय वाईफाई नेटवर्क के भीतर कनेक्टिविटी स्वास्थ्य को समझने के लिए, और फिर एक इंटरनेट एंडपॉइंट के लिए।

वाईफ़ाई उपकरण

नेटस्पॉट (मैक के लिए)

यह स्थानीय वाईएफआई एपी को ट्रैक करता है और एसएनआर, चैनल, सिग्नल स्ट्रेंथ जैसे बुनियादी डेटा प्रदान करता है। यह ताकत और हस्तक्षेप का संकेत देने वाले भौतिक स्थान के लिए एक मूल साइट सर्वेक्षण भी कर सकता है। एपी डिस्कवरी मोड में, आप समय के साथ सिग्नल की शक्ति को भी चार्ट कर सकते हैं, जिससे आप प्लेसमेंट का परीक्षण कर सकते हैं और हस्तक्षेप की संभावनाओं को समायोजित कर सकते हैं। यहाँ छवि विवरण दर्ज करें यहाँ छवि विवरण दर्ज करें यहाँ छवि विवरण दर्ज करें

Android के लिए वाईफ़ाई स्पीड टेस्ट

बहुत उपयोगी। आप अपनी मशीन पर एक साधारण अजगर सर्वर चलाएंगे और ऐप आपको रियलटाइम स्पीड फीडबैक देते हुए कुछ परिदृश्यों का परीक्षण कर सकता है।

यहाँ छवि विवरण दर्ज करें

एक अन्य शानदार एंड्रॉइड ऐप, वाईफाई एनालाइज़र में एपी वाईफाई चैनलों के सक्रिय होने के कुछ मूल्यवान विचार हैं। बहुत सारे काम किए बिना एपी चैनल चुनने के लिए सबसे अच्छा मुफ्त उपकरण हो सकता है।

iperf

स्थानीय नेटवर्क प्रदर्शन को समझने के लिए अच्छी तरह से सम्मानित उपकरण। आपको दो बॉक्स चाहिए, एक सर्वर के रूप में, एक क्लाइंट के रूप में। आप कई पैरामीटर सेट कर सकते हैं, एक परीक्षण चला सकते हैं, और बैंडविड्थ और घबराना के लिए परिणाम देख सकते हैं। मैं परिणामों और टर्निंग मापदंडों के लिए jPerf GUI के साथ इसका उपयोग करने के लिए बाध्य हूं

brew install iperf
iperf -s # on server, next one on client
iperf -c 192.168.1.XXX -P 1 -i 1 -p 5001 -f m -t 60

यहाँ छवि विवरण दर्ज करें

इंटरनेट कनेक्टिविटी स्वास्थ्य

mtr (पिंग और ट्रेसरआउट संयुक्त)

अपने सभी ट्रेसरआउट हॉप्स को पिंग करता है। ट्रेंड डेटा प्रदान करता है। पागल कमाल का।

brew install mtr
mtr 8.8.4.4

speedtest-CLI

आम ookla speedtest.net चीज का सीएलआई संस्करण। परियोजना अनुरक्षक घोषित करता है कि यह सुसंगत नहीं है, लेकिन फिर भी, बड़े अंतरों को नापने का प्रयास करना आसान है।

wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
chmod +x speedtest-cli
speedtest-cli --list | head # and chose a top server (sorted by distance)
speedtest-cli --server 2761 # re-use the same server

एनपीएडी : नेटवर्क पथ और अनुप्रयोग निदान

एंड-सिस्टम और अंतिम-मील नेटवर्क समस्याओं के निवारण के लिए स्वचालित नैदानिक ​​सर्वर। परीक्षणों की बैटरी चलाने के बाद, इस तरह एक परिणाम सारांश पृष्ठ देता है । मैं सबसे नज़दीकी NPAD सर्वर (वे सब खत्म हो चुके हैं) को खोजने के लिए इस NPAD सर्वर रीडायरेक्ट लिंक का उपयोग करने की सलाह देते हैं और अपने परीक्षणों के लिए उस होस्टनाम का उपयोग कर रहे हैं।

  wget http://netspeed.usc.edu:8000/diag-client.c
  cc diag-client.c -o diag-client
# ./diag-client <server_name> <port> <target_RTT> <target_data_rate_in_MB/S>
  ./diag-client ps.psc.xsede.org 8001 30 5

यहाँ छवि विवरण दर्ज करें


मेरे व्यक्तिगत परिणाम:

मैंने यह सब करने में कुछ घंटे बिताए, अलग-अलग चीजों की कोशिश कर रहा था (डीडी-डब्ल्यूआरटी से टमाटर फर्मवेयर पर स्विच करना) और पढ़ना। पता चला कि यह नेटवर्क लेयर नहीं था और ज्यादातर ब्लूटूथ से अच्छा पुराना आरएफ हस्तक्षेप था! मेरे पास मेरा कंप्यूटर, 5 फीट के राउटर के भीतर एक ब्लूटूथ माउस और कीबोर्ड था। (और पुराने रूटर अभी भी 2.4Ghz पर हैं जहां वे टकराते हैं।)

इसके लिए, मुझे एंड्रॉइड के लिए सबसे अधिक वाईफ़ाई स्पीड टेस्ट मिला , जो नियमित रूप से चल रहा था जबकि मैंने अपार्टमेंट में चीजों को घुमाया। चूंकि यह रिपोर्ट हर 200ms या तो अपडेट करता है, यह स्पष्ट रूप से संचारित किया गया था जब हस्तक्षेप मेरे पैकेट को गिरा रहा था।

मैं निश्चित रूप से Metageek से हस्तक्षेप गाइड के सामान्य स्रोतों को पढ़ने की सलाह देता हूं। (वे InSSIDer और अन्य वाईफ़ाई विश्लेषण उपकरण भी बनाते हैं जो अच्छे लगते हैं।)

यहाँ छवि विवरण दर्ज करें

एक उपकरण जो मेरे पास नहीं था वह एक भौतिक स्पेक्ट्रम विश्लेषण मीटर था। फ़ोन और लैपटॉप केवल वाईफ़ाई एपी का पता लगा सकते हैं, लेकिन ब्लूटूथ या अन्य आरएफ-आधारित प्रौद्योगिकियों के हस्तक्षेप पर नहीं उठा सकते हैं। मेटेजेक के पास इस स्पेस ( वाई-स्पाई और इनसाइडर ऑफिस ) में कुछ अच्छे समाधान हैं और उम्मीद है कि हमें एयरशर्क की तरह और भी उपकरण उभर कर सामने आएंगे


ये सुंदर उपकरण हैं, मेरे नोट्स को अपडेट कर रहे हैं।
जेफ क्लेटन

एक और "त्वरित और गंदा" उपकरण जो अमूल्य है क्योंकि इसका पोर्टेबल Android उपकरणों के लिए वाईफ़ाई विश्लेषक है।
दाविदगो

ऐ। मैंने वाईफाई विश्लेषक का संक्षेप में उल्लेख किया है; यह एपी चैनल के हस्तक्षेप को समझने के लिए सबसे अच्छा साधन हो सकता है, हालांकि मेरे मामले में, यह एक मुद्दा नहीं था। उस ने कहा, यह वास्तव में अच्छी तरह से किया है।
पॉल आयरिश

महान सूची, धन्यवाद। एक और चीज हमेशा कोशिश करना है कि वाईफाई के बिना क्या होता है । एक बार जब मुझे लगा कि मुझे एक वाईफ़ाई समस्या है, लेकिन वाईफ़ाई एपी को खिलाने और सीधे iPerf चलाने वाले केबल में प्लग करने से खराब केबल का असली अपराधी के रूप में पता चला!
रायन डेलुगोज

1
Hmmmm। ब्लूटूथ आपके द्वारा वर्णित हस्तक्षेप के प्रकार का कारण होने की संभावना नहीं है, यह सामान्य रूप से है एएफएस hopping पैटर्न 2.4GHz में एक सामान्य 20MHz वाई-फाई सिग्नल से बचना होगा। आप 40Mhz चैनल नहीं चला रहे थे?
अल्फवाट

4

जैसा कि ऊपर मेरी टिप्पणी में उल्लेख किया गया है: आमतौर पर वाई-फाई मुद्दों के निदान के लिए उपयोग किए जाने वाले उपकरण वास्तव में इस समस्या का कारण बन सकते हैं। वाई-फाई नेटवर्क के लिए स्कैन करते समय रेडियो को चैनल से दूर जाना पड़ता है, आमतौर पर यह एपी को बफर फ्रेम के लिए बताता है इसलिए यह 'स्लीप' कर सकता है फिर स्कैन करने के लिए चैनल स्विच करता है।

इसके अतिरिक्त, AirDrop पेश करने के बाद से iOS और OS X, अन्य AirDrop सेवाओं की तलाश के लिए Wi-Fi रेडियो को बंद कर देगा और चूंकि Yosemite समय-समय पर हैंडऑफ का समर्थन करने के लिए चैनल से दूर चला जाएगा।


1
महान बिंदु - मैंने अतीत में InSSIDer का उपयोग करके इस समस्या पर ध्यान दिया है - इसके लिए स्पष्टीकरण प्राप्त करने के लिए अच्छा है।
निक

3

इसलिए मेरे पास राउटर के लिए वाई-फाई पिंग उतार-चढ़ाव भी था।

PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: icmp_seq=0 ttl=63 time=2.334 ms
64 bytes from 192.168.0.1: icmp_seq=1 ttl=63 time=1.813 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=63 time=2749.664 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=63 time=1748.912 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=63 time=748.162 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=63 time=1.796 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=63 time=1.806 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=63 time=1.991 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=63 time=1.797 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=63 time=1.832 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=63 time=1.713 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=63 time=1.819 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=63 time=1.616 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=63 time=1.748 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=63 time=1.677 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=63 time=3427.213 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=63 time=2426.371 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=63 time=1425.634 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=63 time=424.834 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=63 time=1.829 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=63 time=1.691 ms
64 bytes from 192.168.0.1: icmp_seq=21 ttl=63 time=2.038 ms
64 bytes from 192.168.0.1: icmp_seq=22 ttl=63 time=1.679 ms
^C--- 192.168.0.1 ping statistics ---
23 packets transmitted, 23 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.616/564.346/3427.213/1015.102 ms

मैंने राउटर को स्विच किया (TL-WR743ND से DIR-815 तक), कई वाई-फाई यूएसबी एडेप्टर (ज्यादातर टीपी-लिंक की कोशिश की, हालांकि मुझे लगता है कि मेरे पास डी-लिंक डीडब्ल्यूए -160 भी था), 2.5 गीगाहर्ट्ज पर चला गया। 5GHz और चैनलों को परिमार्जन किया। भाग्य नहीं, समस्या बनी रही।

जब तक मैंने देखा कि जब मैं एक नेटवर्क स्पीड टेस्ट करता हूं या बिटटोरेंट क्लाइंट चलाता हूं तो पिंग बिल्कुल ठीक है। नेटवर्क में निष्क्रिय होने पर ही इसमें उतार-चढ़ाव आता है।

विंडोज 7 का मुद्दा हो सकता है या मेरे टीपी-लिंक एडेप्टर के साथ एक चीज हो सकती है, लेकिन जब मैं वाई-फाई पर थोड़ा लोड देता हूं तो उतार-चढ़ाव गायब हो जाता है और नेटवर्क ठीक काम करता है।

अब तक मैंने अपने वाई-फाई नेटवर्क को बनाए रखने के लिए थोड़ा रस्ट प्रोग्राम बनाया है।

// Need a constant wifi load in order not to have the ping drops.
fn wifi_load() {
  // This *might* be useful if the router suddenly supports Keep-Alive.
  // Not the case with DIR-815 though, we'll keep making new connections to it.
  let config = hyper::client::pool::Config {max_idle: 1};

  let client = hyper::client::Client::with_pool_config (config);
  loop {
    let url = "http://192.168.0.1/css/init.css";
    if let Err (err) = client.get (url) .send() {
      log! ("wifi_load] Error fetching {}: {}", url, err);
      sleep (Duration::from_secs (9));}
    sleep (Duration::from_millis (100));}} 
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.