विंडोज फाइल कॉपी डायलॉग: अनुमान क्यों है ... बीएडी?


38

अनुमान

xkcd

मुझे पता है कि विंडोज कॉपी डायलॉग (विंडोज एक्सपी में) पहले मेमोरी में कॉपी स्टोर करता है, और यह डायलॉग बंद होने के बाद भी कॉपी कर रहा है, इसलिए समय समाप्त हो गया है, लेकिन कॉपी बनाने में लगने वाले समय का अनुमान क्यों है इसलिए गलत है, तब भी जब मेमोरी कॉपी को अक्षम कर दिया गया है (विस्टा और विंडोज 7 में)? इतना मनमाना लगता है! पूरी कॉपी प्रक्रिया कैसे काम करती है, और विंडोज इसका सही अनुमान क्यों नहीं लगा सकता?



प्रगति बार फाइलों का # पूरा दिखाता है,% समय पूरा नहीं हुआ, फी।
कारक मिस्टिक


3
इसके अलावा, यह किसी भी ओएस पर लागू होना चाहिए , न केवल विंडोज, जैसा कि मेरा मानना ​​है कि बाधाएं सार्वभौमिक हैं।
क्लॉकवर्क-म्यूज़ियम

1
यह भी ध्यान दें कि मार्क रोसिनोविच का ब्लॉग पोस्ट: blogs.technet.com/b/markrussinovich/archive/2008/02/04/…
surfasb

जवाबों:


29

संक्षेप में: खराब एल्गोरिदम और उछल-कूद का अनुमान वास्तव में एक कार्यान्वयन कमजोरी है।

TeraCopy जैसे अन्य उपकरण बेहतर काम करते हैं। मुझे लगता है कि यह स्पष्ट करने लायक नहीं है कि उनका कार्यान्वयन अच्छा क्यों नहीं है। उन्होंने इस पर ध्यान दिया है और इसमें सुधार होगा।

क्या कठिन है:

  1. आपको मुख्य रूप से संसाधन में उतार-चढ़ाव (सीपीयू / नेटवर्क बैंडविड्थ / एचडीडी की गति) को ध्यान में रखना होगा
  2. आपको व्यवहार की भविष्यवाणी करके उस समय को एक्सट्रपलेशन करने की आवश्यकता है जो (विंडोज फाइल कॉपी निश्चित रूप से अभी बुरी तरह से करता है)।
  3. अपने मूल अनुमान के अनुसार समय के साथ समायोजन करें (मेरा मतलब है कि ऊपर दिए गए मजाकिया चित्र में छोटे समायोजन पसंद नहीं हैं!)

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

इस डायलॉग ने मुझे कई बार पागल भी किया:

  • एक पुराने WinNT सिस्टम पर, यदि आपके पास कॉपी करने के लिए बहुत सारी छोटी फाइलें थीं, तो यह प्रत्येक फ़ाइल के लिए नाम और अच्छा एनीमेशन प्रदर्शित करता था, जो पूरी प्रक्रिया को व्यावहारिक रूप से अनुपयोगी बनाता है।

आधुनिक विंडोज कॉपी सामान ज्यादा बेहतर नहीं है:

  • स्थानांतरित करने के लिए डेटा की मात्रा की गणना करने के लिए यह पहले एक लुकअप करने के लिए लगता है (जो कि मुझे लगता है कि यह करता है) तो यह उम्र लेता है यदि आप कई निर्देशिकाओं का चयन करते हैं जब तक कि यह प्रभावी रूप से काम करना शुरू न करे।
  • कुछ बिल्ट-इन टाइमआउट बड़ी फ़ाइलों की नकल करने के लिए पहुंचता है (> मेरे सिस्टम पर लगभग 60GB)। दर्द यह है कि यह आपको बताता है कि नेटवर्क पर पहले से ही 30GB से अधिक कॉपी किए जाने के बाद और यह बैंडवाइड और समय खो जाता है, क्योंकि आपको स्क्रैच से पुनरारंभ करना होगा!
  • एक कंप्यूटर से दूसरे कंप्यूटर पर फ़ाइलों की प्रतिलिपि किसी कारण से धीमी है। (मेरा मतलब है उपलब्ध नेटवर्क बैंडविड्थ के साथ तुलना में, अन्य उपकरणों का उपयोग करना तेज है इसलिए यह कम्प्यूटेशनल सीमा नहीं है।)

बहुत ही रोचक!
मैक्सिम ज़स्लावस्की

48

रेमंड चेन ने एक बार इस बारे में बहुत अच्छा लेख लिखा था। असल में, संवाद सिर्फ अनुमान लगा रहा है :)।

http://blogs.msdn.com/b/oldnewthing/archive/2004/01/06/47937.aspx

"क्योंकि कॉपी डायलॉग सिर्फ अनुमान लगा रहा है। यह भविष्य की भविष्यवाणी नहीं कर सकता है, लेकिन यह कोशिश करने के लिए मजबूर है। और कॉपी की शुरुआत में, जब बहुत कम इतिहास है, तो भविष्यवाणी वास्तव में खराब हो सकती है।

