Wi-Fi की स्पीड जितनी तेज़, गुणवत्ता उतनी खराब क्यों होती है

 (orb.net)
12 पॉइंट द्वारा GN⁺ 2025-10-12 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • 5 GHz बैंड में 20/40 MHz की संकीर्ण चैनल चौड़ाई का उपयोग सबसे अच्छा अनुभव देता है, लेकिन उपभोक्ता उत्पाद डिफ़ॉल्ट रूप से 80MHz या उससे अधिक की चौड़ी चैनल चौड़ाई इस्तेमाल करते हैं, जिससे interference और latency बढ़ती है
  • उपभोक्ता ज़्यादा स्पीड को पसंद करते हैं, इसलिए निर्माता/ISP को डर रहता है कि अगर वे संकीर्ण चैनल सेटिंग के साथ उत्पाद लॉन्च करें तो benchmark रैंकिंग गिर सकती है, इस वजह से वे चौड़े चैनल पर टिके रहते हैं
  • Wi-Fi स्पीड टेस्ट करना भी नेटवर्क की shared bandwidth खर्च करता है, जिससे responsiveness घटती है और नेटवर्क के दूसरे डिवाइस latency और packet loss झेलते हैं
  • IEEE का अगला Wi-Fi 8(802.11bn) स्पीड से अधिक reliability और responsiveness सुधारने पर केंद्रित है, लेकिन 2028 तक भी इसके standardization के पूरा होने की संभावना नहीं है
  • अभी तैनात हार्डवेयर में सिर्फ़ सेटिंग बदलने से भी काफ़ी सुधार संभव है

संकीर्ण चैनल चौड़ाई का महत्व

  • enterprise नेटवर्क बड़े क्षेत्र और कई डिवाइस कनेक्शन को सपोर्ट करने के लिए 20MHz~40MHz चैनल चौड़ाई का उपयोग करते हैं
    • इससे अधिक चैनल उपलब्ध होते हैं और co-channel interference से बचा जा सकता है
  • घरों और छोटे व्यवसायों का Wi-Fi भी enterprise नेटवर्क से बहुत अलग नहीं है: अमेरिका के औसत घर में 21 Wi-Fi डिवाइस होते हैं
    • प्रभावी coverage के लिए कई घरों में multiple mesh nodes या access points की ज़रूरत होती है
  • लेकिन घरेलू router या ISP उपकरण डिफ़ॉल्ट रूप से अक्सर 80MHz या उससे अधिक का उपयोग करते हैं, जिससे वे पूरे बैंड का 2/3 हिस्सा घेर लेते हैं
    • कुछ 2.4GHz उपकरण केवल 40MHz की अनुमति देते हैं, इसलिए उपयोगकर्ता उन्हें और संकीर्ण भी नहीं कर सकता

‘स्पीड पर आसक्ति’ की समस्या

  • इन सेटिंग्स की वजह यह है कि उपभोक्ता Wi-Fi गुणवत्ता = स्पीड मानते हैं और स्पीड के अलावा दूसरे कारकों पर ध्यान नहीं देते
    • responsiveness और reliability जैसे ज़्यादा महत्वपूर्ण internet experience metrics की तुलना में वे सिर्फ़ स्पीड पर फोकस करते हैं
  • निर्माता और ISP स्पीड टेस्ट स्कोर को लेकर संवेदनशील रहते हैं, इसलिए डिफ़ॉल्ट सेटिंग में चौड़े चैनल बनाए रखते हैं
    • संकीर्ण चैनल का उपयोग करने पर वास्तविक अनुभव बेहतर हो सकता है, लेकिन स्पीड का आँकड़ा कम दिखेगा, जिससे return rate बढ़ने का डर रहता है
  • नतीजतन, responsiveness और stability की जगह maximum throughput पर ज़ोर देने वाली संरचना बनी रहती है

स्पीड टेस्ट का उल्टा असर

  • Wi-Fi airtime contention संरचना पर काम करता है, इसलिए एक समय में केवल एक डिवाइस ही transmission कर सकता है
    • इसलिए जब एक डिवाइस पर स्पीड टेस्ट चलता है, तो दूसरे डिवाइसों की latency और packet loss बढ़ जाती है
  • प्रयोगों में पाया गया कि उसी नेटवर्क पर अगर कोई दूसरा डिवाइस स्पीड टेस्ट चलाता है, तो latency, jitter, और packet loss सभी बढ़ जाते हैं
    • यही टेस्ट wired connection(ethernet) पर करने पर ऐसा असर नहीं दिखता
  • ज़्यादातर consumer उपकरणों में buffer bloat कम करने वाले फीचर बंद रहते हैं, जिससे स्थिति और खराब हो जाती है
  • स्पीड मापने वाले tools या automated speed measurement systems खुद उपभोक्ता के वास्तविक अनुभव की गुणवत्ता गिराने वाले बड़े कारण बन सकते हैं

