2016-09-22 7 views
6

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

इस उपकरण पर हमें समर्थन देने वाली सेवाओं में से एक एसएनएमपी है, जो यूडीपी डेटाग्राम पर निर्भर करता है, और हालांकि एसएनएमपी के पास टीसीपी समर्थन है, हम ग्राहकों को इसका उपयोग करने के लिए मजबूर नहीं कर सकते हैं।

मुझे जो मिल रहा है वह यह है कि यह प्रणाली लगभग सभी एसएनएमपी अनुरोधों को खो रही है।

यह ध्यान रखना महत्वपूर्ण है कि न तो नेटवर्क और न ही सीपीयू ओवरलोड हो रहे हैं। डेटा दर विशेष रूप से उच्च नहीं होती है, और सीपीयू आमतौर पर लगभग 30% लोड होते हैं। इसके अलावा, हम एसएनएमपी ++ और एजेंट ++ पुस्तकालयों का उपयोग एसएनएमपी के लिए कर रहे हैं, इसलिए हमारे पास उन पर नियंत्रण है, इसलिए यह सिस्टम डिमन ब्रेकिंग में कोई समस्या नहीं है। हालांकि, अगर हम प्रसंस्करण और नेटवर्क गतिविधि को रोकते हैं, तो एसएनएमपी अनुरोध खो नहीं जाते हैं। एसएनएमपी को अपने धागे में संभाला जा रहा है, और हमने सुनिश्चित किया है कि अनुरोध दुर्लभ और फैलाने के लिए सुनिश्चित करें ताकि वास्तव में किसी भी समय एक से अधिक अनुरोधों को बफर्ड नहीं किया जाना चाहिए। कम CPU लोड के साथ, अनुरोध की सेवा करने के लिए प्राप्त करने की प्रक्रिया में संदर्भ-स्विचिंग में कोई समस्या नहीं होनी चाहिए।

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

जब इसे गुगल करते हैं, तो मुझे खोए हुए पैकेट की रिपोर्ट करने के लिए नेटस्टैट का उपयोग करने के उदाहरण मिलते हैं, लेकिन ऐसा लगता है कि इस प्रणाली पर काम नहीं लगता है, क्योंकि कोई "-s" विकल्प नहीं है। मैं इन पैकेट बूंदों की निगरानी कैसे कर सकता हूं? मैं कारण का निदान कैसे कर सकता हूं? इस नुकसान को कम करने के लिए मैं कर्नेल पैरामीटर कैसे ट्यून कर सकता हूं?

धन्यवाद!

+0

यह संभव है कि अनुरोध करने वाले अंत में एसएनएमपी प्रतिक्रियाएं खो जाएंगी, लेकिन यह केवल एक पुरानी पुरानी x86 मशीन है जो बहुत सी सीपीयू और मेमोरी के साथ लिनक्स चल रही है। –

+0

समस्या को हल करने के लिए बहुत अच्छा होगा और देखें कि क्या आप यह निर्धारित कर सकते हैं कि पैकेट कहां जा रहे हैं और फिर खो गए हैं। आप यह सुनिश्चित करने के लिए वायरसहार्क जैसे टूल का उपयोग कर सकते हैं कि अनुरोध Zynq बोर्ड पर जा रहे हैं। मैं यह देखने के लिए कि क्या यूडीपी पैकेट कर्नेल में उपलब्ध हैं, मैं 'tcpdump' की अनुशंसा करता हूं। आप बोर्ड के फ्लैश के माध्यम से अन्य लिनक्स यूटिल्स इंस्टॉल कर सकते हैं। इसके अलावा, यूडीपी की गारंटीकृत डिलीवरी नहीं है (मुझे यकीन नहीं है कि एसएनएमपी के पास अपना खुद का पुनः प्रयास तर्क है)। – Phil

+0

ठीक है, मैंने व्यक्तिगत रूप से कभी भी वायरशर्क का उपयोग नहीं किया है, लेकिन मेरे सहयोगियों के पास है, इसलिए मैं उनके साथ उनके साथ काम करूंगा। एसएनएमपी के लिए, यह एक टाइमआउट है। मेरे मामले में, मैं एक स्टेट वैरिएबल को बदलने की कोशिश कर रहा हूं और इसे सेट नहीं कर रहा हूं, इसलिए मैंने 10 बार रीट्री करने वाले धागे को जन्म दिया। अक्सर सभी 10 प्रयास खो जाते हैं, जो परेशान है। –

उत्तर

3

वायर्सहार्क या टीसीपीडम्प एक अच्छा दृष्टिकोण है। आप/proc/sys/net/ipv4/में सेटिंग्स को देखना चाहते हैं या पुराने कर्नेल (4.x के बजाय 3.x) को आजमा सकते हैं। हमें ज़िनक पर 4.4 कर्नेल के साथ टीसीपी कनेक्शन के साथ कोई समस्या थी, लेकिन यह सिस्टम लॉग में देखा जा सकता था (SYN कुकीज़ और संभावित बाढ़ के बारे में एक चेतावनी)।

संबंधित मुद्दे