यहाँ एक सादृश्य है: मान लीजिए कि कोई आपको बताता है, "मैं 100 तक गिनती करने जा रहा हूँ, और आपको निरंतर अनुमान देने की आवश्यकता है कि जब मैं किया जाऊंगा।" वे बाहर शुरू करते हैं, "एक, दो, तीन ..."। आप देखते हैं कि वे प्रति सेकंड एक संख्या के बारे में जा रहे हैं, इसलिए आप 100 सेकंड का अनुमान लगाते हैं। उह, अब वे धीमे हो रहे हैं। "चार ... ... ... पांच ... ... ..." अब आपको अपना अनुमान शायद 200 सेकंड में बदलना होगा। अब वे गति देते हैं: "छह-सात-आठ-नौ" आपको अपने अनुमान को फिर से अपडेट करना होगा।

अब कोई व्यक्ति जो केवल आपके अनुमानों को सुन रहा है, न कि आपके गिने हुए व्यक्ति को लगता है कि आप अपने रॉकर से दूर हैं। आपका अनुमान 100 सेकंड से 200 सेकंड से 50 सेकंड तक चला गया; तुम्हारी समस्या क्या है? आप एक अच्छा अनुमान क्यों नहीं दे सकते?

फाइल कॉपी एक ही चीज है। शेल को पता है कि कितनी फाइलें और कितनी बाइट्स कॉपी होने वाली हैं, लेकिन यह नहीं पता कि हार्ड ड्राइव या नेटवर्क या इंटरनेट कितनी तेजी से होने वाला है, इसलिए इसका सिर्फ अनुमान लगाना है। यदि कॉपी थ्रूपुट बदल जाता है, तो नए हस्तांतरण दर को ध्यान में रखने के लिए अनुमान को बदलना होगा। "


8
वह जो सादृश्य दे रहा है, उसे एक शब्द में अभिव्यक्त किया जा सकता है: सांख्यिकी।
सर्फस

33

मैं दस तक गिनती करने जा रहा हूं, 1....2....3....410 तक पहुंचने के लिए कितने डॉट हैं?

5.6.7अभी का क्या? क्या आप संख्याओं के बीच के सभी पुराने बिंदुओं को ध्यान में रखते हैं और इसे औसत करते हैं, क्या आप केवल पिछले 4 अंतरालों को लेते हैं और उस औसत का उपयोग करते हैं, क्या आप केवल पिछले अंतराल को देखते हैं?

फ़ाइल ट्रांसफ़र में भी आपको यही समस्या है। फ़ाइल स्थानांतरण की गति स्थिर नहीं है, यह बहुत सारे कारकों के आधार पर गति बढ़ाता है और धीमा हो जाता है। Microsoft के इतने अधिक संख्या में जमा होने का कारण स्पेक्ट्रम की "केवल अंतिम अंतराल की गिनती" की ओर झुकाव है।

स्पेक्ट्रम के उस पक्ष के साथ कुछ भी गलत नहीं है, यह आपको अधिक सटीक "सेकंड प्रति सेकंड" देता है (वास्तविक समय में एक सेकंड काउंटर को एक सेकंड से नीचे चला जाता है) लेकिन इससे टाइमर का कुल ईटीए बहुत अधिक कूद जाता है ।

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


2
मुझे धड़कता है कि वे एक घातीय या नियमित रूप से चलती औसत क्यों नहीं करते थे ...
मेहरदाद

@ मेहरदाद मुझे लगता है कि विंडोज़ के हाल के संस्करण अधिक हैं, ईटीए समय विंडोज 7 और नए में 7zip की तरह अधिक व्यवहार करता है।
स्कॉट चैंबरलेन

15

वास्तव में इस बारे में Microsoft के रेमंड चेन द्वारा लगभग एक विवादास्पद जवाब है WAAAAAY बैक से, और पहेली के कुछ टुकड़े हैं।

क्योंकि कॉपी डायलॉग का सिर्फ अनुमान है। यह भविष्य की भविष्यवाणी नहीं कर सकता है, लेकिन यह कोशिश करने के लिए मजबूर है। और नकल की शुरुआत में, जब वहाँ बहुत कम इतिहास है, तो भविष्यवाणी वास्तव में खराब हो सकती है।

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


दिलचस्प की तरह, 2004 में वापस पहली टिप्पणी विस्तृत फ़ाइल कॉपी जानकारी ड्रॉपडाउन बाइट दिखाती है जो 2006 में विस्टा में नहीं पेश की गई थी।
स्कॉट चैंबरलेन

2
हाँ, चैट पर किसी ने यह भी बताया। मैं बजाय पर :) घूरना कि हल करती है कहने के लिए उपयोगकर्ता पूरा होने के लिए समय घूर की समस्या परीक्षा रहा हूँ, उसे रंगीन रेखांकन देकर
जर्नीमैन गीक

@JourneymanGeek "चैट पर किसी को" रिपोर्टिंग में! हाँ, जबकि यह एक बहुत ही आधिकारिक स्रोत है, यह ध्यान में रखना महत्वपूर्ण है कि यह 2004 से है, और यह बहुत पुराना है और संभवतः केवल विंडोज 8 पर उपयोग में आने वाले वर्तमान एल्गोरिदम से संबंधित है
बॉब