IEEE 802.11bn (Wi-Fi 8) का नया दृष्टिकोण: responsiveness और reliability की ओर बदलाव

  • अमेरिका के 68% घरों ने पिछले एक साल में Wi-Fi समस्या का अनुभव किया
  • IEEE Wi-Fi 8(802.11bn) standard मौजूदा स्पीड-केंद्रित सोच से हटकर
    • reliability, कम latency (95th percentile के आधार पर), packet loss को न्यूनतम करना, और interference वाले माहौल में robustness को लक्ष्य बनाता है
    • लेकिन यह standard 2028 तक जाकर ही अंतिम रूप लेगा
  • Wi-Fi 6E और 7 द्वारा उपयोग किया जाने वाला 6GHz बैंड अधिक चौड़े चैनल देता है, लेकिन
    • डिवाइस अपनाने की दर कम है, और यह channel sharing की मूल समस्या को हल नहीं करता

समाधान और सुझाव

  • Wi-Fi 6E और 7 के व्यापक प्रसार या Wi-Fi 8 के अभी-अधूरे वादों का इंतज़ार करने की ज़रूरत नहीं है
    • पहले से तैनात हार्डवेयर में सिर्फ़ सेटिंग बदलकर ही कहीं बेहतर performance हासिल की जा सकती है
    • सिर्फ़ maximum throughput का पीछा छोड़कर Wi-Fi responsiveness और reliability पर ध्यान देना चाहिए
  • स्पीड टेस्ट उपयोगी tool है, लेकिन उस पर अत्यधिक निर्भरता उल्टा गुणवत्ता घटा सकती है
  • उपभोक्ता वास्तव में तेज़ responsiveness और stability चाहते हैं, लेकिन इसे मापने के लिए tools और data की कमी है
  • निर्माता और ISP को नए metrics अपनाकर continuous network experience(Responsiveness & Reliability) पर ज़ोर देना चाहिए
  • मौजूदा हार्डवेयर के साथ भी साधारण सेटिंग बदलाव से ज़्यादा स्थिर Wi-Fi वातावरण बनाया जा सकता है

संबंधित पढ़ाई

