पूर्वी - पश्चिमी तट अमरीका के लिए "विशिष्ट" कितना नेटवर्क विलंबता है?

Question

फिलहाल हम यह तय करने की कोशिश कर रहे हैं कि क्या हमारे डेटासेंटर को पश्चिमी तट से पूर्वी तट तक ले जाना है या नहीं।

हालाँकि, मैं अपने पश्चिमी तट स्थान से पूर्वी तट तक की कुछ अशांत संख्या देख रहा हूँ। यहाँ एक नमूना परिणाम है, Google क्रोम में एक छोटी। Png लोगो फ़ाइल को पुनः प्राप्त करना और देव उपकरण का उपयोग करके यह देखने के लिए कि अनुरोध में कितना समय लगता है:

• पश्चिम तट से पूर्वी तट:
  215 एमएस विलंबता, 46 एमएस स्थानांतरण समय, 261 एमएस कुल
• पश्चिमी तट से पश्चिमी तट:
  114 एमएस विलंबता, 41 एमएस स्थानांतरण समय, 155 एमएस कुल

यह समझ में आता है कि कोर्वलिस, या भौगोलिक रूप से बर्कले, सीए में मेरे स्थान के करीब है, इसलिए मुझे कनेक्शन थोड़ा तेज होने की उम्मीद है .. लेकिन जब मैं एनवाईसी के लिए एक ही परीक्षण करता हूं, तो मुझे +100 मीटर की विलंबता में वृद्धि दिखाई दे रही है। सर्वर। ऐसा लगता है .. मेरे लिए अत्यधिक। विशेष रूप से समय बीतने के बाद से वास्तविक डेटा केवल 10% बढ़ गया, फिर भी विलंबता 100% बढ़ गई!

मुझे लगता है कि ... गलत ... मेरे लिए।

मुझे यहाँ कुछ लिंक मिले जो सहायक थे (Google के माध्यम से कम नहीं!) ...

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

... लेकिन आधिकारिक कुछ भी नहीं।

तो, क्या यह सामान्य है? यह सामान्य महसूस नहीं करता है। संयुक्त राज्य अमेरिका के पूर्वी तट <-> के पश्चिमी तट से नेटवर्क पैकेट ले जाने पर मुझे "विशिष्ट" विलंबता की अपेक्षा करनी चाहिए?

Comments

नेटवर्क पर कोई भी माप जिसे आप नियंत्रित नहीं करते हैं वह लगभग व्यर्थ प्रतीत होता है। इस प्रकार के नेटवर्क चर्चा में अक्सर ऐसा लगता है कि हम भूल जाते हैं कि हर पैकेट के साथ एक अस्थायी घटक जुड़ा हुआ है। यदि आप 24 x 7 बार बार परीक्षण चलाते हैं और किसी निष्कर्ष पर पहुंचे हैं जो एक बात है। यदि आपने दो बार परीक्षण चलाया तो मेरा सुझाव है कि आप इसे कुछ और चलाएं। और प्रदर्शन के कुछ उपाय के रूप में पिंग के उपयोग की वकालत करने वालों को नहीं। मैंने कभी भी काम किया हर बड़े नेटवर्क पर हमने ICMP ट्रैफिक को सबसे कम प्राथमिकता पर सेट किया। पिंग का मतलब केवल एक चीज है, और यह प्रदर्शन के बारे में नहीं है;)।

— dbasnett

जहां मैं रहता हूं, वहां से जेफरसन सिटी, एमओ, समय समान हैं।

— dbasnett

साइड नोट के रूप में: NY से SF तक सीधी रेखा में यात्रा करने के लिए प्रकाश को ~ ~ 14ms लगते हैं (रास्ते में फाइबर पर विचार करते हुए)।

— शादोक

फाइबर में प्रकाश .67 (अपवर्तक सूचकांक के बराबर) के वेग कारक के साथ यात्रा करता है ~ 201,000 किमी / सेकंड, इसलिए यह कम से कम 20 एमएस है।

— Zac67

Answer 1

