2008-10-10 11 views
5

मैं एक छोटा सा एप्लीकेशन लिख रहा हूं, जो एक एसडी कार्ड पर स्थिर दर पर जेपीईजी छवियां लिख रहा है। मैं एक EXT3 फाइल सिस्टम चुनता हूं, लेकिन एक ही व्यवहार एक EXT2 फाइल सिस्टम के साथ देखा गया था।एसडी कार्ड लिखने का प्रदर्शन

मेरे लेखन पाश इस तरह दिखता है:

get_image() 
fwrite() 
fsync() 

या इस तरह:

get_image() 
fopen() 
fwrite() 
fsync() 
fclose() 

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

कुछ परिशुद्धता: हाँ प्रत्येक फ़ाइल के बाद fsync करना आवश्यक है, क्योंकि मैं चाहता हूं कि छवि डिस्क पर हो, न कि कुछ उपयोगकर्ता या कर्नेल बफर में। Fsyncing के बिना, मेरे पास काफी बेहतर है, लेकिन अभी भी अस्वीकार्य स्टाल। मुझे नहीं लगता कि यह एक बफर समस्या है, क्योंकि पहली बार 50 एमबाइट्स लिखे जाने के बाद होता है। और मैन पेज के अनुसार, fsync यह सुनिश्चित करने के लिए ठीक है कि कोई डेटा buffered नहीं है।

औसत लिखने की दर के बारे में प्रेसिजन: मैं उस कार्ड पर टिकाऊ हूं जो मैं उपयोग कर रहा हूं। अगर मैं fsync को पूरा करने के लिए प्रतीक्षा करते समय आने वाली छवि को ढेर करता हूं, तो इस स्टॉल के बाद लिखने की स्थानांतरण दर बढ़ेगी और मैं जल्दी से औसत दर पर वापस जाऊंगा। औसत स्थानांतरण दर लगभग 1.4 MBytes/s है।

systeme एक आधुनिक लैपटॉप शेयर Kee (2.6.24.19)

उत्तर

1

मैं इस क्षेत्र में बहुत जानकार नहीं हूँ के साथ Ubuntu 8.04 चल रहा है, लेकिन लक्षण आपके द्वारा बताई गई एक बफर को भरने की तरह एक बहुत भयानक ध्वनि। आप फ़ाइल लेखक में या एसडी कार्ड के साथ संचार करने वाले आई/ओ डिवाइस में एक बफर भर सकते हैं। इससे पहले कि आप अधिक लिख सकें, आपको तब तक कार्ड को डेटा लिखने तक (जैसे बफर खाली करना) लिखना होगा। एसडी कार्ड विशेष रूप से तेज़ लेखकों नहीं हैं। यदि आप यह जांचने का कोई तरीका ढूंढ सकते हैं कि इन विरामों के दौरान वास्तव में कार्ड पर डेटा लिखा जा रहा है, तो यह मेरे सिद्धांत को सत्यापित करेगा। कुछ कार्ड पाठकों में एक एलईडी होता है जो डेटा को एक्सेस होने पर ब्लिंक करता है - जो शायद एक अच्छा संकेतक होगा।

बस एक कूबड़ ... कुछ नमक उसे अपने साथ ले :)

3

यह हर फ़ाइल के बाद आवश्यक है fsync() के लिए? ओएस को यह तय करने में बेहतर भाग्य हो सकता है कि एसडी कार्ड में सभी संलग्न छवियों को लिखने का अच्छा समय कब होता है (प्रत्येक छवि के लिए इसे करने के बजाए कई छवियों पर एसडी कार्ड फाइल सिस्टम में हेरफेर करने की स्टार्टअप लागत को कम करना)।

क्या आप अपने प्लेटफ़ॉर्म के बारे में कुछ और जानकारी प्रदान कर सकते हैं? धीरे-धीरे I/O बार सिस्टम पर अन्य प्रक्रियाओं, धीमी आई/ओ नियंत्रक, आदि के साथ करना पड़ सकता है ..

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

+0

pleaes ध्यान दें JFFS और तरह तरह के CompactFlash के रूप में कुछ फ्लैश उपकरणों,, जो अपने ही पहनने लेवलिंग कर के लिए एक अच्छा विचार नहीं कर रहे हैं। – Hasturkun

+1

क्या वे एक बुरा विचार हैं, या कॉम्पैक्ट फ्लैश पहनने के स्तर सिर्फ जेएफएफएस के लाभों को अस्वीकार करते हैं? यह एक ईमानदार सवाल है, मुझे कोई जानकारी नहीं है। मैं मानता हूं कि यह 'कच्चे' फ्लैश डिवाइस के लिए निश्चित रूप से बेहतर विकल्प है। –

2

AFAIK कुछ फ़्लैश डिस्क में वास्तव में खराब लेखन प्रदर्शन (esp। सस्ते ब्रांड) हैं। तो यदि आप अपने आवेदन की लिखने की गति को मापते हैं (fsync के लिए आवश्यक समय सहित), तो आपको क्या मिलता है? यह प्रति सेकंड बहुत कम मेगाबाइट्स के क्रम में आसानी से हो सकता है - सिर्फ इसलिए कि हार्डवेयर बेहतर नहीं करता है।