2 टिप्पणियां

 
GN⁺ 2025-10-12
Hacker News राय

  • UniFi hub के साथ प्रयोग करने पर पता चला कि हर डिवाइस को अलग WiFi चैनल देना आदर्श है। इंटरफेरेंस इतना गंभीर होता है कि चैनल टकरा न रहे हों तो, प्रदर्शन गिरने वाले माहौल में भी नतीजे कहीं बेहतर मिलते हैं। साथ ही, वायरलेस वातावरण को तेज़ करने का सबसे अच्छा तरीका है कि जहाँ संभव हो WiFi का उपयोग कम किया जाए, और TV जैसे न चलने वाले डिवाइसों ko सीधे Ethernet से जोड़ देने पर WiFi की भीड़ और गति में गिरावट को प्रभावी ढंग से कम किया जा सकता है

    • स्मार्टफोन या डेस्क से बँधे न रहने वाले लैपटॉप के अलावा बाकी सभी डिवाइसों को Ethernet से जोड़ना आदर्श है। 2020 में video conferencing बढ़ने के बाद घर के भीतर सीधे Ethernet wiring करवाई, और उपयोगिता काफी बेहतर हो गई

    • IoT डिवाइस अक्सर धीमे WiFi chipset और पुराने standards का उपयोग करते हैं, इसलिए उन्हें अलग 2.4GHz-only SSID पर रखना एक प्रभावी तरीका है। इससे पुराने और धीमे डिवाइस 5GHz की अच्छी quality को खराब नहीं करते। साथ ही, अधिक wireless routers लगाकर wired backhaul का उपयोग करने पर डिवाइस पास के AP से अधिक कुशलता से जुड़ पाते हैं, जिससे WiFi काफी अधिक stable हो जाता है। घर के सभी स्थिर डिवाइसों को wired करने और tuning के बाद wireless quality बहुत बेहतर हो गई

    • iPhone/iPad को भी Ethernet adapter से जोड़ा जा सकता है, और बड़े downloads के समय काम बहुत तेज़ी से हो सकता है। लेकिन अफसोस है कि कई consumer electronics wired connection को support नहीं करते। घनी शहरी apartment इमारतों में wireless वास्तव में नुकसानदेह विकल्प है, और कई डिवाइस आसपास के networks के डिवाइस ज़रूरत से ज़्यादा दिखाते हैं या असामान्य रूप से WiFi बंद नहीं कर पाते, यह भी असुविधाजनक है

    • नेटवर्क पर traffic न होने वाले idle Wi-Fi clients quality पर लगभग कोई असर नहीं डालते। असली समस्या वे डिवाइस हैं जो सक्रिय उपयोग में हों या जिनमें background traffic अधिक हो, जैसे smart TV। IoT नेटवर्क में अधिकतर डिवाइसों की internet access बंद करके background traffic कम किया जाता है। इसके अलावा, कुल मिलाकर AP coverage बढ़ाना, wired backhaul का उपयोग करना, और बेहतर equipment (जैसे Ubiquiti/UniFi) पर जाना ही अधिकांश WiFi समस्याओं में बड़ा सुधार ला सकता है। यदि mesh WiFi का उपयोग कर रहे हों तो 6GHz backhaul की सिफारिश है, लेकिन दूरी की coverage कुछ कम हो जाती है

    • wired installation सबसे आक्रामक और शक्तिशाली समाधान है। लेकिन यदि WiFi का सक्रिय रूप से उपयोग करना ही हो, तो dedicated backhaul वाले कई AP लगाकर optimization किया जा सकता है। इस तरीके से 60 से अधिक डिवाइसों को आराम से roaming और तेज़ speed बनाए रखते हुए चलाया है। UniFi आधारित setup था, लेकिन Eero PoE उपकरण भी इसी तरह अच्छा performance देते हैं

  • WiFi के खराब होने के कारणों में एक HP जैसी printers की WiFi Direct सुविधा भी है। आसपास signal scan करने पर पड़ोस की 5 से अधिक printers बहुत मज़बूत signal भेजती दिखती हैं। बड़े building environments में WiFi 6e का 6GHz channel ही व्यावहारिक रूप से उपयोगी होता है

  • लेख पढ़कर समझ नहीं आता कि व्यवहार में क्या करना चाहिए। क्या घर में channel width कम करने की बात है? वास्तव में असर दिखाने के लिए शायद काफी अधिक WAP चाहिए होंगे। apartments जैसी जगहों में channel width से ज़्यादा TX power कम करने की सलाह अधिक व्यावहारिक लगती है। लेकिन सभी ऐसा नहीं करेंगे, इसलिए कानूनी सीमा के भीतर रहना ही सर्वोत्तम है। high performance चाहिए तो डिवाइस को मूलतः wired ही होना चाहिए। अगर WiFi optimization पर समय लगाने का इरादा है तो wiisfi.com वास्तव में बहुत अच्छा resource है

    • मुख्य बात यह है कि 5GHz channel width को 40Mhz तक घटाकर और 2.4GHz को 20MHz पर रखकर reliability बढ़ाई जा सकती है। अगर निर्माता यह default के रूप में सही सेट कर दें तो सभी उपयोगकर्ताओं को फायदा होगा, लेकिन अभी home routers में सामान्यतः बहुत चौड़ी channel width default रहती है। हाँ, अगर आपके environment में समस्या नहीं है तो इसे बदलने की ज़रूरत नहीं

    • ऐसी settings केवल समस्या होने पर ही ध्यान देने लायक हैं। अधिकांश मामलों में modern WiFi के resources इतने पर्याप्त हैं कि बड़ा अंतर महसूस नहीं होता, और केवल बहुत ही अपवादस्वरूप भारी file transfer में थोड़ा slowdown दिखेगा, इसलिए सिर्फ इसके लिए अतिरिक्त cabling जोड़ने की ज़रूरत महसूस नहीं होती

    • 2.4GHz पर 40MHz उपयोग करना उपलब्ध channels के आधे हिस्से पर कब्ज़ा करने जैसा है, इसलिए speed बढ़ने से अधिक channel pollution गंभीर हो सकता है। अगर आसपास बिना सोचे-समझे 8 या 9 नंबर channel उपयोग करने वाले डिवाइस बढ़ जाएँ, तो बाकी band भी जल्दी प्रदूषित हो जाता है और IoT डिवाइस मुश्किल से signal पकड़ पाते हैं। 20MHz पर भी सही placement के साथ 70Mbps से अधिक मिलता था, लेकिन यह घटकर केवल 30Mbps रह सकता है। कई लोग साथ उपयोग करें तो FaceTime तक के लिए 5GHz force करना या WiFi बंद करना पड़े, ऐसी स्थिति हो सकती है

    • मेरे यहाँ भी 80MHz 5GHz environment में bedroom का WiFi connection बार-बार टूटता था, लेकिन आज ही इसे 20MHz पर घटाया तो signal-to-noise ratio लगभग 5dB बढ़ गया और bedroom connection फिर संभव हो गया। latency थोड़ी बढ़ी है, लेकिन असर स्पष्ट महसूस हुआ

    • सुझाया गया resource वास्तव में बहुत उपयोगी है, काश यह पहले पता होता

  • यह याद दिलाता है कि हाल के WiFi optimization में वास्तविक user experience के बजाय सिर्फ़ कागज़ी maximum speed पर ज़ोर देने वाली 'speed spec competition' हावी रही है। यह कुछ वैसा है जैसे पहले digital cameras में 'megapixel war' हुआ करती थी। रोज़मर्रा के उपयोग में वास्तव में महत्वपूर्ण चीज़ responsiveness और reliability है, लेकिन इन metrics को quantify करना कठिन है और product packaging पर दिखाया भी नहीं जाता। उल्टा, speed test खुद नेटवर्क performance को और खराब कर सकता है, यह भी विडंबना है। आगे routers और ISP speed metrics की जगह responsiveness जैसे वास्तविक अनुभव-आधारित scores देंगे या नहीं, यह अभी स्पष्ट नहीं है। मूल समस्या network culture की है; industry बेहतर अनुभव के बजाय केवल पूजनीय numbers के पीछे भागती रही है

    • यह जानने की उत्सुकता है कि वास्तविक throughput wireless 'airtime' के उपयोग और optimization को कैसे प्रभावित करता है, और कम PHY rates पर यह संबंध कैसे बदलता है

  • Apple केवल speed मापने के बजाय network quality को अधिक सटीक ढंग से आँकने का तरीका प्रस्तावित कर रहा है। यह network-quality/goresponsiveness नाम का spec है, और हाल के Mac में networkQuality नाम का CLI tool built-in आता है। यह tool idle और load दोनों स्थितियों में 'round trips per minute' मापता है। यह इंटरनेट के वास्तविक अनुभवजन्य आराम, यानी तेज़ responsiveness और तुरंत response, का साधारण speed tests की तुलना में बेहतर अनुमान देता है, इसलिए व्यावहारिक उपयोगिता भी अधिक है

  • क्योंकि मापना आसान 'speed' ही सारा ध्यान खींच लेती है, अंततः सभी stakeholders speed पर ही अटक जाते हैं। लंबे समय तक networking क्षेत्र में काम करते हुए मेरा अनुभव है कि users हर समस्या को speed की कमी मानते हैं, जबकि एक निश्चित स्तर के बाद वह अक्सर केवल मनोवैज्ञानिक संतुष्टि भर होती है

  • IEEE 802.11bn(Wi-Fi 8) working group में भी spec के लक्ष्य को केवल speed बढ़ाने के बजाय reliability, low latency (खासकर 95th percentile के आधार पर), packet loss में कमी, interference/mobility से निपटना आदि के रूप में फिर से परिभाषित किया जा रहा है। लेकिन industry अनुभव कहता है कि नई features हर generation में तुरंत ठीक से लागू नहीं होतीं; WiFi 6 की मुख्य features सच में WiFi 7 पर जाकर, और WiFi 7 की features WiFi 8 पर जाकर सही से चलती हैं। इसलिए किसी generation द्वारा लाई गई features को वास्तव में स्थिर रूप से काम करने में एक generation और लग जाता है। फिर भी आज का WiFi वास्तविक 1Gbps से आगे बढ़कर 2.5Gbps से अधिक effective performance दे रहा है, और reliability तथा efficiency के मामले में हर साल उल्लेखनीय प्रगति कर रहा है

  • यह सुनकर आश्चर्य हुआ कि कई ISP, device manufacturers और consumers नियमित रूप से automated speed tests चलाते हैं, और इससे पूरे consumer internet experience पर नकारात्मक असर पड़ता है। सच में यह जानना है कि जानबूझकर ज़रूरत से अधिक load बनाने की वजह क्या है

    • उदाहरण के तौर पर SamKnows नाम की एक कंपनी है, जो लाखों घरों से performance data इकट्ठा करती है और हाल ही में Cisco द्वारा अधिग्रहण की घोषणा की गई है। संबंधित लेख: Cisco, SamKnows acquisition announcement

    • अधिकांश ISP ऐसे speed tests केवल अपने internal network के भीतर चलाते हैं, इसलिए वास्तविक traffic load पर असर कम पड़ता है। ऐसा इसलिए कि सिर्फ internal traffic उपयोग करके numbers बढ़ा-चढ़ाकर दिखाए जा सकते हैं और external links का उपयोग न होने से कंपनी के लिए bhi कोई समस्या नहीं होती। वास्तव में मेरे ISP के एक network operator ने मुझे यह सिद्धांत समझाया था, तब जाकर बात समझ आई

    • speed test के बारे में जानने वाले लोग ही बहुत कम हैं, और अधिकांश consumers में इसे automate करके चलाने की क्षमता भी शायद नहीं होगी

  • WiFi में सबसे असंतोषजनक हिस्सा roaming है। घर मोटी दीवारों (अधिकतम 120cm) से बना है, इसलिए लगभग हर कमरे में AP चाहिए। काफी optimization करने के बाद भी अब तक पूरी तरह seamless roaming का अनुभव नहीं हुआ। TP-Link Omada उपकरणों पर बदलने के बाद स्थिति पहले से कुछ बेहतर हुई, लेकिन फिर भी DECT cordless phone जैसी बिना रुकावट switching नहीं मिलती। उदाहरण के लिए कमरे में Twitch देखते हुए रसोई तक जाएँ तो लगभग 30% संभावना रहती है कि playback freeze हो जाए, और गंभीर स्थिति में WiFi बंद करके फिर चालू करना पड़ता है। channel, overlap आदि के सभी tips आज़मा लिए, लेकिन अभी भी यह पूरी तरह flawless नहीं है

    • DECT cordless phone 1.9GHz band का उपयोग करते हैं, इसलिए 2.4GHz WiFi की तुलना में पानी से signal loss कम होता है और कई materials को बेहतर पार कर लेते हैं। समस्या अक्सर इसलिए होती है कि लोग WiFi repeater/relay को गलत जगह रखते हैं या multi-radio के बिना सस्ते उपकरण लेते हैं। अगर repeater या mesh उपकरण single radio वाले हों तो हर hop पर speed आधी रह जाती है। ISP चलाने के नज़रिए से देखें तो ग्राहक हमेशा घर के wireless network पर पैसा बचाना चाहते हैं, इसलिए उसके परिणाम और कारण समझाना आसान नहीं होता

    • मैं भी इसी तरह की संरचना वाली इमारत में रहता हूँ, इसलिए परेशानी समझ सकता हूँ। लेकिन AP को wired backhaul से जोड़कर, channel overlap हटाकर, 2.4GHz को 20MHz और 5GHz को 40MHz तक सीमित रखकर, 2.4GHz में केवल 1, 6, 11 channels का उपयोग करके, 5GHz में DFS channels से बचकर, और ज़रूरत पड़ने पर हर AP की transmit power कम करके ताकि वे दूर से overlap न करें, समस्या लगभग हल हो गई। 2.4GHz को ज़रूरत के अनुसार कुछ AP पर बंद करना भी एक तरीका है

    • ज़्यादातर calls के लिए मैं DECT VoIP phone उपयोग करता हूँ और इससे संतुष्ट हूँ

  • अगला WiFi standard 802.11bn(WiFi 8) Ultra High Reliability(UHR) उपनाम के साथ आ रहा है। संदर्भ लिंक: 802.11bn Wikipedia। अब रुझान यह है कि speed के अलावा अन्य variables को भी अधिक गंभीरता से लिया जाए

    • WiFi कितना भी सुधर जाए, radio एक shared medium ही है। Ethernet की तरह हर pair को पूरी bandwidth स्वतंत्र रूप से देकर reuse नहीं किया जा सकता। Ethernet की reliability की तुलना में wireless में स्थिरता की एक बुनियादी सीमा हमेशा रहेगी
 
galadbran 2025-10-12

मैं KT का Giga Wi-Fi इस्तेमाल करता हूँ। चैनल बैंड 80MHz पर सेट था, इसलिए उसे 40MHz में बदलकर macOS के networkQuality नतीजों की तुलना की। मेरे मामले में 40MHz पर बदलते ही responsiveness भी और कुल performance भी काफी गिर जाती है।