1
यहाँ विंडोज 8 पर एक संबंधित ब्लॉग पोस्ट है : "एक कॉपी को पूरा करने के लिए शेष समय का अनुमान लगाना लगभग किसी भी सटीकता के साथ करना असंभव है ... इसके बजाय कम आत्मविश्वास वाले अनुमान के साथ आने वाले समय का बहुत अधिक निवेश करें जो केवल थोड़ा सुधार होगा वर्तमान में, हमने उस जानकारी को प्रस्तुत करने पर ध्यान केंद्रित किया जिसके बारे में हम आश्वस्त थे ... "
केली थॉमस

12

यहाँ रेमंड चेन , माइक्रोसॉफ्ट में प्रिंसिपल सॉफ्टवेयर डिज़ाइन इंजीनियर द्वारा स्पष्टीकरण दिया गया है :

कॉपी डायलॉग ऐसे भयानक अनुमान क्यों देता है?

क्योंकि कॉपी डायलॉग का सिर्फ अनुमान है। यह भविष्य की भविष्यवाणी नहीं कर सकता है, लेकिन यह कोशिश करने के लिए मजबूर है। और नकल की शुरुआत में, जब वहाँ बहुत कम इतिहास है, तो भविष्यवाणी वास्तव में खराब हो सकती है।

यहाँ एक सादृश्य है: मान लीजिए कि कोई आपको बताता है, "मैं 100 तक गिनती करने जा रहा हूँ, और आपको निरंतर अनुमान देने की आवश्यकता है कि जब मैं किया जाऊंगा।" वे बाहर शुरू करते हैं, "एक, दो, तीन ..."। आप देखते हैं कि वे प्रति सेकंड एक संख्या के बारे में जा रहे हैं, इसलिए आप 100 सेकंड का अनुमान लगाते हैं। उह, अब वे धीमे हो रहे हैं। "चार ... ... ... पांच ... ... ..." अब आपको अपना अनुमान शायद 200 सेकंड में बदलना होगा। अब वे गति देते हैं: "छह-सात-आठ-नौ" आपको अपने अनुमान को फिर से अपडेट करना होगा।

ब्लॉग पोस्ट ऊपर उद्धृत इस मुद्दे का एक लंबा विचार-विमर्श, कुछ रोचक टिप्पणी के साथ है।

रेमंड चेन एक प्रसिद्ध व्यक्ति है, "माइक्रोसॉफ्ट का चक नॉरिस", मुझे नहीं लगता कि आप अधिक आधिकारिक उत्तर प्राप्त करने जा रहे हैं। मुझे यकीन है कि उसने कम से कम कोड को प्रश्न में देखा था।


9

स्पष्ट कारण यह है कि स्थानांतरण की गति समय के साथ बदलती रहती है, और इसी तरह औसत होती है, और इसी तरह भविष्यवाणी भी होती है। एक गैर-तकनीकी मित्र को यह समझाने के लिए, मैंने एक सादृश्य का उपयोग किया है जिसमें हवाई यात्रा शामिल है। आप अटलांटिक पर उड़ान भरने जा रहे हैं। जब आप प्रस्थान करने वाले हवाई अड्डे पर टैक्सी से पहुंचते हैं, तो आपका ईटीए लगभग दो महीने का होता है। जब आप अपनी अब तक की औसत गति के आधार पर आने वाले हवाई अड्डे पर उतरते हैं, तो आप 5 सेकंड में अपने मित्र के घर पहुंच जाएंगे।

लेकिन आपको यह सराहना करने की आवश्यकता है कि वास्तव में गति कितनी भिन्न हो सकती है, यहां तक ​​कि एक ही डिस्क के भीतर फ़ाइलों की नकल करने या दो स्थानीय डिस्क के बीच एक पूर्वानुमानित परिदृश्य की तरह प्रतीत होने वाले के साथ भी। विंडोज 8 में मुझे जो नई सुविधाएँ पसंद हैं उनमें से एक है समय के साथ गति को ग्राफ़ करने की क्षमता यदि आप "अधिक विवरण" पर क्लिक करते हैं। यदि आपके पास विंडोज 8 मशीन तक पहुंच नहीं है, तो बहुत सारे उदाहरणों के लिए विंडोज 8 कॉपी संवाद के लिए छवियां खोजें । उनमें से कई काफी सपाट हैं, लेकिन उनमें से कई भी विचलित रूप से ऊबड़-खाबड़ हैं, इस बात पर कि आप आश्चर्य करते हैं कि क्या हार्ड ड्राइव वास्तव में स्वस्थ है, जब यह शून्य हो जाता है।

इनमें से कुछ धक्कों की संभावना फ़ाइल आकार में भिन्नता के कारण होती है - छोटे क्षेत्रों में अधिक पहुंच होती है, जो चीजों को धीमा कर देती है, विशेष रूप से एक यांत्रिक हार्ड ड्राइव पर जिसे इसके पढ़े हुए सिर को हिलाने की जरूरत होती है - लेकिन कुछ यह सिर्फ एक सस्ती ड्राइव हो सकती है जो प्लेटर्स को नुकसान से बचाने के लिए मामूली स्पर्श पर स्टॉल।

बेहतर और बदतर ईटीए भविष्यवाणी एल्गोरिदम हैं, लेकिन एक सटीक भविष्यवाणी के लिए, कंप्यूटर को सभी को जानना होगा। एल्गोरिथ्म को "स्मार्ट" बनाने की कोशिश करने का जोखिम यह है कि यह नए, अप्रत्याशित, ऐसे मामले पैदा कर सकता है जहां यह और भी अधिक गलत है।