इसके अलावा, स्पष्ट रूप से लेखन बहुत धीमा हो सकता है यदि आप एक बड़े ब्लॉक के बजाय कई छोटे ब्लॉक लिखते हैं (फ्लैश डिस्क केवल खराब मामलों में प्रति सेकंड लगभग 10 लिख सकता है)। यह शायद कुछ ऐसा है जो कर्नेल बफर द्वारा कम किया जा सकता है, इसलिए fsync का उपयोग अक्सर लेखन को धीमा कर सकता है ...

बीटीडब्ल्यू। क्या आपने एफएटी 32 पर लेखन प्रदर्शन को माप लिया? मुझे लगता है कि यह वही है, लेकिन यदि नहीं, तो शायद कुछ अनुकूलन अभी भी उपलब्ध है?

1

हो सकता है इस में मदद मिलेगी - Benchmarking Filesystems:

... मैं काफी हैरान कैसे धीमी गति से ext3 समग्र था, के रूप में कई वितरण उनके डिफ़ॉल्ट फाइल सिस्टम के रूप में इस फाइल सिस्टम का उपयोग किया गया था ...

और "ext3 fsync batching":

... इस पैच उपायों बार यह डिस्क के लिए एक सौदे के लिए प्रतिबद्ध करने लगते हैं, और अंतर्निहित डिस्क की गति के आधार पर सोता है।

-1

शायद एसडी कार्ड पर भी विचार कर सकता है, क्या यह शून्य या नंद है? यह पृष्ठ एसडी कार्ड (2 एम/एस बनाम 20 एम/एस) के बीच परिमाण का क्रम दिखाता है।
http://www.robgalbraith.com/bins/camera_multi_page.asp?cid=6007-9597
मुझे लगता है कि जेडएफएस फ्लैश मेमोरी के लिए अनुकूलित है।

4

O_DIRECT के साथ फ़ाइल को खोलने का प्रयास करें और एप्लिकेशन स्तर में कैशिंग करें।

हम इसी मुद्दे से मुलाकात की जब हम एसटीबी बॉक्स में पीवीआर (पर्सनल वीडियो रिकॉर्ड) सुविधा लागू कर रहे थे। O_DIRECT चाल हमारी ज़रूरत फिनली से संतुष्ट है। (*)

O_DIRECT के बिना। write() का डेटा पहले कर्नेल बफर में कैश किया जाएगा और फिर जब आप fsync या कर्नेल कैश बफर पूर्ण करते हैं तो मीडिया पर फ़्लश किया जाएगा। (**)।

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

सुनिश्चित नहीं है कि यह आपकी समस्या का समाधान भी कर सकता है, लेकिन आप कोशिश कर सकते हैं।

* लिनस के critizeO_DIRECT के बावजूद, यह हमारी समस्याओं का समाधान करता है।

** आप O_DSYNC या O_SYNC

+0

बहुत दिलचस्प है। मुझे लगता है कि कैशिंग के साथ समस्या यह है कि सभी I/O अनुरोध (इस विशेष प्रणाली पर) एक कतार के माध्यम से जाते हैं। यदि कोई ब्लॉक डिवाइस (डिस्क) इसकी जर्नलिंग जानकारी को फ़्लश कर रहा है, तो किसी अन्य ब्लॉक डिवाइस (एसडी कार्ड) से संबंधित कोई भी लिंक अवरुद्ध नहीं होगा। मैं इस O_DIRECT चीज़ को आजमाउंगा। – shodanex

0

साथ फ़ाइल को खोलने नहीं था किसी को भी इस पढ़ने और 2.6.28 के ऊपर एक कर्नेल का उपयोग कर के लिए लगता है, सिफारिश ext3 के बजाय ext4 उपयोग करने के लिए है, जो एक फाइल सिस्टम है कि आप बेहतर प्रदर्शन के लिए ट्यून कर सकते हैं। सबसे अच्छा प्रदर्शन डेटा = लिखने के तरीके में प्राप्त होता है, जहां डेटा जर्नल नहीं किया जाता है। से डेटा मोड अनुभाग पढ़ें।

पहले से बनाई एक विभाजन है, तो /dev/sdb1 कहते हैं, तो इन कुछ कदम है कि journaling बिना ext4 के साथ यह फ़ॉर्मेट करने के लिए इस्तेमाल किया जा सकता हैं:

mkfs.ext4 /dev/sdb1 -L jp # Creates the ext4 filesystem 
tune2fs -o journal_data_writeback /dev/sdb1 # Set to writeback mode 
tune2fs -O ^has_journal /dev/sdb1 # Disable journaling 
sudo e2fsck -f /dev/sdb1 # Filesystem check is required 

फिर, आप इस विभाजन माउंट कर सकते हैं (या सेट एक प्रवेश /etc/fstab आप जानते हैं कि आप क्या कर रहे) इसी झंडे के साथ:

mount -t ext4 -O noatime,nodirame,data=writeback /dev/mmcblk0p1 /mnt/sd 

ext3 से एक अनुकूलित ext4 फाइलसिस्टम स्थानांतरण करने के लिए एक कठोर अंतर होना चाहिए। और, ज़ाहिर है, अगर आपका एसडी कार्ड तेज है तो मदद करनी चाहिए (यानी कक्षा 10)।

भी देखें https://developer.ridgerun.com/wiki/index.php/High_performance_SD_card_tuning_using_the_EXT4_file_system

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