माइक्रोसेकंड स्तर सटीकता

Question

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

सर्वर एक हार्डवेयर (एफपीजीए) है जो सटीक 1ms अंतराल पर पैकेट उत्पन्न करता है। क्लाइंट एप्लिकेशन 10 जी सौरफ्लेयर एनआईसी के साथ एक लिनक्स (आरएचईएल/सेंटोस 7) मशीन पर चलता है।

मेरे कोड के पहले संस्करण इस

while(1) 
{ 
    while(1) 
    { 
    numbytes = recvfrom(sockfd, buf, sizeof(buf), 0, NULL, NULL); 
    if(numbytes > 0) 
    { 
     //Some more lines here, to read packet number 
     break; 
    } 
    } 
    for (i=0;i<14;i++) 
    { 
    if (sendto(sockfd,(void *)(sym) , sizeof(sym), 0, NULL, NULL) < 0) 
      perror("Send failed\n"); 
    } 
} 

मैं मापने recvfrom कॉल करने से पहले (clock_gettime का प्रयोग करके) टाइम स्टांप लेने के द्वारा समय प्राप्त करते हैं और एक के बाद, मैं इन timestamps और प्रिंट के समय मतभेद प्रिंट की तरह है जब भी समय अंतर 900-1100 की स्वीकार्य सीमा से अधिक हो जाता है।

समस्या का सामना करना पड़ रहा हूँ

पैकेट प्राप्त उस समय (प्रिंट माइक्रोसेकंड में हैं)

Decode Time : 1234 
Decode Time : 762 
Decode Time : 1593 
Decode Time : 406 
Decode Time : 1703 
Decode Time : 257 
Decode Time : 1493 
Decode Time : 514 
and so on.. 

और कभी-कभी डिकोड बार 2000us और आवेदन से अधिक टूट जाएगा इस तरह fluctuating.Something जाता है।

इस स्थिति में, एप्लिकेशन 2 सेकंड से कुछ मिनट के बीच कहीं भी तोड़ देगा।

विकल्प अब तक मेरे द्वारा प्रयास किए गए।

1. किसी विशेष पृथक कोर से संबंध स्थापित करना। SCHED_FIFO
2. बढ़ाएँ सॉकेट बफर के साथ अधिकतम करने के लिए
3. सेटिंग शेड्यूलिंग प्राथमिकताओं आकार
4. सेटिंग नेटवर्क इंटरफेस एक ही कोर जो आवेदन poll(),select() कॉल का उपयोग recvfrom से अधिक
5. स्पिनिंग प्रक्रियाओं को आत्मीयता बीच में।

ये सभी विकल्प कोड के प्रारंभिक संस्करण में महत्वपूर्ण सुधार देते हैं। अब आवेदन ~ 1-2 घंटे के लिए चला जाएगा। लेकिन यह अभी भी पर्याप्त नहीं है।

कुछ टिप्पणियों:

1. मैं, इन डिकोड समय प्रिंट आ विशाल डंप प्राप्त जब भी मैं Linux मशीन को ssh सत्र जबकि आवेदन चल रहा है (जो बनाता है मुझे अन्य 1G ईथरनेट इंटरफेस से अधिक नेटवर्क संचार लगता है 10 जी ईथरनेट इंटरफेस के साथ हस्तक्षेप पैदा कर रहा है)।
2. आवेदन आरएचईएल (लगभग 2-3 घंटे के रन टाइम) में बेहतर प्रदर्शन करता है (लगभग 30 मिनट - 1.5 घंटे के रन टाइम)
3. रन टाइम भी विभिन्न हार्डवेयर कॉन्फ़िगरेशन के साथ लिनक्स मशीनों के साथ भिन्न होता है ओएस।

कृपया सुझाव दें कि आवेदन के रन-टाइम में सुधार करने के लिए कोई और तरीका है या नहीं।

अग्रिम धन्यवाद।

Answer 1

सबसे पहले, आपको टाइमस्टैम्पिंग विधि की सटीकता को सत्यापित करने की आवश्यकता है; clock_gettime। संकल्प नैनोसेकंड है, लेकिन सटीकता और सटीकता प्रश्न में है। यह आपकी समस्या का उत्तर नहीं है, लेकिन इस बात पर सूचित करता है कि आगे बढ़ने से पहले टाइमस्टैम्पिंग कितनी भरोसेमंद है। Difference between CLOCK_REALTIME and CLOCK_MONOTONIC? देखें कि क्यों आपके आवेदन के लिए CLOCK_MONOTONIC का उपयोग किया जाना चाहिए।

मुझे लगता है डिकोड समय उतार-चढ़ाव के बहुमत डिकोड प्रति संचालन, ऑपरेटिंग सिस्टम, या IRQs के संदर्भ स्विचिंग के परिवर्तनशील करने के लिए या तो कारण है।

डिकोड प्रति

संचालन मैं के बाद से कोड अपनी पोस्ट में सरलीकृत किया गया है पर कोई टिप्पणी नहीं कर सकते हैं। इस मुद्दे को भी प्रोफाइल और निरीक्षण किया जा सकता है। प्रक्रिया के अनुसार

संदर्भ स्विचिंग आसानी से निरीक्षण किया जा सकता है और https://unix.stackexchange.com/a/84345

नजर रखी रूप में रॉन कहा गया है, इन एक नेटवर्क के लिए बहुत सख्त समय आवश्यकताओं हैं। यह एक अलग नेटवर्क होना चाहिए, और एकल उद्देश्य होना चाहिए। एसएसएचइंग अन्य सभी यातायात को इंगित करते समय डीकोड ओवर-टाइम के बारे में आपका अवलोकन रोकना चाहिए। अलग-अलग एनआईसी दिए जाने पर यह परेशान है। इस प्रकार मुझे संदेह है कि आईआरक्यू मुद्दे हैं। देखें/proc/interrupts।

लंबे अंतराल के ऊपर (hours-> दिन) संगत डिकोड बार प्राप्त करने के लिए तेजी से ओएस को सरल बनाने की आवश्यकता होगी। अनावश्यक प्रक्रियाओं और सेवाओं, हार्डवेयर, और शायद अपने स्वयं के कर्नेल का निर्माण। संदर्भ स्विचिंग और बाधाओं को कम करने के लक्ष्य के लिए सभी। जिस बिंदु पर एक वास्तविक समय ओएस पर विचार किया जाना चाहिए। यह केवल लगातार डीकोड समय की संभावना में सुधार करेगा, गारंटी नहीं।

मेरा काम एक डाटा अधिग्रहण प्रणाली है कि FPGA एडीसी, पीसी, और ईथरनेट का एक संयोजन है विकसित कर रहा है। अनिवार्य रूप से, बहु-उद्देश्य पीसी की असंगतता का मतलब है कि कुछ विशेषताओं को समर्पित हार्डवेयर में स्थानांतरित किया जाना चाहिए। पीसी के लिए अपने अनुप्रयोग को विकसित करने के पेशेवरों/विपक्ष पर विचार करें, इसे हार्डवेयर में ले जाकर बनाम।