विंडोज 8 कॉपी डायलॉग

विंडोज 8 कॉपी डायलॉग 2


4

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

यह शायद ही कभी एक बग के रूप में शायद ही कभी-सटीक जानकारी का बेकार प्रदर्शन होता है। इसे ठीक करने का सबसे अच्छा तरीका अपनी आँखें बंद करना है। अनदेखी करो इसे। ;-)

शायद वहाँ एक कार्यक्रम है जो फ़ाइलों को कॉपी / संपीड़ित कर सकता है और समाप्त होने पर एक अलार्म ध्वनि बना सकता है। यह वास्तव में उपयोगी होगा। जब हम विंडोज के लिए घर वापसी का इंतजार करते हैं तो हम थोड़ा झपकी ले सकते थे।


4

मुझे लगता है कि रोनाल्ड के जवाब से जुड़े ब्लॉग पोस्ट की टिप्पणियों में से एक में कारण स्पष्ट रूप से समझाया गया था :

इसमें एक भयानक अनुमान एल्गोरिथ्म है। कोई बहाना नहीं हैं। यदि 1000 1000KB फ़ाइलों और 10 1MB फ़ाइलों की प्रतिलिपि बनाना है, तो उसे लगता है कि यह 1 MB फ़ाइल के साथ 1KB फ़ाइलों के साथ व्यस्त होगा।

इस तरह के भयानक अनुमानों का कारण यह है कि यह अच्छी तरह से नहीं किया गया है। जाहिर है कि यह कभी भी 100% सटीक नहीं हो सकता है, लेकिन यह बहुत बेहतर हो सकता है।


1
यह जानना कि विंडोज़ में कितनी बड़ी फ़ाइल है, इसे खोलने की आवश्यकता है, और विंडोज में एक फ़ाइल खोलने का मतलब है इसे पढ़ना। और सभी फ़ाइलों को खोलने के बजाय यह देखने के लिए कि वे कितनी बड़ी संख्या में हैं, यह अनुमान लगाने के लिए कि प्रतिलिपि कितनी देर तक चलेगी, विंडोज अपने समय का उपयोग वास्तव में फ़ाइलों की प्रतिलिपि बनाने का निर्णय लेता है - आखिरकार, आपने इसे करने के लिए कहा है।
सिक्योरिटीमैट

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

4

कॉपी प्रक्रिया में तेजी लाने के लिए (कॉपी-संबंधित संचालन करने के बजाय समय अनुमानों की गणना करने में बहुत अधिक समय खर्च न करें), एक्सप्लोरर में निर्मित विंडोज़ कॉपी उपयोगिता सीमित लिखावट को पूरा करने के बारे में सीमित मात्रा में जानकारी बनाए रखती है। हर बार जब इसे शेष समय की गणना करने की आवश्यकता होती है, तो यह केवल समय लिखता है कि ऑपरेशन की औसत मात्रा कितनी है, और फिर शेष लेखन कार्यों की संख्या से गुणा करता है।

समस्या यह है कि लिखने के संचालन के लिए जितना समय लगता है वह निरंतर नहीं है - यह वास्तव में महत्वपूर्ण रूप से भिन्न हो सकता है। तो, यह बदले में, समय अनुमान में महत्वपूर्ण परिवर्तन पैदा करता है।


मुझे नहीं लगता कि आप इस पर काफी हद तक सही हैं - आप केवल 2 नंबर - वर्तमान औसत [ A] और उस औसत को प्राप्त करने के लिए उपयोग किए जाने वाले डेटा बिंदुओं की संख्या का उपयोग करने योग्य औसत बनाए रख सकते हैं n। फिर इसे अपडेट करने के लिए, यह सिर्फ एक मामला है (A*n + [New value])/[n+1]। इसके अलावा, चूंकि कॉपी ऑपरेशन लगभग हमेशा IO- बाउंड नहीं CPU-बाउंड होते हैं, एक साधारण गणना जैसे कि हर कुछ सेकंड कुछ भी नहीं है। दूसरी ओर, अंतिम nलिखने का औसत रखने के लिए nतत्वों की एक सरणी / कतार / ढेर की आवश्यकता होती है - इसलिए आप जानते हैं कि किस मूल्य को बेदखल किया जाना है।
बेसिक

अच्छी बात! तो क्यों बिल्ली यह सब जगह है? : पी
ब्रायन ग्रैडिन

मुझे लगता है कि उन्होंने अधिक संवेदनशील औसत करके, केवल कुछ पिछले लेखों को ध्यान में रखकर - और बहुत कम उठाया। उस ने कहा, मेरे पास स्रोत नहीं है इसलिए कौन जानता है?
बेसिक

4

खाते में लेने के लिए 3 कारक हैं:

  1. स्थानांतरण का कुल आकार।
  2. स्थानांतरित होने वाली फ़ाइलों की संख्या।
  3. मीडिया के "व्यस्त-नेस", और संभवतः कनेक्शन।

नंबर 1 और 3 का स्थानांतरण समय की गणना पर सबसे स्पष्ट प्रभाव होगा, लेकिन बहुत से लोग नंबर 2 के लिए जिम्मेदार नहीं हैं। इसका बहुत बड़ा प्रभाव हो सकता है कि हस्तांतरण कितना समय लगेगा, और इसे निर्धारित करना मुश्किल है।

