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


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

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

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

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

ऐसा लगता है ... गलत ... मेरे लिए।

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

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

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


99
2018-04-30 11:26


मूल


जिन नेटवर्कों पर आप नियंत्रण नहीं करते हैं, उनमें से कोई भी माप लगभग व्यर्थ लगता है। इन प्रकार के नेटवर्क चर्चाओं में अक्सर ऐसा लगता है कि हम भूल जाते हैं कि प्रत्येक पैकेट से जुड़े एक अस्थायी घटक हैं। यदि आपने परीक्षण बार-बार 24 x 7 चलाया और कुछ निष्कर्ष पर पहुंचा कि यह एक बात है। यदि आप दो बार परीक्षण चलाते हैं तो मेरा सुझाव है कि आप इसे और अधिक चलाएं। और उन लोगों के लिए जो प्रदर्शन के कुछ उपाय के रूप में पिंग के उपयोग की वकालत करते हैं, नहीं। हर प्रमुख नेटवर्क पर मैंने कभी काम किया है कि हम आईसीएमपी यातायात को सबसे कम प्राथमिकता पर सेट करते हैं। पिंग का मतलब केवल एक चीज है, और यह नहीं है;) प्रदर्शन के बारे में। - dbasnett
जहां से मैं रहता हूं, जेफरसन सिटी, एमओ, समय समान हैं। - dbasnett
एक साइड नोट के रूप में: प्रकाश सीधे एनवाई से सीएफ तक यात्रा करने के लिए ~ 14ms लेता है (सीधे फाइबर पर विचार कर रहा है)। - Shadok
फाइबर में प्रकाश .67 के एक वेग कारक के साथ यात्रा करता है (अपवर्तक सूचकांक के बराबर) ~ 201,000 किमी / एस, तो यह कम से कम 20 एमएस है। - Zac67


जवाब:


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

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

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

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

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

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

यह एक गुई उपकरण के साथ peerings के रूप में अन्वेषण करने के लिए भी मजेदार है linkrank, यह आपको अपने आस-पास के इंटरनेट की एक तस्वीर देता है।


108
2018-04-30 12:03



सहमत हैं, कौवा मक्खियों के रूप में प्रकाश की गति सबसे अच्छा है जो आप संभवतः कर सकते हैं। वैसे भी वास्तव में उत्कृष्ट जवाब, यह वही है जो मैं खोज रहा था। धन्यवाद। - Jeff Atwood
जिज्ञासा के लिए वास्तविक गणित है: 3000 मील / सी = 16.1ms - tylerl
एक वैक्यूम में एक फोटॉन लगभग 134 एमएस में भूमध्य रेखा की यात्रा कर सकता है। कांच में एक ही फोटॉन लगभग 200 मीटर ले जाएगा। फाइबर के 3,000 मील टुकड़े में 24 एमएस है। बिना किसी डिवाइस के देरी। - dbasnett
यह मुझे याद दिलाता है 500 मील ईमेल का मामला। - bahamat


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

ट्रांस-अटलांटिक पथ
एनवाई 78 लंदन
87 फ्रैंकफर्ट धोएं
ट्रांस-पैसिफ़िक पथ
एसएफ 147 हांगकांग
ट्रांस-यूएसए पथ
एसएफ 72 एनवाई

network latency by world city pairs

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

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

ये Google क्रोम देव उपकरण का उपयोग करके मापा गया था।


41
2018-04-30 11:45



शांत चार्ट! एनएफ से एसएफ वर्तमान में है 71 ms इस पर, तो आप सही हैं - हम इससे बेहतर प्रदर्शन करने की उम्मीद नहीं कर सकते हैं। - Jeff Atwood
धन्यवाद। इसने मेरी बहुत मदद की। दुनिया के विभिन्न स्थानों के बीच नेटवर्क विलंबता देखने के लिए यह एक और स्रोत है - dotcom-monitor.com/WebTools/network_latency.aspx - Sajib Mahmood


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

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

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

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

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

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


10
2018-04-30 17:34





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

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

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

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

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

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

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

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

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

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

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


7
2017-08-15 15:46





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

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

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

Serverfault करने के लिए Traceroute

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.

करियर के लिए Traceroute

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 होप्स तक जारी रखता है और फिर समाप्त होता है।

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


6
2018-04-30 11:43



ठीक है, यह उम्मीद की जाती है कि पूर्वी तट डेटासेंटर हमारे यूरोपीय दर्शकों के लिए अधिक अनुकूल होगा - आप संयुक्त राज्य अमेरिका की चौड़ाई को पार करने के लिए + 200ms समय के बारे में देख रहे हैं। हालांकि अन्य उत्तरों के प्रति केवल ~ 80ms होना चाहिए? - Jeff Atwood
ऐसा लगता है कि यह लगभग 200ms पर सुसंगत है, मैंने अब दोनों पर 20-30 बार रीफ्रेश किया है (हालांकि एक ही समय में नहीं), और सर्वरफॉल्ट साइट ऐसा लगता है कि यह लगभग 200ms +/- दूसरे की तुलना में अधिक है । मैंने एक traceroute की कोशिश की, लेकिन यह सब कुछ पर सितारों के साथ आता है तो शायद हमारे आईटी प्रशासकों ने कुछ अवरुद्ध कर दिया है। - Lasse Vågsæther Karlsen


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

यह देखना दिलचस्प होगा कि आप कहां विलंब प्राप्त कर रहे हैं - लेयर-चार ट्रैसरआउट (एलएफटी) जैसे टूल को आज़माएं। संभावना है कि यह "आखिरी मील" (यानी आपके स्थानीय ब्रॉडबैंड प्रदाता में) पर प्राप्त होता है।

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


2
2018-04-30 11:42





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

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

अंतर यह मानता है कि इंटरनेट की अप्रत्याशित प्रकृति पर विचार करते हुए, 100ms तक का कारण है।

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


2
2018-04-30 12:52





यहां हर किसी के पास कुछ वाकई अच्छा बिंदु है। और अपने स्वयं के पीओवी में सही हैं।

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

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

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

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

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

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

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


2
2017-09-09 15:43





एनवाईसी समय:

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

1
2018-04-30 12:10