थर्ड-पार्टी ऑप्टिक्स: विश्वसनीयता और अर्थशास्त्र

ऑपरेटरों के बीच सहमति भारी है: थर्ड-पार्टी ऑप्टिक्स सामान्य हैं। स्विच-वेंडर ब्रांड के तहत बिकने वाले मॉड्यूल और स्वतंत्र ऑप्टिक्स वेंडर द्वारा बेचे जाने वाले मॉड्यूल उन्हीं कुछ चुनिंदा कॉन्ट्रैक्ट प्रोडक्शन लाइन से निकलते हैं; फ़र्क़ सिर्फ़ लेबल और क़ीमत का है — आमतौर पर 5× से 40× तक।

रिपोर्ट किया गया फ़ील्ड अनुभव इसकी पुष्टि करता है: कई सौ थर्ड-पार्टी SFP के फ़्लीट जो 7–12 साल से चल रहे हों और सिर्फ़ एक से तीन फ़ेल्योर हुए हों, ऐसे उदाहरण आम तौर पर दिए जाते हैं।

समस्याएँ कहाँ आती हैं

• ख़राब प्रोडक्शन बैच। फ़ेल्योर के समूह लगभग हमेशा किसी पूरे विक्रेता की बजाय किसी ख़ास बैच और अवधि से जुड़े होते हैं। कई स्वतंत्र रिपोर्ट में ख़ास ख़रीद लॉट के लिए सामान्य से काफ़ी ऊपर डिफ़ेक्ट दर बताई गई है।
• महँगे मॉड्यूल पर तकलीफ़देह RMA। 40G/100G ऑप्टिक्स को समुद्र-पार के विक्रेता के पास लौटाना और हफ़्तों इंतज़ार करना एक असली ऑपरेशनल लागत है।
• Tx पावर जो प्रोग्राम की गई वैल्यू से मेल नहीं खाती। कुछ मॉड्यूल जो Tx आँकड़ा दिखाते हैं वह मेमोरी में लिखी एक स्थिर संख्या होती है, कोई माप नहीं। जो प्रोवाइडर परवाह करते हैं वे आने वाले बैच को पावर मीटर से टेस्ट करते हैं।
• प्रोक्योरमेंट कंप्लायंस। पब्लिक-सेक्टर ख़रीद के लिए, “कंप्लायंट” मॉड्यूल अक्सर वही हार्डवेयर होता है जिसमें बस सॉफ़्टवेयर कॉन्फ़िगरेशन अलग होता है — जाँच लें कि आप असल में किस चीज़ के पैसे दे रहे हैं।

अनुभवी ख़रीदार क्या करते हैं

• मास 1G/10G/25G मॉड्यूल के लिए बजट थर्ड-पार्टी वेंडर इस्तेमाल करें, जहाँ फ़ेल्योर को बदलना सस्ता हो।
• LR4, ER, कोहेरेंट और अन्य महँगे ऑप्टिक्स के लिए, क्वालिटी की साख वाले प्रीमियम थर्ड-पार्टी वेंडर को तरज़ीह दें, और आदर्श रूप से ऐसे मॉड्यूल जिन्हें यूज़र दोबारा प्रोग्राम कर सके।
• आने वाले बैच का इंस्पेक्शन करें: प्रोडक्शन में जाने से पहले हर मॉड्यूल का DDM पढ़ें और पावर मीटर से Tx/Rx जाँचें।
• OEM से बातचीत करें। थर्ड-पार्टी क़ीमत दिखाने पर कुछ स्विच वेंडर “कॉमन ऑप्टिक्स” SKU बड़ी छूट पर देते हैं।
• सपोर्ट कॉल के लिए हर टाइप का एक OEM मॉड्यूल रखें (देखें विक्रेता लॉक)।

कुल लागत

ऑपरेटर थर्ड-पार्टी मॉड्यूल की ओर जाकर सालाना ऑप्टिक्स ख़र्च में 90% से भी ज़्यादा की कटौती की रिपोर्ट देते हैं — और अक्सर उस बचत में से एक कोडिंग टूल के लिए बजट रखते हैं, इस बीमे के तौर पर कि कहीं कोई OEM भविष्य के किसी फ़र्मवेयर में अपने स्वीकृति नियम सख़्त न कर दे।

CodingBox कैसे मदद करता है

• इनकमिंग इंस्पेक्शन — Check transceiver स्क्रीन पर पहचान जानकारी और लाइव DDM पढ़ें, और DDM से वैल्यू को CSV में लॉग करें।
• मॉड्यूल के अस्वीकार होने पर स्विच को जो चाहिए उसके हिसाब से रीकोड करें — देखें EEPROM रीकोडिंग।
• रिकॉर्ड रखें — हर रीड code database में सेव होता है, ताकि बाद में कोई बैच समस्या आने पर मॉड्यूल का इतिहास उपलब्ध हो।

कौन सा प्लैटफ़ॉर्म क्या जाँचता है, और हर प्लैटफ़ॉर्म क्लास के लिए कोडेड पहचान जानकारी को क्या पूरा करना चाहिए: हर NOS मॉड्यूल को कैसे वैलिडेट करता है; अपग्रेड के दौरान मिश्रित फ़्लीट को सुरक्षित रखना: संगतता मैट्रिक्स और फ़र्मवेयर।

सर्वर एडाप्टर पर थर्ड-पार्टी मॉड्यूल — Intel ड्राइवर व्हाइटलिस्ट और allow_unsupported_sfp ओवरराइड, अनुमतिशील विक्रेता, Windows/ESXi: NIC पर ट्रांसीवर संगतता।