मूल रूप से, हर बार किसी फाइल के लिखे जाने के बाद फाइलसिस्टम को फ़ाइल के बारे में मेटाडेटा लिखने की जरूरत होती है, जैसे। स्वामित्व, अनुमतियाँ, निर्माण / संशोधन / एक्सेस समय, आदि। विशेष फाइलसिस्टम के आधार पर, यह जानकारी डिस्क के एक हिस्से को बहुत 'दूर' लिखी जा सकती है जहाँ से वे फाइल लिखी जा रही हैं। यह फाइलसिस्टम ओवरहेड वह है जो प्रतीत होता है कि सरल हस्तांतरण को एक लंबा समय लग सकता है, और / या समय का अनुमान बेतहाशा उतार-चढ़ाव करता है।

उदाहरण के लिए: एक बड़ी फ़ाइल को स्थानांतरित करना आप देखेंगे कि अनुमान स्थिर है और काफी सटीक है, लेकिन अलग-अलग आकारों की सैकड़ों फ़ाइलों को स्थानांतरित कर रहा है, लेकिन एक ही कुल आकार में अधिक समय लग सकता है और एक फिट पिच करने के लिए समय अनुमान का कारण बन सकता है।


4

वर्तमान आकलन एल्गोरिदम में तीन कमियां हैं।

आम धारणा के विपरीत, वे हमारे हाथ फेंकने के लिए लगभग मुश्किल नहीं हैं।