प्रकाश की गति:
आप एक दिलचस्प शैक्षणिक बिंदु के रूप में प्रकाश की गति को हरा नहीं रहे हैं। यह लिंक स्टैंफोर्ड से बोस्टन में ~ 40ms सर्वोत्तम समय पर काम करता है। जब इस व्यक्ति ने गणना की तो उसने तय किया कि इंटरनेट "प्रकाश की गति के दो के एक कारक के भीतर" पर काम करता है, इसलिए लगभग ~ 85ms स्थानांतरण समय है।

टीसीपी विंडो का आकार:
यदि आप ट्रांसफर स्पीड की समस्या से जूझ रहे हैं तो आपको प्राप्त करने वाली विंडो टीसीपी के आकार को बढ़ाने की आवश्यकता हो सकती है। यदि आप उच्च विलंबता (जिसे "लॉन्ग फैट पाइप कहा जाता है) के साथ एक उच्च बैंडविड्थ कनेक्शन है, तो आपको विंडो स्केलिंग सक्षम करने की आवश्यकता हो सकती है। इसलिए यदि आप एक बड़ी फ़ाइल स्थानांतरित कर रहे हैं, तो आपको विंडो अपडेट के लिए इंतजार किए बिना पाइप को भरने के लिए एक बड़ी पर्याप्त खिड़की प्राप्त करने की आवश्यकता है। मैं अपने विवरण ट्यूनिंग ए एलीफैंट में गणना करने के तरीके पर कुछ विस्तार में गया ।

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

सबसे पहले, भले ही अधिकांश ग्राहकों को भौगोलिक रूप से पास के सीडीएन नोड द्वारा सेवा दी जाती है, लेकिन ग्राहकों का एक बड़ा हिस्सा उसी क्षेत्र के अन्य ग्राहकों की तुलना में कई दसियों मिलीसेकंड का कई गुना अनुभव करता है। दूसरा, हम पाते हैं कि कतार में देरी अक्सर पास के सर्वर के साथ बातचीत करने वाले ग्राहक के लाभों को ओवरराइड करती है।

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

whois -h v4-peer.whois.cymru.com "69.59.196.212"
PEER_AS | IP               | AS Name
25899   | 69.59.196.212    | LSNET - LS Networks
32869   | 69.59.196.212    | SILVERSTAR-NET - Silver Star Telecom, LLC

लिंकरक जैसे गाई टूल के साथ सहकर्मी के रूप में इनका पता लगाने में मज़ा आता है , यह आपको अपने आसपास के इंटरनेट की तस्वीर देता है।

Comments

सहमत हैं, कौवा मक्खियों के रूप में प्रकाश की गति सबसे अच्छा है जो आप संभवतः कर सकते हैं। वैसे, वास्तव में उत्कृष्ट जवाब, यह वही है जो मैं देख रहा था। धन्यवाद।

— जेफ एटवुड

जिज्ञासु के लिए वास्तविक गणित है: 3000 mi / c = 16.1ms

— tylerl

वैक्यूम में एक फोटॉन भूमध्य रेखा को लगभग 134 एमएस में यात्रा कर सकता है। ग्लास में एक ही फोटॉन लगभग 200 एमएस होगा। फाइबर के एक 3,000 मील टुकड़े में 24 एमएस है। बिना किसी उपकरण के देरी के।

— dbasnett

यह मुझे 500 मील ईमेल के मामले की याद दिलाता है ।

— बहमट

Answer 2

यह साइट पूर्व / पश्चिम तट के बीच लगभग 70-80ms विलंबता का सुझाव देगी। यूएस विशिष्ट है (उदाहरण के लिए सैन फ्रांसिस्को से न्यूयॉर्क)।

ट्रांस-अटलांटिक पथ
एनवाई 78 लंदन
87 फ्रैंकफर्ट धो लें

ट्रांस-पैसिफिक पथ
एसएफ 147 हांगकांग

ट्रांस-यूएसए पथ
एसएफ 72 एनवाई

यहां मेरी टाइमिंग हैं (मैं लंदन, इंग्लैंड में हूं, इसलिए मेरा वेस्ट कोस्ट टाइम पूर्व की तुलना में अधिक है)। मुझे 74ms विलंबता अंतर मिलता है, जो उस साइट से मूल्य का समर्थन करता है।

NY - 108ms latency, 61ms transfer, 169 total
OR - 182ms latency, 71ms transfer, 253 total

इन्हें Google Chrome dev टूल का उपयोग करके मापा गया था।

Comments

अच्छा चार्ट! एनवाई से एसएफ वर्तमान 71 msमें उस पर है, इसलिए आप सही हैं - हम इससे बेहतर करने की उम्मीद नहीं कर सकते।

— जेफ एटवुड

धन्यवाद। इसने मेरी बहुत मदद की। यह दुनिया के विभिन्न स्थानों के बीच नेटवर्क विलंबता को देखने के लिए एक और स्रोत है - dotcom-monitor.com/WebTools/network_latency.aspx

— साजिब महमूद

Answer 3

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

रिच एडम्स के उत्तर से जा रहे हैं और उस साइट का उपयोग करते हुए जिसकी उन्होंने सिफारिश की थी, आप देख सकते हैं कि एटी एंड टी की रीढ़ पर, आईसीएमपी ट्रैफिक को उनके एसएफ और एनवाई एंडपॉइंट के बीच स्थानांतरित करने के लिए 72 एमएस लगते हैं। यह एक उचित संख्या है, लेकिन आपको यह ध्यान रखना चाहिए कि यह एक ऐसे नेटवर्क पर है जो एटी एंड टी द्वारा पूरी तरह से नियंत्रित है। यह आपके घर या कार्यालय नेटवर्क में संक्रमण को ध्यान में नहीं रखता है।

यदि आप अपने स्रोत नेटवर्क से careers.stackoverflow.com के खिलाफ पिंग करते हैं, तो आपको 72 एमएस (शायद +/- 20 एमएस) से बहुत दूर नहीं देखना चाहिए। यदि ऐसा है, तो आप शायद यह मान सकते हैं कि आप दोनों के बीच का नेटवर्क पथ ठीक है और सामान्य सीमाओं के भीतर चल रहा है। यदि नहीं, तो घबराएं नहीं और कुछ अन्य स्थानों से मापें। यह आपका आईएसपी हो सकता है।

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

यदि उन HTTP समय का व्यापक विचलन है, तो मुझे आश्चर्य नहीं होगा कि धीमी प्रदर्शन करने वाली साइट पर कॉन्फ़िगरेशन समस्या थी।

अब, एक बार जब आप इस बिंदु पर होते हैं, तो आप यह देखने के लिए ऐप पक्ष में कुछ अधिक आक्रामक अनुकूलन करने का प्रयास कर सकते हैं कि क्या उन संख्याओं को कम किया जा सकता है। उदाहरण के लिए, यदि आप IIS 7 का उपयोग कर रहे हैं, तो क्या आप इसकी कैशिंग क्षमताओं आदि का लाभ उठा रहे हैं? शायद आप वहां कुछ जीत सकते हैं, शायद नहीं। जब यह निम्न स्तर की वस्तुओं जैसे कि टीसीपी विंडो को ट्विक करने की बात आती है, तो मुझे बहुत संदेह है कि इसका स्टैक ओवरफ्लो जैसी किसी चीज के लिए बहुत अधिक प्रभाव पड़ेगा। लेकिन हे - आप तब तक नहीं जान पाएंगे जब तक आप इसे नहीं आजमाते और मापते।

Answer 4

यहाँ कई उत्तर उनके स्पष्टीकरण के लिए पिंग और ट्रेसरआउट का उपयोग कर रहे हैं। इन उपकरणों में अपना स्थान है, लेकिन वे नेटवर्क प्रदर्शन माप के लिए विश्वसनीय नहीं हैं।

विशेष रूप से, (कम से कम कुछ) जुनिपर राउटर आईसीएमपी घटनाओं के प्रसंस्करण को राउटर के नियंत्रण विमान पर भेजते हैं। यह फ़ॉरवर्डिंग प्लेन की तुलना में MUCH धीमा है, खासकर एक बैकबोन राउटर में।

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

नतीजतन, पिंग / ट्रेसरआउट आपको उचित ऊपरी सीमा देते हैं - चीजें कम से कम तेजी से चल रही हैं - लेकिन वे वास्तव में आपको यह नहीं बताते हैं कि वास्तविक ट्रैफ़िक कितना तेज़ है।

किसी कार्यक्रम में -

यहां मिशिगन विश्वविद्यालय (मध्य अमेरिका) से स्टैनफोर्ड (पश्चिमी तट यूएस) तक एक उदाहरण ट्रेसरआउट है। (यह वाशिंगटन, डीसी (पूर्वी तट अमेरिका) के रास्ते से होता है, जो "गलत" श्रेणी में 500 मील की दूरी पर है)

% traceroute -w 2 www.stanford.edu
traceroute to www-v6.stanford.edu (171.67.215.200), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  v-vfw-cc-clusta-l3-outside.r-seb.umnet.umich.edu (141.211.81.130)  3.808 ms  4.225 ms  2.223 ms
 4  l3-bseb-rseb.r-bin-seb.umnet.umich.edu (192.12.80.131)  1.372 ms  1.281 ms  1.485 ms
 5  l3-barb-bseb-1.r-bin-arbl.umnet.umich.edu (192.12.80.8)  1.784 ms  0.874 ms  0.900 ms
 6  v-bin-arbl-i2-wsu5.wsu5.mich.net (192.12.80.69)  2.443 ms  2.412 ms  2.957 ms
 7  v0x1004.rtr.wash.net.internet2.edu (192.122.183.10)  107.269 ms  61.849 ms  47.859 ms
 8  ae-8.10.rtr.atla.net.internet2.edu (64.57.28.6)  28.267 ms  28.756 ms  28.938 ms
 9  xe-1-0-0.0.rtr.hous.net.internet2.edu (64.57.28.112)  52.075 ms  52.156 ms  88.596 ms
10  * * ge-6-1-0.0.rtr.losa.net.internet2.edu (64.57.28.96)  496.838 ms
11  hpr-lax-hpr--i2-newnet.cenic.net (137.164.26.133)  76.537 ms  78.948 ms  75.010 ms
12  svl-hpr2--lax-hpr2-10g.cenic.net (137.164.25.38)  82.151 ms  82.304 ms  82.208 ms
13  hpr-stanford--svl-hpr2-10ge.cenic.net (137.164.27.62)  82.504 ms  82.295 ms  82.884 ms
14  boundarya-rtr.stanford.edu (171.66.0.34)  82.859 ms  82.888 ms  82.930 ms
15  * * *
16  * * *
17  www-v6.stanford.edu (171.67.215.200)  83.136 ms  83.288 ms  83.089 ms

विशेष रूप से, वॉश राउटर और एटला राउटर (7 और 8 hops) के ट्रेसरआउट परिणामों के बीच के समय के अंतर पर ध्यान दें । नेटवर्क पथ पहले धोने के लिए जाता है और फिर atla के लिए। वाश को प्रतिक्रिया देने में 50-100ms लगते हैं, आंवला में लगभग 28ms लगते हैं। स्पष्ट रूप से एटला आगे दूर है, लेकिन इसके अनुरेखक परिणाम बताते हैं कि यह करीब है।

नेटवर्क माप के बारे में बहुत सारी जानकारी के लिए http://www.internet2.edu/performance/ देखें । (अस्वीकरण, मैं इंटरनेट 2 के लिए काम करता था)। इसे भी देखें: https://fasterdata.es.net/

मूल प्रश्न में कुछ विशिष्ट प्रासंगिकता जोड़ने के लिए ... जैसा कि आप देख सकते हैं कि मेरे पास स्टैनफोर्ड में 83 एमएस राउंड-ट्रिप पिंग का समय था, इसलिए हम जानते हैं कि नेटवर्क कम से कम इस तेजी से जा सकता है।

ध्यान दें कि मैंने इस ट्रेसरआउट पर जो अनुसंधान और शिक्षा नेटवर्क पथ लिया था, वह कमोडिटी इंटरनेट पथ से अधिक तेज़ होने की संभावना है। R & E नेटवर्क आमतौर पर अपने कनेक्शन को ओवरप्रोविजन करते हैं, जिससे प्रत्येक राउटर में बफरिंग की संभावना कम होती है। इसके अलावा, लंबे भौतिक पथ पर ध्यान दें, जो तट से तट तक लंबा है, हालांकि स्पष्ट रूप से वास्तविक यातायात का प्रतिनिधि है।

michigan-> वॉशिंगटन, डीसी-> एटलांटा-> हॉस्टन-> लॉस एंजेल्स-> स्टैनफोर्ड

Answer 5

मैं लगातार अंतर देख रहा हूं, और मैं नॉर्वे में बैठा हूं:

serverfault       careers
  509ms            282ms
  511ms            304ms
  488ms            295ms
  480ms            274ms
  498ms            278ms

यह Google Chrome के संसाधन दृश्य का उपयोग करने के वैज्ञानिक सटीक और सिद्ध तरीके से मापा गया था और प्रत्येक लिंक को बार-बार ताज़ा किया गया था।

सर्वर से ट्रैफ़रआउट

Tracing route to serverfault.com [69.59.196.212]
over a maximum of 30 hops:

  1    <1 ms     1 ms    <1 ms  81.27.47.1
  2     2 ms     1 ms     1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     2 ms     1 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    14 ms    14 ms    14 ms  193.28.236.253
  6    13 ms    13 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    22 ms    21 ms    21 ms  te7-1-10G.ar3.cph1.gblx.net [67.16.161.93]
  8    21 ms    20 ms    20 ms  sprint-1.ar3.CPH1.gblx.net [64.212.107.18]
  9    21 ms    21 ms    20 ms  sl-bb20-cop-15-0-0.sprintlink.net [80.77.64.33]
 10   107 ms   107 ms   107 ms  144.232.24.12
 11   107 ms   106 ms   105 ms  sl-bb20-msq-15-0-0.sprintlink.net [144.232.9.109]
 12   106 ms   106 ms   107 ms  sl-crs2-nyc-0-2-5-0.sprintlink.net [144.232.20.75]
 13   129 ms   135 ms   134 ms  sl-crs2-chi-0-15-0-0.sprintlink.net [144.232.24.208]
 14   183 ms   183 ms   184 ms  sl-crs2-chi-0-10-3-0.sprintlink.net [144.232.20.85]
 15   189 ms   189 ms   189 ms  sl-gw12-sea-2-0-0.sprintlink.net [144.232.6.120]
 16   193 ms   189 ms   189 ms  204.181.35.194
 17   181 ms   181 ms   180 ms  core2-gi61-to-core1-gi63.silverstartelecom.com [74.85.240.14]
 18   182 ms   182 ms   182 ms  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com [74.85.242.6]
 19   195 ms   195 ms   194 ms  sst-6509-peak-p2p-gi13.silverstartelecom.com [12.111.189.106]
 20   197 ms   197 ms   197 ms  ge-0-0-2-cvo-br1.peak.org [69.59.218.2]
 21   188 ms   187 ms   189 ms  ge-1-0-0-cvo-core2.peak.org [69.59.218.193]
 22   198 ms   198 ms   198 ms  vlan5-cvo-colo2.peak.org [69.59.218.226]
 23   198 ms   197 ms   197 ms  stackoverflow.com [69.59.196.212]

Trace complete.

करियर के लिए ट्रेसरूट

Tracing route to careers.stackoverflow.com [64.34.80.176]
over a maximum of 30 hops:

  1     1 ms     1 ms     1 ms  81.27.47.1
  2     2 ms     1 ms    <1 ms  qos-1.webhuset.no [81.27.32.17]
  3     1 ms     1 ms     1 ms  81.27.32.10
  4     1 ms     1 ms     2 ms  201.82-134-26.bkkb.no [82.134.26.201]
  5    12 ms    13 ms    13 ms  193.28.236.253
  6    13 ms    14 ms    14 ms  TenGigabitEthernet8-4.ar1.OSL2.gblx.net [64.209.94.125]
  7    21 ms    21 ms    21 ms  ge7-1-10G.ar1.ARN3.gblx.net [67.17.109.89]
  8    21 ms    20 ms    20 ms  tiscali-1.ar1.ARN3.gblx.net [64.208.110.130]
  9   116 ms   117 ms   122 ms  xe-4-2-0.nyc20.ip4.tinet.net [89.149.184.142]
 10   121 ms   122 ms   121 ms  peer1-gw.ip4.tinet.net [77.67.70.194]
 11     *        *        *     Request timed out.

दुर्भाग्य से, यह अब एक लूप या व्हाट्सएप में जाने लगता है और 30 हॉप्स और फिर खत्म होने तक स्टार और टाइमआउट देता रहता है।

ध्यान दें, ट्रेसरआउट शुरू से ही एक अलग होस्ट से हैं, मुझे उन्हें निष्पादित करने के लिए अपने होस्टेड सर्वर पर आरडीपी करना पड़ा

Comments

सही है, यह उम्मीद की जाती है कि पूर्वी तट डाटासेंटर हमारे यूरोपीय दर्शकों के लिए अधिक अनुकूल होगा - आप यूएसए की चौड़ाई को पार करने के लिए लिए गए लगभग 200 मीटर के समय को देख रहे हैं। हालांकि अन्य उत्तरों के अनुसार केवल ~ 80ms होना चाहिए?

— जेफ एटवुड

ऐसा लगता है कि यह लगभग 200ms पर संगत है, मैंने दोनों पर लगभग 20-30 बार ताज़ा ताज़ा किया है (हालांकि एक ही समय में नहीं), और सर्वरफ़ॉल्ट साइट ऐसा लग रहा है कि यह लगभग 200ms +/- पर घूमता है । मैंने एक ट्रेसरआउट की कोशिश की, लेकिन यह हर चीज पर सितारों के साथ आता है इसलिए शायद हमारे आईटी व्यवस्थापक ने कुछ अवरुद्ध कर दिया है।

— लास वागेसथेर कार्लसन 11

Answer 6

मैं पूर्व और पश्चिम के तटों के बीच अच्छी तरह से मापा लिंक, अच्छी तरह से मापा लिंक पर लगभग 80-90ms विलंबता देखता हूं।

यह देखना दिलचस्प होगा कि आप विलंबता कहाँ प्राप्त कर रहे हैं - परत-चार अनुरेखक (lft) जैसे उपकरण का प्रयास करें। संभावना बहुत हैं यह "अंतिम मील" (यानी आपके स्थानीय ब्रॉडबैंड प्रदाता में) पर प्राप्त किया जाता है।

स्थानांतरण समय केवल थोड़ा प्रभावित होने की उम्मीद थी - दो स्थानों के बीच स्थानांतरण समय के अंतर की जांच करने पर पैकेट नुकसान और घबराना अधिक उपयोगी माप है।

Answer 7

बस मज़े के लिए, जब मैंने यूरोप के भीतर से ऑनलाइन गेम वंश 2 एनए रिलीज़ किया:

Response time to east coast servers: ~110-120ms
Response time to west coast servers: ~190-220ms

अंतर का समर्थन करने के लिए लगता है कि इंटरनेट के अप्रत्याशित प्रकृति को देखते हुए, 100ms तक का कारण है।

प्रशंसित क्रोम ताज़ा परीक्षण का उपयोग करते हुए, मुझे दस्तावेज़ लोड समय मिलता है जो लगभग 130ms से भिन्न होता है।

Answer 8

यहाँ हर किसी के पास कुछ बहुत अच्छी बात है। और अपने स्वयं के POV में सही हैं।

और यह सब नीचे आता है कि यहां कोई वास्तविक सटीक उत्तर नहीं है, क्योंकि बहुत सारे चर हैं जो किसी भी उत्तर को हमेशा एक सौ चर को बदलकर गलत साबित हो सकते हैं।

72ms NY से SF विलंबता की तरह एक पैकेट के वाहक के PoP से PoP तक विलंबता है। यह अन्य महान बिंदुओं में से किसी को भी ध्यान में नहीं रखता है जो कुछ ने भीड़, पैकेट के नुकसान, सेवा की गुणवत्ता, ऑर्डर पैकेट से बाहर, या पैकेट के आकार, या PoP से PoP की सही दुनिया के बीच नेटवर्क पुन: उत्पन्न करने के बारे में बताया है। ।

और फिर जब आप दो शहरों के भीतर PoP से अपने वास्तविक स्थान पर अंतिम मील (आम तौर पर कई मील) को जोड़ते हैं, जहां ये सभी चर अधिक तरल पदार्थ बन जाते हैं, जो उचित अनुमान-क्षमता से बाहर तेजी से बढ़ना शुरू करते हैं!

उदाहरण के रूप में मैंने NY शहर और व्यावसायिक दिन के एसएफ के बीच एक परीक्षण चलाया। मैंने एक दिन ऐसा किया था कि दुनिया भर में कोई बड़ी "घटनाएं" नहीं हुईं, जो ट्रैफिक में वृद्धि का कारण बनें। तो शायद आज की दुनिया में यह औसत नहीं था! लेकिन फिर भी यह मेरी परीक्षा थी। मैंने वास्तव में इस अवधि में एक व्यावसायिक स्थान से दूसरे स्थान पर मापा, और प्रत्येक तट के सामान्य व्यापारिक घंटों के दौरान।

उसी समय, मैंने वेब पर सर्किट प्रदाताओं की संख्या पर नजर रखी।

परिणाम 88 से 100 एमएस के बीच व्यापार स्थानों के दरवाजे से विलंबता संख्या थे। इसमें किसी भी अंतर कार्यालय नेटवर्क विलंबता संख्या शामिल नहीं थी।

सेवा प्रदाता नेटवर्क विलंबता 70 से 80 एमएस के बीच थी। मतलब कि अंतिम मील लेटेंसी 18 से 30 एमएस के बीच हो सकती है। मैंने दो वातावरणों के बीच सटीक चोटियों और चढ़ाव को सहसंबंधित नहीं किया।

Answer 9

एनवाईसी समय:

NY     OR
109ms  271ms
72ms   227ms
30ms   225ms
33ms   114ms
34ms   224ms

एक आवासीय कनेक्शन पर क्रोम का उपयोग करना।

न्यू जर्सी, न्यू जर्सी में डेटासेंटर में वीपीएस से लिफ्ट का उपयोग करना:

terracidal ~ # lft careers.stackoverflow.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to 64.34.80.176:80/tcp
 1  207.192.75.2 0.4/0.5ms
 2  vlan804.tbr2.mmu.nac.net (209.123.10.13) 0.4/0.3ms
 3  0.e1-1.tbr2.tl9.nac.net (209.123.10.78) 1.3/1.5ms
 4  nyiix.Peer1.net (198.32.160.65) 1.4/1.4ms
 5  oc48-po3-0.nyc-75bre-dis-1.peer1.net (216.187.115.134) 1.6/1.5ms
 6  216.187.115.145 2.7/2.2ms
 7  64.34.60.28 2.3/1.8ms
 8  [target open] 64.34.80.176:80 2.5ms

terracidal ~ # lft serverfault.com -V
Layer Four Traceroute (LFT) version 3.0
Using device eth0, members.linode.com (97.107.139.108):53
TTL LFT trace to stackoverflow.com (69.59.196.212):80/tcp
 1  207.192.75.2 36.4/0.6ms
 2  vlan803.tbr1.mmu.nac.net (209.123.10.29) 0.4/0.4ms
 3  0.e1-1.tbr1.tl9.nac.net (209.123.10.102) 1.3/1.4ms
 4  nyk-b3-link.telia.net (213.248.99.89) 1.6/1.4ms
 5  nyk-bb2-link.telia.net (80.91.250.94) 1.9/84.8ms
 6  nyk-b5-link.telia.net (80.91.253.106) 1.7/1.7ms
 7  192.205.34.53 2.1/2.1ms
 8  cr1.n54ny.ip.att.net (12.122.81.106) 83.5/83.6ms
 9  cr2.cgcil.ip.att.net (12.122.1.2) 82.7/83.1ms
10  cr2.st6wa.ip.att.net (12.122.31.130) 83.4/83.5ms
11  cr2.ptdor.ip.att.net (12.122.30.149) 82.7/82.7ms
12  gar1.ptdor.ip.att.net (12.123.157.65) 82.2/82.3ms
13  12.118.177.74 82.9/82.8ms
14  sst-6509b-gi51-2-gsr2-gi63.silverstartelecom.com (74.85.242.6) 84.1/84.0ms
15  sst-6509-peak-p2p-gi13.silverstartelecom.com (12.111.189.106) 83.3/83.4ms
16  ge-0-0-2-cvo-br1.peak.org (69.59.218.2) 86.3/86.2ms
**  [neglected] no reply packets received from TTLs 17 through 18
19  [target closed] stackoverflow.com (69.59.196.212):80 86.3/86.3ms