- यह AWS डेटा सेंटरों के बीच latency को 3 ms रेंज में बाँटकर दिखाने वाला एक visualization पेज है
- लेजेंड को 100ms से कम, 100~200ms, और 200ms से अधिक में विभाजित किया गया है, जिससे latency स्तरों की जल्दी तुलना की जा सकती है
- दी गई जानकारी से यह पुष्टि नहीं की जा सकती कि इसमें कौन से डेटा सेंटर या रीजन शामिल हैं
- मापन की विधि, मापन का समय, और डेटा सेंटरों के बीच individual latency मान उपलब्ध नहीं हैं
- इसलिए इस सारांश में सत्यापित की जा सकने वाली सीमा visualization के रेंज मानदंड तक ही सीमित है
latency लेजेंड
- X < 100ms: 100ms से कम
- X 100ms - 200ms: 100ms~200ms
- X > 200ms: 200ms से अधिक
सत्यापित नहीं की जा सकने वाली विस्तृत जानकारी
- किसी विशेष AWS डेटा सेंटर की सूची या क्षेत्रीय नाम उपलब्ध नहीं हैं
- मापन विधि, मापन का समय, और individual डेटा सेंटरों के बीच latency मानों की पुष्टि नहीं की जा सकती
2 टिप्पणियां
लगता है कि पश्चिमी देशों की दिशा में
us-east-1सबसे बेहतर लोकेशन है।Hacker News की राय
सिर्फ ping वैल्यू दिखाने के बजाय, यह भी दिखे तो अच्छा होगा कि वह सैद्धांतिक सर्वोत्तम वैल्यू की तुलना में कितनी खराब है
मेरी जानकारी में optical fiber medium में रोशनी की गति vacuum में रोशनी की गति से करीब 30% धीमी होती है
डेटा सेंटरों के बीच latency को लेकर architecture meetings में शिकायतें उठीं, और बाद में पता चला कि वे शुरू से ही सैद्धांतिक रूप से संभव वैल्यू के काफी करीब थीं—ऐसा कई बार हुआ
जब ग्राहक high availability या disaster recovery सिस्टम डिजाइन करते हैं, तो यह महत्वपूर्ण है कि वे primary zone के साथ गलती से कोई ऐसा region या zone न चुन लें जिसकी latency “कृत्रिम रूप से” बहुत ज्यादा हो
हमारी मौजूदा कंपनी SAP को cloud पर migrate करने में विशेषज्ञ है, और पहले गलत assumptions के कारण अस्वीकार्य latency से नुकसान झेलने के बाद से, हम quotation और scope estimation के चरण में AWS और GCP network experts के साथ यह बातचीत जरूर करते हैं
यह ICMP ping नहीं, बल्कि tcp/443 पर socket stream connection बनाने का तरीका है
ping एक metric के तौर पर अनुपयुक्त हो सकता है
https://github.com/mda590/cloudping.co/blob/8918ee8d7e632765...
fiber-optic cable के अंदर रोशनी लगभग रोशनी की गति के 70%, यानी करीब 210,000km/s से चलती है
पृथ्वी की परिधि करीब 40,000km है, और पृथ्वी के दूसरी तरफ तक सीधा path one-way करीब 100ms और round-trip करीब 200ms होगा
बेशक, hollow-core fiber और लगभग सीधी fiber routes इस्तेमाल करके सैद्धांतिक रूप से करीब 40% और सुधार किया जा सकता है, लेकिन इसकी लागत उठाना चाहने वाली जगहें कम ही होंगी
सोच रहा हूं कि इस value को सही-सही calculate करने के लिए कोई अच्छा resource है या नहीं
मैं red-green colorblind हूं, इसलिए 100ms से कम वाली lines और 200ms से ज्यादा वाली lines में फर्क करना मुश्किल या असंभव है
यह पुरुष आबादी के करीब 8% पर लागू होता है, इसलिए colorblind mode जोड़ना अच्छा रहेगा
visualization अपने आप में बहुत अच्छा है
developer tools में
bodyelement परfilter: hue-rotate(60deg);rule डालें, या address bar मेंjavascript:void(document.body.style.filter='hue-rotate(60deg)')run करेंअगर पहले इस समस्या को अच्छी तरह solve करने के सबसे अच्छे examples आपको पता हों, और link हो, तो कृपया share करें
काफी confusing है
जैसे कोई filter जो पूरी screen के colors को किसी खास तरीके से बदलकर उन्हें distinguishable बना दे
वह ratio इससे कम है, और colorblind लोगों के बीच भी color perception अलग-अलग होता है
किसी एक को साफ दिखता है, इसका मतलब यह नहीं कि दूसरे को भी साफ दिखेगा; और उल्टा भी सही है
पहले एक customer के लिए इससे जुड़ी planning की थी
AWS latency measure करते हुए, approximate submarine cable length को km में मापकर 150 से divide करने पर actual latency से 10% के भीतर match हो जाता था
यह बहुत चौंकाने वाला नहीं था, लेकिन बेहद consistent था, और बाद में लगा कि शायद वह 155 था
https://www.ibiblio.org/harris/500milemail.html
“LabVIEW के जरिए optical fiber में light की speed लगभग 2.054 x 10^8 m/s calculate की गई, जो refractive index n ≈ 1.4606 के अनुरूप एक typical value है”
https://web.phys.ksu.edu/posters/2009/juma-Adv-Lab-S09.pdf
उस rule of thumb की mathematical explanation क्या roughly इस तरह है, यह जानना चाहूंगा
https://news.ycombinator.com/user?id=Hikikomori ने optical fiber medium में light की speed को 3e5 नहीं बल्कि 2e5 करके correct किया
light की speed 2e5km/s है, यानी लगभग 2e2km/ms, और रूप length(km) / 200(km/ms) बनता है; आखिरकार latency(ms) ≈ K' × length(km) हो जाती है
सोच रहा हूं कि यहां K करीब 1.3, K' 1/155 है, और क्या इसमें non-straight distance, network overhead और switching, तथा round-trip measurement error जैसे factors शामिल हैं
दिलचस्प। data center को दिखाने वाले नीले circle पर click करने से दूसरे data centers तक की latency दिखती है
यह समझने में मुझे थोड़ा समय लगा, इसलिए site पर select करने के लिए data center पर click करें जैसी guidance जोड़ना अच्छा रहेगा
network और compute components के कई abstraction levels—यानी data centers, edge installation points वगैरह—मिलकर region बनाते हैं
region के अंदर भी zone के हिसाब से variation बड़ा होता है, इसलिए measurement methodology महत्वपूर्ण है
AWS Network Manager में regions के बीच, Availability Zones के बीच, और Availability Zone के अंदर latency के आंकड़े देता है
latency baseline तय करने और यह देखने के लिए उपयोगी है कि AWS की तरफ कोई समस्या है या नहीं
https://docs.aws.amazon.com/network-manager/latest/infrastru...
visualization और concept शानदार हैं, लेकिन अच्छा हो अगर रंग bucketed होने के बजाय continuous gradient हों
अभी का तरीका 100ms को 99ms से बहुत खराब दिखाता है, फिर भी 200ms जैसा ही दिखाता है
उदाहरण के लिए us-east-1 पर क्लिक करने पर Western Europe के datacenters की latency काफ़ी अलग दिखती है, जबकि eu-central-1 और eu-south-1 में बस लगभग 9ms का अंतर है फिर भी वे पूरी तरह अलग दिखते हैं, और eu-north-1 और ap-south-1 में लगभग 88ms का अंतर है फिर भी वे एक जैसे दिखते हैं
मापे गए values की तुलना speed of light के हिसाब से संभव न्यूनतम latency से करने की बात भी है, लेकिन समस्या यह है कि vacuum में light की speed c, optical fiber के अंदर information transmission speed नहीं है
असल theoretical best सिर्फ medium में light की speed देखने पर भी c के 70% से ऊपर जाना मुश्किल है, और repeater delays जैसे कई unknown factors भी हैं
मौजूदा visualization 90ms latency को “अच्छा” जैसा दिखाता है, लेकिन असल में कई applications के लिए यह बिल्कुल unacceptable value है
खासकर तब, जब एक request process करने के लिए कई round trips करने पड़ते हों
जिज्ञासा है कि किन datacenters को शामिल करना है, यह कैसे चुना गया
उदाहरण के लिए eu-south-2, यानी Spain, गायब है
पहले मैंने एक project किया था जिसमें datacenters के बीच latency 30ms से कम होनी थी, और हमें eu-west-1 Ireland और eu-south-2 इस्तेमाल करने थे
लेकिन वास्तविक latency 42ms के करीब थी, और मुख्य वजह यह थी कि Ireland और mainland Europe के बीच submarine cable नहीं थी, इसलिए route पहले UK जाता था और फिर UK को पार करके mainland की तरफ cable पर जाता था
CloudPing में जाएँ तो dataset में eu-south-2 नहीं है
CloudPing GitHub repository में 4 साल से code changes नहीं हुए हैं, इसलिए आख़िरी active work के बाद कुछ नए regions आए हो सकते हैं
बस जानना चाहता हूँ कि यह publicly available data कहाँ है
data बहुत useful है और globe visually impressive है, लेकिन practical use के लिहाज़ से flat world map बेहतर लगता है
सभी datacenters एक साथ दिखेंगे, और lines बहुत ज़्यादा पास-पास नहीं होंगी, इसलिए पढ़ना भी आसान होगा
https://en.wikipedia.org/wiki/Azimuthal_equidistant_projecti...
दोनों के बीच switch करने का option बेहतर होगा
latency का सबसे बड़ा factor बेशक distance है
लेकिन कुछ relatively पास regions के बीच भी direct optical fiber नहीं होता, इसलिए latency खराब हो सकती है, जैसे polar region से गुजरने वाले routes
जिज्ञासा है कि क्या ऐसे region examples हैं जो triangle inequality को बहुत ज़्यादा violate करते हों
यानी A–C latency, best A–B + B–C latency से कहीं ज्यादा खराब हो
curiosity के तौर पर सोच रहा हूँ कि क्या इस idea से यह infer किया जा सकता है कि कौन-से datacenters direct fiber से connected होने की ज्यादा संभावना रखते हैं, और फिर सिर्फ वही connections दिखाए जा सकते हैं
मूल रूप से उन probe pairs को खोजने का तरीका था जहाँ probes A और C के बीच round-trip time, A–B + B–C से बड़ा हो
इस method में ICMP/round-trip time measurement की usual समस्याएँ हैं, और यह भी कि traffic वास्तव में “relay” probe से होकर route नहीं हुआ था, लेकिन ऐसे pairs मौजूद हैं
https://theses.hal.science/tel-03666771/document के page 84 पर example है। अगर आप French पढ़ सकते हैं
अगर B से होकर जाने वाला “detour” route ICMP packet के लिए सबसे सस्ता path है, तो असल में भी वही path लिया जाएगा
बल्कि जहाँ A–C लगभग A–B + B–C के बराबर हो, वहाँ देखने से ऐसी जगहें मिल सकती हैं जहाँ यह हो रहा है
fiber की कमी के अलावा, बेहतर peering contracts जैसे financial reasons से भी ऐसा संभव है
मेरी जानकारी में Mumbai से southern Russia तक distance के हिसाब से बहुत दूर नहीं है, लेकिन latency आश्चर्यजनक रूप से ज्यादा है
उदाहरण के लिए Frankfurt से Moscow तक से कहीं ज्यादा, और पता नहीं Frankfurt–Moscow–Mumbai के बीच triangle inequality violate करने लायक है या नहीं
https://www.submarinecablemap.com/
submarine cables बिछाने की cost बहुत ज्यादा होती है, इसलिए unpublished cables होने की संभावना बहुत कम है
कुल मिलाकर packet loss भी ज्यादा होता है
कुछ दिन पहले मैं यह इस्तेमाल कर रहा था
https://aws-latency-test.com/