अधिकांश लोग ब्लॉग लिखने का कारण, और यहाँ के लोगों को संभावना के बारे में पता नहीं है क्योंकि मैं अध्ययन और स्कूली शिक्षा के क्षेत्र के कारण बता सकता हूं। [अभी तक एक बहुत ही आरामदायक उपाय संभव है [ब्लॉग लेखकों की तुलना में अधिक हाल के प्रशिक्षण के साथ स्नातक] [एक मल्टीबिलियन डॉलर कंपनी] माइक्रोसॉफ्ट।

मैं मोटे तौर पर यह समझाने का प्रयास करूंगा कि क्यों।


विफलता के बिंदु इस प्रकार हैं। गिरी:

1. कर्नेल के दायरे के बाहर की परिस्थितियों के कारण भविष्य के IO भार का अनुमान पूर्वक नहीं लगा सकते

  • इस बारे में कुछ नहीं किया जाना चाहिए क्योंकि यह एक बहुत ही अनबिके P = NP समस्या है।

2. विस्तार के किसी भी उपयोगी स्तर में IO के आंकड़ों को ट्रैक नहीं करता है। यूटिलाइजेशन डिस्क / नेटवर्क रीड / राइट स्पीड की तुलना में बहुत व्यापक अवधारणा है

  • इस बारे में बहुत कम ज़रूरत है, सबसे बुनियादी IO उपयोग की जानकारी को ट्रैक करने की तुलना में थोड़ा अधिक

    • डिस्क से
      • औसत पढ़ने की गति आयाम 1 ए
      • फ़ाइलों की औसत गति लिखने की गति 2a
    • प्रति-क्वांटा * के आधार पर
      • फ़ाइल का आकार आयाम बी
      • डिस्क के आयाम पर फ़ाइल का स्थान c
    • * 3 श्रेणियों से अधिक [संभावना] में परिमाणित नहीं। आयाम में कमी हमें कुछ के लिए निर्धारित करने में मदद करेगी लेकिन 3 के लिए (शायद प्रभावी) बेहतर-से-कुछ नहीं भविष्यवाणी तंत्र के लिए बहुत कुछ होना चाहिए:
      • फाइल का आकार
        • रोशनी
        • मध्यम
        • भारी
      • स्थान [तलाश के विलंबता की सूचना]
        • शुरुआत
        • मध्य
        • तुम समझ गए
      • फ़ाइल का आकार और स्थान रीड / राइट स्पीड के साथ बेमानी / ओवरलैप है, यह जानबूझकर है
    • हमें यह जानने की आवश्यकता है कि डिस्क कितनी "व्यस्त" है ताकि हम यह मान सकें कि यह व्यस्त आयाम d होगा
      • पढ़ी जा रही फ़ाइलों की मात्रा से गणना की, उनके संबंधित वजन के साथ सजाया गया
      • नकल की शुरुआत में समय का अनुमान लगाने के लिए उपयोग किया जाता है ... भविष्य में अपेक्षित लोड पर आधारित संवाद अगर इस कॉपी संवाद से अलग सब कुछ जारी है जैसा कि अभी है
    • ... उद्देश्य के लिए रिकॉर्डिंग की विधि यहाँ पेटेंट करने योग्य है

3. क्या उन्हें ट्रैक किया गया था , उत्तराधिकार के लिए उपयोग नहीं किया जाएगा

  • यहाँ बहुत कम किया गया है, जहाँ हम अधिकतर काम करते हैं
  • यह वह जगह है जहां हम # 2 का उपयोग करने के लिए डेटा डालते हैं
    • फ़ाइल भार और स्थानों का मोटा सांख्यिकीय विश्लेषण यह निर्धारित करने के लिए कि हम क्या करने जा रहे हैं। वजन + स्थान हमें एक भविष्यवाणी देता है
    • वर्तमान डिस्क लोड भार और स्थानों के साथ संयोजन करें
    • अनुमान लगाने के लिए हम क्या सोचते हैं फ़ाइलों की संख्या की औसत पढ़ें / लिखें गति आयाम च हो जाएगा
    • हम अपने मॉडल की धुन ठीक करने की तुलना करते हैं
    • जो हमें प्रगति बार और पूर्णता के समय का सही अनुमान लगाएगा
  • भविष्यवाणी करने के उद्देश्य से विश्लेषण करने की विधि ... यहाँ पेटेंट करने योग्य है

इन सबके बीच हमारा मॉडल केवल 2a = F * (bxc) + d जटिल है

जहाँ a, b, और c में 3 स्थितियाँ हैं: फ़ाइल प्रबंधक कॉपी करने से पहले फाइलों (या सिर्फ मेटाडेटा) पर झांकता है, और F * (bxc) + d एक महंगी संगणना नहीं है; यदि आप अधिक सटीक कुछ चाहते हैं तो अधिक राज्यों के साथ एक लुकअप तालिका का उपयोग करें - शायद ही कोई गणना हो।

ध्यान दें: आयाम यहाँ एक थाली के लिए हैं, एक SSD-- शुरुआत / मध्य / अंत के साथ अलग नहीं होगा

मैंने जो भी वर्णन किया था और पिछले कार्यान्वयनों के बीच महत्वपूर्ण अंतर जो हमने अब तक देखा है, संक्षेप में, डिस्क पर फ़ाइलों के अवलोकन और फ़ाइल में गड़बड़ी / एन्ट्रॉपी और इसे उपयोग करने के लिए [अधिक] सटीक रूप से डिस्क उपयोग के समय तत्व के लिए खाता होगा।

(पेटेंट पाठक के लिए एक अभ्यास के रूप में छोड़ दिया जाता है ...)


@ मैं क्या कर रहा हूँ, अब यह कैसा है?
2

काफी बेहतर। साइट का उपयोग करने के लिए शुभकामनाएं और समुदाय में शामिल होने के लिए धन्यवाद।
मैं कहता हूं कि

3

जब आप यह अनुमान लगाने की कोशिश कर रहे हैं कि बहुत सारे "अज्ञात" वैरिएबल हैं, तो आपको कितना समय लगेगा। उदाहरण के लिए, जबकि कार्यक्रम जानता है कि 3500 फाइलें हैं, और यह कि फाइलें 3.5 जीबी (3500 एमबी) की मात्रा हैं, क्या इसका मतलब है कि प्रत्येक फाइल 1 एमबी है? जरुरी नहीं। बहुत सारी 4 केबी फाइलें, और बहुत सी 100 एमबी फाइलें, और बीच में कुछ अन्य हो सकती हैं। इसके अलावा, आपको यह ध्यान रखना होगा कि फाइलें कहां से आ रही हैं और वे कहां जा रहे हैं (जैसे मीडिया।) सबसे बड़ी अड़चन क्या है? आप एक वीपीएन सुरंग के माध्यम से HDD से फ़ाइलों को कॉपी करने की कोशिश कैसे करते हैं ? आप एक सर्वोत्तम स्थिति देते हैं, और फिर वास्तविक समय में अपने काउंटरों को समायोजित करते हैं। यही कारण है कि आप उन प्रगति मीटर को मक्खी पर बदलते हुए देखते हैं।


2

गणितीय रूप से सही मॉडल वास्तव में एक भोली औसत और एक्सट्रपलेशन है:

transfer speed = data copied / time elapsed
time remaining = data remaining / transfer speed

कारण यह है कि बड़ी संख्याओं के कानून द्वारा स्थानीय उतार-चढ़ाव औसतन स्थानांतरण गति को रद्द कर देगा , और यह आपको सबसे स्थिर परिणाम देगा।

क्या माइक्रोसॉफ्ट लगता है ऐसा करने के लिए गणना करने के लिए है स्थानांतरण गति नवीनतम समय सीमा पर। इसका मतलब है कि प्रत्येक स्थानीय उतार-चढ़ाव से परिणाम में काफी बदलाव आता है।


2
आपका मॉडल ठीक से लंबे समय से चल रही गड़बड़ी को ठीक से हैंडल नहीं करेगा, जैसे समानांतर में अन्य फ़ाइल स्थानांतरण शुरू करना, और मुझे यह बताना जारी रखेगा कि यह केवल 5 और मिनट लेगा, भले ही डेटा की समान मात्रा में सिर्फ 20 मिनट लगे हों। एक भारित चलती औसत अधिक सटीक हो सकती है।
डैनियल बेक

@ डैनियलबेक: बिल्कुल सही नहीं है। अपेक्षित समय धीरे-धीरे बढ़ेगा। सवाल यह है कि यह कितनी तेजी से बढ़ेगा? खैर, यह बीता हुआ समय पर निर्भर करता है। यदि यह एक लंबा ऑपरेशन था, उदाहरण के लिए, यह पहले से ही 5 घंटों के लिए कॉपी कर रहा था, तो यह अपेक्षा को बहुत अधिक नहीं बढ़ाएगा। लेकिन क्या 5 घंटे के ऑपरेशन के लिए 15 मिनट की अशुद्धि मायने रखती है? नहीं। बिंदु यह है कि यह आपको सापेक्ष त्रुटि के संदर्भ में सबसे अच्छा अनुमान देता है। इसके अलावा, आप कुछ ऐसा नहीं कर सकते जो हर परिदृश्य में बेहतर काम करे ।
ybungalobill

2
आपके मॉडल की समस्या यह है कि यह स्थानांतरण के माध्यम से दर परिवर्तन को स्थानांतरित करने के लिए बिल्कुल प्रतिक्रिया नहीं करता है। यह तेज-प्रतिक्रियाशील विंडोज फाइल ट्रांसफर उदाहरण के समान ही अपर्याप्त होगा : पहले 10MB / s पर 60GB ट्रांसफर। प्रारंभ में समय बचा: 100 मिनट। 54GB ट्रांसफर करें और 2MB / s पर ड्रॉप करें। 90 मिनट के बाद: अनुमानित समय 54GB: 10min पर छोड़ दिया गया। 54GB: 50min पर वास्तविक समय बचा है। 115 मिनट के बाद : अनुमानित समय 57GB: 6min पर छोड़ दिया। 57GB: 25min पर वास्तविक समय बचा है। 131.67 मिनट के बाद : अनुमानित समय 59GB : 2.23 मिनट पर छोड़ दिया गया। 59GB: 8.33 मिनट पर वास्तविक समय बचा।
डैनियल बेक

@ डैनियलबेक: पूरा स्थानांतरण 150 मिनट तक चलता है, इसलिए स्थानांतरण की शुरुआत में अधिकतम सापेक्ष त्रुटि 50% है जहां आप कोई बेहतर काम नहीं कर सकते। 54 जीबी में यह कुल मिलाकर केवल 14% है। (यदि आपको 150 मिनट लगते हैं, तो 20 मिनट क्यों?) वास्तव में एक बहुत अच्छा अनुमान है ... यह कहा, मैं आपकी बात समझता हूं। इस सुधार करने के लिए जिस तरह से किया जाता है नहीं मूविंग औसत क्योंकि आप विंडो के क्या आकार यह होना चाहिए नहीं पता कर सकते भारित (इस ऑपरेशन, पर फ़ाइल कॉपी की तरह मिनट लेने की उम्मीद है
ybungalobill

या पी 2 पी फ़ाइल साझाकरण प्रोटोकॉल के माध्यम से घंटे जहां आपको 10 एमबी / एस के 10 मिनट और 0 एमबी / एस के 10 मिनट मिलते हैं। इसे सुधारने का तरीका समय के हिसाब से औसत भार उठाना है, आकार से नहीं।
ybungalobill

1
There is some way to refine or correct this kind of "bug"?

जैसा कि रोनाल्ड वैन डोर्न ने कहा, यह मूल रूप से सिर्फ अनुमान है। बेशक, इसका मतलब यह नहीं है कि यह एक बेहतर अनुमानक नहीं हो सकता है। ऐसी बहुत सारी संख्याएँ हैं जिनका उपयोग इस गणना के लिए किया जा सकता है।

  1. सबसे अच्छा तरीका, सबसे महंगा तरीका, पिछली 'प्रतियों' का इतिहास रखना और फिर एक अनुमान की गणना के लिए कृत्रिम बुद्धिमत्ता एल्गोरिदम का उपयोग करना होगा।
  2. एक शोध के आधार पर एक सूत्र का निर्माण कर सकता है कि इसे कितना समय लेना चाहिए। वे चीजों को ध्यान में रख सकते हैं जैसे: फाइल सिस्टम, फाइलों की संख्या, फाइलों का आकार, डिस्क की तलाश का समय, डिस्क बल्क रीड / राइट स्पीड, डिस्क पर फाइलों का स्थान (विखंडन), वर्तमान डिस्क उपयोग।
  3. दो का मिश्रण। अर्थात। कुछ बेंचमार्क यह पता लगाने के लिए कि कुछ निश्चित ऑपरेशनों में कितना समय लगता है और फिर उन्हें सरल सूत्रों के लिए एक इतिहास के रूप में उपयोग किया जाता है।

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

हालाँकि, यदि आप 7-ज़िप के साथ कुछ कंप्रेस करते हैं, तो आप देखेंगे कि यह विंडोज़ की तुलना में अनुमान लगाने में बहुत बेहतर है। मुझे संदेह है कि यह कुछ जटिल है, बस थोड़ा बेहतर अनुमानक है।


1

संक्षेप में, गणना वर्तमान स्थानांतरण गति पर आधारित है ।

उदाहरण के लिए: यदि आपका ट्रांसफर रेट डूब जाता है, क्योंकि विंडोज़ को बड़ी मात्रा में छोटी फ़ाइलों को कॉपी करना पड़ता है, तो बड़ी फ़ाइलों के लिए अपेक्षित समय रैखिक रूप से और इसके विपरीत होता है

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


1

MSDN ब्लॉग पोस्ट में कुछ दिलचस्प जवाब हैं हमारी फ़ाइल प्रबंधन मूल बातें सुधारना: इस बारे में कॉपी, स्थानांतरित, नाम बदलना और हटाना । क्यों यह कठिन है:

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

और वे कैसे सुधार कर रहे हैं,

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

कहा कि, यदि आप वास्तव में सिर्फ दिए गए अनुमान को सुधारना चाहते हैं और प्रगति पट्टी को बनाए रखना चाहते हैं, तो आप स्लिपडाउन टिप्पणी में सुझाए गए कुछ कर सकते हैं :

फाइलसिस्टम पर प्रत्येक स्टोरेज डिवाइस के लिए अपेक्षित गति की तालिका बनाए रखें। फाइलसिस्टम की जानकारी को पढ़ने में कितना समय लगता है रिकॉर्ड करें। जब कोई डिवाइस माउंट किया जाता है, अगर यह डिवाइस के प्रकार के लिए उचित है, तो मध्य और अंत की तलाश करें, वहां गति को भी मापें। स्थानों पर पढ़ने और लिखने की गति के लिए अनुमानित वक्र प्राप्त करें, और भविष्य के अनुमानों के लिए उन का उपयोग करें। भविष्य के पढ़ने और लिखने के संचालन के लिए, ध्यान दें कि वे कहां हैं और वे कितनी तेजी से चलते हैं, और तदनुसार घटता समायोजित करें।

जब कोई ऑपरेशन शुरू होता है, तो संबंधित उपकरणों के लिए इनपुट और आउटपुट के लिए घटता को देखें। लक्ष्य स्थान के लिए अपेक्षित गति ज्ञात करें। अनुमान के लिए जो भी कम गति का उपयोग किया जाना चाहिए।


1

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


जबकि दिलचस्प, यह सवाल का जवाब नहीं है। जवाब देने से पहले कैसे पढ़ें ।
उपयोगकर्ता 99572

0

मैंने सिर्फ USB HDD से अपने मुख्य ड्राइव में 200GB की प्रतिलिपि बनाई। करीब 130000 फाइलें थीं

पहले 4-5 मिनट के बाद मैंने देखा कि:

  • सबसे छोटी फ़ाइलों के लिए, दर लगभग 100 फाइलें प्रति सेकंड लगभग 600KB / s पर थी
  • और बड़ी फ़ाइलों के लिए यह 70MB / s जैसा था

शुरुआत में खिड़कियों ने अनुमान को 1 घंटे से 5+ घंटे तक बदल दिया और फिर 1 घंटे और इतने पर वापस कर दिया। अंत में जैसे 95% यह अभी भी 10 मिनट से 10+ घंटे तक अनुमान बदल रहा था। इसलिए यह अधिक सटीक बनने के बजाय कम और कम सटीक होता जा रहा था।

सरल गणित शो:

प्रति सेकंड 100 फाइलों पर 130,000 फाइलें = 22 मिनट

200,000 एमबी 70 एमबी प्रति सेकंड = 47 मिनट पर

22 मिनट - आकार में कुछ किलोबाइट की फ़ाइलों की प्रतिलिपि बनाने के समय में खो गया। 47 मिनट - यदि वास्तविक समय नहीं है, तो वास्तविक डेटा को स्थानांतरित करने की आवश्यकता होगी।

22min + 47min का योग अधिकतम अधिकतम समय है जो संभवतः ले सकता है।

तो जाहिर है अनुमान 47 से 69 मिनट के बीच होना चाहिए ।

संवाद 90% पर क्या दिखाता है: "मैं 1MB / s पर कुछ छोटी फ़ाइलों की प्रतिलिपि बना रहा हूं, 20GB अधिक डेटा है, इसे पूरा करने में 5:30 घंटे लगेंगे।

कुछ सेकंड बाद: "मैं यहाँ एक बड़ी फाइल की नकल कर रहा हूँ, 70mb / s पर इसे पूरा होने में 4 मिनट लगेंगे।

मानव वास्तव में एक ही संवाद से क्या देखता है: 120,000 फाइलें और 180GB पहले से ही 40 मिनट के लिए कॉपी किए जाते हैं। बाकी 10000 फाइलें और 20GB लगभग 5min लेना चाहिए

संवाद गणना के लिए पर्याप्त जानकारी देता है जो प्रत्येक सेकंड में अधिक से अधिक सटीक होती है। यह जानता है कि कौन सी छोटी फाइलों की नकल की जाती है। यह पता है कि बड़ी फ़ाइलों को किस गति से कॉपी किया जाता है। यह भी पता है कि कितनी फाइलें और कितनी बाइट्स बाकी हैं।

केवल ऊपरी और निचली सीमा निर्धारित करके इतनी सटीक धारणा बनाना इतना सरल है।

छोटी फ़ाइलों से पहले बड़ी फ़ाइलों के मामले में संवाद थोड़ा अधिक सही डेटा दिखाता है। यदि यह मामला 40 मिनट से शुरू होता है, और 30 मिनट के बाद यह छोटी फ़ाइलों की नकल करना शुरू कर देता है और कहता है "अच्छी तरह से मुझे 20 मिनट और चाहिए"।

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


यह वास्तव में सवाल का जवाब नहीं देता है।
DavidPostill

यह वास्तव में इसका उत्तर देता है, यदि आप ध्यान से पढ़ रहे हैं। वे दो प्रकार के बुरे अनुमान हैं और मैंने समझाया है कि वे एक उदाहरण आधारित रिवर्स इंजीनियरिंग बिंदु से क्यों होते हैं।
Xizario
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.