উইন্ডোজ ফাইল অনুলিপি কথোপকথন: অনুমান কেন এত… বিএডি?

Question

xkcd

আমি জানি যে উইন্ডোজ অনুলিপি ডায়লগ (উইন্ডোজ এক্সপিতে) প্রথমে কপিটি মেমরির মধ্যে সঞ্চয় করে এবং ডায়লগটি বন্ধ হওয়ার পরে এটি অনুলিপি করে চলেছে, তাই সময়টি বন্ধ রয়েছে, তবে কেন অনুলিপিটি তৈরি করতে সময় লাগবে কেন এতটা ভুল, এমনকি যখন মেমোরি অনুলিপি অক্ষম করা হয়েছে (ভিস্তা এবং উইন্ডোজ 7 এ)? মনে হয় এত স্বেচ্ছাচারী! সম্পূর্ণ অনুলিপি পদ্ধতি কীভাবে কাজ করে এবং উইন্ডোজ কেন এটি সঠিকভাবে অনুমান করতে পারে না?

Comments

superuser.com/questions/21980/user-interface-annoyances/…

— ট্র্যাজি

অগ্রগতি বারটি ফাইলগুলির # টি দেখায়,% সময় শেষ হয় না, ফায়ি i

— ফ্যাক্টর মিস্টিক

imgs.xkcd.com/comics/estimation.png

— এবার Smudge

এছাড়াও, এটি কেবল উইন্ডোজ নয়, কোনও ওএসের ক্ষেত্রে প্রযোজ্য কারণ আমি বিশ্বাস করি যে সীমাবদ্ধতা সর্বজনীন।

— ক্লকওয়ার্ক-মিউজিক

মার্ক রাশিনোভিচের ব্লগ পোস্টটিও লক্ষণীয়: ব্লগস.টেকনেট

— বি

Answer 1

সংক্ষেপে: দরিদ্র অ্যালগরিদম এবং ঝাপটায় অনুমান আসলে বাস্তবায়নের দুর্বলতা।

অন্যান্য সরঞ্জাম যেমন টেরাকপি আরও ভাল কাজ করে। আমি মনে করি তাদের বাস্তবায়ন কেন ভাল নয় তা ব্যাখ্যা করার মতো নয়। তারা এটি লক্ষ্য করেছে এবং উন্নতি করবে।

কি কঠিন:

1. আপনার অ্যাকাউন্ট রিসোর্স ওঠানামা নিতে হবে (সিপিইউ / নেটওয়ার্ক ব্যান্ডউইথ / এইচডিডি গতি মূলত)
2. আচরণের পূর্বাভাসের দ্বারা আপনার যে সময় লাগবে তা আপনাকে এক্সট্রোপোলেট করা দরকার (উইন্ডোজ ফাইল কপিটি এখনই খারাপভাবে কী করবে)।
3. আপনার আসল অনুমানের সাথে সময়ের সাথে সাথে সামঞ্জস্য করুন (মানে উপরের মজার ছবিতে ছোট ছোট সামঞ্জস্যগুলি নয়!)

এর জন্য কেবল বাইটের পরিমাণই নয় ফাইলগুলি তৈরি করতে পরিমাণের ভূমিকা রাখে। আপনার যদি এক মিলিয়ন 1 কেবি ফাইল বা হাজার 1 এমবি ফাইল থাকে তবে পরিস্থিতি একেবারেই আলাদা হবে কারণ প্রাক্তনটির অনেকগুলি ফাইল তৈরির ওভারহেড রয়েছে। ব্যবহৃত ফাইলসিস্টেমের উপর নির্ভর করে, এটি আসলে ডেটা স্থানান্তর করার চেয়ে বেশি সময় নিতে পারে।

এই কথোপকথনটি আমাকে বেশ কয়েকবার পাগল করেছিল:

• পুরানো উইনটিটি সিস্টেমে, যদি আপনার অনুলিপি করার জন্য প্রচুর ছোট ফাইল থাকে, তবে এটি প্রতিটি ফাইলের নাম এবং দুর্দান্ত অ্যানিমেশন প্রদর্শন করেছিল যাতে পুরো প্রক্রিয়াটি ব্যবহারিকভাবে অকেজো হয়ে যায়।

আধুনিক উইন্ডোজ অনুলিপি জিনিসগুলি আরও ভাল নয়:

• স্থানান্তর করতে তথ্যের পরিমাণ গণনা করাতে এটি প্রথমে একটি অনুসন্ধান করা বলে মনে হয় (এটি আমি মনে করি এটি করে) তাই আপনি কার্যকরভাবে কাজটি শুরু না হওয়া অবধি আপনি বহু ডিরেক্টরি নির্বাচন করেন যদি এটি বয়স হয় ages
• কিছু অন্তর্নির্মিত সময়সীমা বড় ফাইলগুলি অনুলিপি করে (> আমার সিস্টেমে প্রায় 60 জিবি)। ব্যথাটি হ'ল এটি আপনাকে বলে যে ইতিমধ্যে 30 জিবি-র বেশি নেটওয়ার্কে অনুলিপি করার পরে এবং এটি ব্যান্ডউইথ এবং সময় হারিয়ে গেছে কারণ আপনাকে স্ক্র্যাচ থেকে পুনরায় আরম্ভ করতে হবে!
• এক কারণে অন্য কম্পিউটারে ফাইলের অনুলিপি কিছু কারণে ধীর slow (আমার অর্থ উপলব্ধ নেটওয়ার্ক ব্যান্ডউইথের সাথে তুলনা করা, অন্যান্য সরঞ্জামগুলি ব্যবহার করে এটি দ্রুত হয় এটি কোনও গণনীয় সীমাবদ্ধতা নয় not)

Comments

অনেক আগ্রহব্যাঞ্জক!

— ম্যাক্সিম জাস্লাভস্কি

Answer 2

রেমন্ড চেন একবার এই সম্পর্কে একটি খুব সুন্দর নিবন্ধ লিখেছিলেন। মূলত, ডায়ালগটি কেবল অনুমান করা যায় :)।

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

"কারণ অনুলিপি কথোপকথনটি কেবল অনুমান করা হচ্ছে It এটি ভবিষ্যতের পূর্বাভাস দিতে পারে না, তবে এটি চেষ্টা করতে বাধ্য হয় And

এখানে একটি সাদৃশ্য রয়েছে: ধরুন যে কেউ আপনাকে বলে, "আমি 100 টি গণনা করতে চলেছি, এবং আমার কখন করা হবে সে সম্পর্কে আপনাকে অবিরত অনুমানের প্রয়োজন।" তারা শুরু করে, "এক, দুই, তিন ..."। আপনি লক্ষ্য করেছেন যে তারা প্রতি সেকেন্ডে প্রায় এক সংখ্যায় যাচ্ছে, সুতরাং আপনি 100 সেকেন্ডের অনুমান করেন। আহ-ওহ, এখন তারা কমছে। "চার ... ... ... পাঁচ ... ... ..." এখন আপনাকে নিজের অনুমানটি সম্ভবত 200 সেকেন্ডে পরিবর্তন করতে হবে। এখন তারা গতি বাড়িয়েছে: "ছয়-সাত-আট-নয়" আপনাকে আবার নিজের অনুমান আপডেট করতে হবে।

এখন এমন কেউ যে কেবল আপনার অনুমানের কথা শুনছে এবং ব্যক্তি গণনা করছে না তিনি ভাবেন যে আপনি আপনার রকার বন্ধ। আপনার অনুমানটি 100 সেকেন্ড থেকে 200 সেকেন্ড থেকে 50 সেকেন্ডে গিয়েছিল; তোমার সমস্যা কি? কেন আপনি ভাল অনুমান দিতে পারবেন না?

ফাইল অনুলিপি করা একই জিনিস। শেলটি জানে যে কতগুলি ফাইল এবং কয়টি বাইট অনুলিপি করা হচ্ছে, কিন্তু হার্ড ড্রাইভ বা নেটওয়ার্ক বা ইন্টারনেট কতটা দ্রুত চলেছে তা তা জানে না, সুতরাং এটি কেবল অনুমান করতে হবে। যদি অনুলিপি থ্রুপুট পরিবর্তিত হয়, তবে নতুন ট্রান্সফার রেটটি অ্যাকাউন্টে নেওয়ার জন্য অনুমানের পরিবর্তন করা দরকার। "

Comments

তিনি যে উপমা দিচ্ছেন তা একটি কথায় সংক্ষেপে বলা যেতে পারে: পরিসংখ্যান।

— surfasb

Answer 3

আমি দশকে গণনা করতে যাচ্ছি, 1....2....3....410 এ পেতে কতগুলি বিন্দু লাগবে?

5.6.7এখন কি করবে? আপনি কি সংখ্যার মধ্য দিয়ে অতীতের সমস্ত বিন্দু এবং এটির গড় হিসাবে বিবেচনা করেন, আপনি কি কেবল সর্বশেষ 4 টি বিরতি নেন এবং সেই গড়টি ব্যবহার করেন, আপনি কি কেবল শেষ অন্তরকে দেখেন?

আপনার ফাইল ট্রান্সফার নিয়ে একই সমস্যা রয়েছে। ফাইলটি যে গতিতে স্থানান্তরিত হয় তা ধ্রুবক নয়, এটি অনেকগুলি কারণের ভিত্তিতে গতি বাড়ায় এবং ধীর হয়ে যায়। সংখ্যাটি এতটা লাফিয়ে ওঠার কারণ হিসাবে মাইক্রোসফ্ট বর্ণালীটির "কেবলমাত্র শেষ বিরতি গণনা করুন" এর দিকে ঝুঁকছে।

বর্ণালীটির সেই দিকটিতে কোনও ভুল নেই, এটি আপনাকে আরও "সেকেন্ড প্রতি সেকেন্ড" দেয় (রিয়েল টাইমে এক সেকেন্ড কাউন্টারকে এক সেকেন্ডে নামিয়ে তোলে) তবে এটি টাইমারের মোট ইটিএকে অনেক কাছাকাছি চলে যায় ।

বিপরীত দিকের একটি ভাল উদাহরণ হ'ল 7-জিপ যখন এটি সংকোচনের হয়। যদি সংক্রমণের গতি প্রসেস হয় তবে আপনি দেখতে পাচ্ছেন যে ইটিএ কোনও ফাইল স্থানান্তর ইটিএর মতো নাটকীয়ভাবে লাফিয়ে উঠছে না, তবে টাইমারটি এক সেকেন্ডের নীচে টিক দেওয়ার আগে এটি 2 থেকে 3 রিয়েল সেকেন্ডে লাগতে পারে (অথবা এটি এমনকি গণনা শুরুও করতে পারে) ) যতক্ষণ না এটি নতুন গতিতে স্থিতিশীল হয়।

Comments

তারা কেন তাত্পর্যপূর্ণ বা নিয়মিত চলমান গড় না করায় আমাকে

— মারছে

@ মেহরদাদ আমি মনে করি উইন্ডোজের সাম্প্রতিক সংস্করণগুলি আরও বেশি করে দেয়, ইটিএ সময়টি উইন্ডোজ in এবং er-এর নতুন ওপরের মতো অনেক বেশি আচরণ করে।

— স্কট চেম্বারলাইন

Answer 4

সেখানে আসলে একটি ব্যাপার Microsoft এর রেমন্ড Chen দ্বারা প্রায় ক্যানোনিকাল উত্তর WAAAAAY পিছন থেকে এই সম্পর্কে, এবং ধাঁধা হতে কয়েক টুকরা আছে।

কারণ অনুলিপি কথোপকথনটি কেবল অনুমান করা হচ্ছে। এটি ভবিষ্যতের পূর্বাভাস দিতে পারে না, তবে চেষ্টা করতে বাধ্য হয়। এবং অনুলিপিটির একেবারে শুরুতে যখন খুব অল্প ইতিহাস চলে যায়, তখন ভবিষ্যদ্বাণীটি সত্যই খারাপ হতে পারে।

প্রথমত, উইন্ডোজ অনুমান করা হয়। এটি কতগুলি ফাইল, এবং সেগুলি কত বড় তা জানে তবে ফাইল প্রতি স্থানান্তর হার অত্যন্ত পরিবর্তনশীল। এটি আকার বা কিছু ক্ষেত্রে ড্রাইভে এমনকি অবস্থানের মতো বিষয়ের উপর নির্ভর করে। সময়ের সাথে সাথে, এটি বর্তমান এবং অতীতের অবস্থার উপর ভিত্তি করে এর অনুমানকে সামঞ্জস্য করে এবং যেমন আপনার বাস্তব-বিশ্বের পরিস্থিতিতে সঠিক অনুমান স্থানান্তর গতি রয়েছে।

Comments

মজার বিষয়, 2004 সালে প্রথম মন্তব্যটি ভিস্টায় 2006 সালে প্রবর্তিত হয়নি এমন বাক্যগুলি দেখিয়ে বিশদ ফাইল অনুলিপি তথ্য ড্রপডাউন বর্ণনা করে।

— স্কট চেম্বারলাইন

হ্যাঁ, আড্ডায় কেউ এটিকেও নির্দেশ করেছেন। আমি এটি বলতে প্রলোভিত হয়েছি যে ব্যবহারকারীর সমস্যাটি সমাপ্ত হওয়ার সময়ে তার দিকে

— তাকানোর জন্য বর্ণা graph্য

@ জর্নিম্যানজিইক "চ্যাটে কেউ" রিপোর্ট করছে! হ্যাঁ, যদিও এটি একটি দুর্দান্ত অনুমোদনের উত্স, তবে এটি 2004 সালের, এবং ভারীভাবে পুরানো এবং সম্ভবত উইন্ডোজ 8

— বব

উইন্ডোজ 8-এ সম্পর্কিত একটি ব্লগ পোস্ট এখানে দেওয়া হয়েছে : "একটি অনুলিপি সম্পন্ন করার জন্য অবশিষ্ট সময় অনুমান করা কোনও নির্ভুলতার সাথে করা প্রায় অসম্ভব ... বরং স্বল্প আত্মবিশ্বাসের অনুমানের সাথে প্রচুর সময় ব্যয় করা বরং সামান্য উন্নতি হবে than বর্তমানের উপরে, আমরা যে তথ্য সম্পর্কে আত্মবিশ্বাসী ছিল সেগুলি উপস্থাপনের দিকে মনোনিবেশ করেছি ... "

— কেলি টমাস

Answer 5

এখানে ব্যাখ্যা দ্বারা রেমন্ড চেন , মাইক্রোসফট প্রিন্সিপাল সফটওয়্যার ডিজাইন ইঞ্জিনিয়ার:

অনুলিপিটি কেন অনুলিপি দেয়?

কারণ অনুলিপি কথোপকথনটি কেবল অনুমান করা হচ্ছে। এটি ভবিষ্যতের পূর্বাভাস দিতে পারে না, তবে চেষ্টা করতে বাধ্য হয়। এবং অনুলিপিটির একেবারে শুরুতে যখন খুব অল্প ইতিহাস চলে যায়, তখন ভবিষ্যদ্বাণীটি সত্যই খারাপ হতে পারে।

এখানে একটি সাদৃশ্য রয়েছে: ধরুন যে কেউ আপনাকে বলে, "আমি 100 টি গণনা করতে চলেছি, এবং আমার কখন করা হবে সে সম্পর্কে আপনাকে অবিরত অনুমানের প্রয়োজন।" তারা শুরু করে, "এক, দুই, তিন ..."। আপনি লক্ষ্য করেছেন যে তারা প্রতি সেকেন্ডে প্রায় এক সংখ্যায় যাচ্ছে, সুতরাং আপনি 100 সেকেন্ডের অনুমান করেন। আহ-ওহ, এখন তারা কমছে। "চার ... ... ... পাঁচ ... ... ..." এখন আপনাকে নিজের অনুমানটি সম্ভবত 200 সেকেন্ডে পরিবর্তন করতে হবে। এখন তারা গতি বাড়িয়েছে: "ছয়-সাত-আট-নয়" আপনাকে আবার নিজের অনুমান আপডেট করতে হবে।

ব্লগ পোস্ট উপরে উদ্ধৃত এই সমস্যাটি একটি দীর্ঘ আলোচনা, কিছু মজার মন্তব্য করেছেন।

রেমন্ড চেন একজন কিংবদন্তি ব্যক্তি, "মাইক্রোসফ্টের চক নরিস", আমি মনে করি না আপনি আরও প্রামাণিক উত্তর পেতে চলেছেন। আমি নিশ্চিত যে সে কমপক্ষে প্রশ্নবিদ্ধ কোডটি দেখেছিল।

Answer 6

সুস্পষ্ট কারণ হ'ল স্থানান্তরটির গতি সময়ের সাথে সাথে পরিবর্তিত হয়, এবং একইভাবে গড়ও হয়, এবং পূর্বাভাসও দেয়। একটি প্রযুক্তিবিহীন বন্ধুকে এটি ব্যাখ্যা করতে, আমি বিমানের মাধ্যমে যাতায়াত সম্পর্কিত একটি উপমা ব্যবহার করেছি। আপনি আটলান্টিকের ওপরে যাচ্ছেন। যখন আপনি ছাড়ার বিমানবন্দরে ট্যাক্সি নিয়ে আসেন, তখন আপনার ইটিএ প্রায় দুই মাস হয়। এখন পর্যন্ত আপনার গড় গতির উপর ভিত্তি করে আপনি যখন পৌঁছনোর বিমানবন্দরে অবতরণ করবেন, আপনি 5 সেকেন্ডের মধ্যে আপনার বন্ধুর বাড়িতে পৌঁছে যাবেন।

একই গতিতে একই ডিস্কের মধ্যে ফাইলগুলি অনুলিপি করার মতো, বা দুটি স্থানীয় ডিস্কের মধ্যে যেমন অনুমানযোগ্য দৃশ্যের মতো দেখতে পাওয়া যায় তবুও আপনার গতিটি আসলে কতটা আলাদা হতে পারে তা উপলব্ধি করতে হবে। উইন্ডোজ 8-এ আমি যে নতুন বৈশিষ্ট্য পছন্দ করি তার মধ্যে একটি হ'ল আপনি যদি "আরও বিশদ বিবরণ" ক্লিক করেন তবে সময়ের সাথে সাথে গতি চিত্রিত করার ক্ষমতা। আপনার যদি উইন্ডোজ 8 মেশিনে অ্যাক্সেস না থাকে তবে অনেকগুলি উদাহরণের জন্য উইন্ডোজ 8 কপি ডায়ালগের জন্য চিত্রগুলি অনুসন্ধান করুন । এগুলির মধ্যে অনেকগুলি মোটামুটি সমতল, তবে তাদের মধ্যে অনেকে দুর্ঘটনাক্রমে কৃপণও রয়েছে, আপনি যখন ভাবেন যে হার্ড ড্রাইভটি আসলে স্বাস্থ্যকর কিনা, যখন তা শূন্যের কোঠায় নেমে যায়।

এর মধ্যে কয়েকটি ধাক্কা ফাইলের আকারের পরিবর্তনের কারণে হতে পারে — ছোট ক্ষেত্রগুলি আরও অ্যাক্সেস দেয়, যা জিনিসগুলি ধীর করে দেয়, বিশেষত একটি যান্ত্রিক হার্ড ড্রাইভে যা পড়ার মাথাটি সরিয়ে নেওয়া উচিত — তবে কিছু এটি কেবল একটি সস্তা ড্রাইভ হতে পারে যা প্লাটারগুলিকে ক্ষতি রোধ করতে সামান্য স্পর্শে স্টলগুলি।

আরও ভাল এবং খারাপ ইটিএ পূর্বাভাস অ্যালগরিদম রয়েছে, তবে একটি সঠিক ভবিষ্যদ্বাণী করার জন্য কম্পিউটারটি সর্বজ্ঞ হতে হবে। অ্যালগোরিদমকে "স্মার্ট" করার চেষ্টা করার ঝুঁকিটি এটি নতুন, অপ্রত্যাশিত, এমন ক্ষেত্রে তৈরি করতে পারে যেখানে এটি আরও বেশি হাস্যকরভাবে ভুল ously

Answer 7

ফাইলগুলির সেট সংকুচিত করতে কত সময় লাগবে তা জানার একমাত্র উপায় হ'ল তাদের সংকুচিত করা। কখনও কখনও উইন্ডোজ 'সেরা অনুমান কাছাকাছি, কখনও কখনও এটি অত্যন্ত ভুল। আমি নিশ্চিত যে আপনি লক্ষ্য করেছেন নিশ্চিতভাবেই প্রচুর পরিমাণে ফাইল অনুলিপি করার ক্ষেত্রেও এটি একই।

কদাচিৎ-সঠিক তথ্যের অকেজো প্রদর্শন হিসাবে এটি কোনও ত্রুটি নয়। এটি ঠিক করার সর্বোত্তম উপায় হ'ল আপনার চোখ বন্ধ করা। বাদ দাও. ;-)

সম্ভবত সেখানে একটি প্রোগ্রাম রয়েছে যা ফাইলগুলি অনুলিপি / সংকুচিত করতে এবং এটি শেষ হয়ে গেলে একটি অ্যালার্ম শব্দ তৈরি করতে পারে। এটা সত্যিই দরকারী হবে। উইন্ডোজ ঘরের কাজ শেষ করার জন্য অপেক্ষা করার সময় আমরা কিছুটা ঝুলতে পারি।

Answer 8

আমি মনে করি রোল্ডের উত্তরের সাথে সংযুক্ত ব্লগ পোস্টের একটি মন্তব্যে কারণটি সুন্দরভাবে ব্যাখ্যা করা হয়েছিল :

এটিতে একটি ভয়াবহ অনুমানের অ্যালগরিদম রয়েছে। কোন অজুহাত নেই। যদি 1000 1KB ফাইল এবং 10 1MB ফাইলগুলি অনুলিপি করতে হয় তবে এটি মনে করে যে এটি 1 এমবি ফাইলের সাথে 1 এমবি ফাইলের সাথে ব্যস্ত হবে।

এটি এমন ভয়াবহ অনুমান দেওয়ার কারণটি এটি ভালভাবে সম্পন্ন হয়নি। স্পষ্টতই এটি কখনই 100% নির্ভুল হতে পারে না তবে এটি অনেক বেশি, আরও ভাল হতে পারে।

Comments

উইন্ডোতে কোনও ফাইল কত বড় তা জানার জন্য এটি খোলার প্রয়োজন হয় এবং উইন্ডোজে কোনও ফাইল খোলার অর্থ এটি পড়া। এবং অনুলিপিটি কত সময় নেবে সে সম্পর্কে একটি ভাল অনুমানের জন্য তারা কতগুলি বড় ফাইল তা দেখার পরিবর্তে উইন্ডোজ সিদ্ধান্ত নেয় যে সময়টি আসলে ফাইলগুলি অনুলিপি করতে হবে - সর্বোপরি, আপনি এটি করতে বলেছিলেন।

— সিকিউরিটিম্যাট

@ সিকিউরিটিম্যাট: এটি যদি হয় তবে ডিরেক্টরি তালিকা পেতে যুগে যুগে সময় লাগত। আমি নিশ্চিত ফাইলের আকারগুলি ডিরেক্টরিতে সঞ্চিত থাকে এবং যখনই ফাইল পরিবর্তন করা হয় তখন আপডেট হয়। সুতরাং, ডিরেক্টরিতে তালিকাভুক্ত ফাইলের আকার এবং স্থানান্তর গতি সম্পর্কে কিছু অনুমানের উপর ভিত্তি করে অনুলিপি সময়ের একটি দ্রুত এবং মোটামুটি সঠিক অনুমানের উপায় থাকতে হবে। একটি সত্যই স্মার্ট ওএস সময়ের সাথে গড় ট্রান্সফার গতির দিকে মনোযোগ দেবে এবং এটি তার প্রাক্কলন অনুসারে ব্যবহার করবে।

— রবিএইচ

Answer 9

অনুলিপি প্রক্রিয়াটি ত্বরান্বিত করার জন্য (অনুলিপি-সম্পর্কিত ক্রিয়াকলাপগুলি সম্পাদনের পরিবর্তে সময় অনুমানের সময় গণনা করতে খুব বেশি সময় ব্যয় করবেন না), এক্সপ্লোরারে নির্মিত উইন্ডোজ অনুলিপি ইউটিলিটি কীভাবে পূর্ববর্তী রাইট অপারেশন সম্পন্ন হয়েছিল সে সম্পর্কে সীমিত পরিমাণে তথ্য বজায় রাখে। প্রতিটি সময় যখন অবশিষ্ট সময় গণনা করা দরকার তখন এটি লেখার জন্য কতটা সময় নিয়েছে তার গড় পরিমাণ নির্ধারণ করে এবং তারপরে বাকী লেখার ক্রিয়াকলাপের সংখ্যা দ্বারা বহুগুণ।

সমস্যাটি হ'ল লিখন অপারেশন করতে যে পরিমাণ সময় লাগে তা ধ্রুব নয় - এটি আসলে উল্লেখযোগ্যভাবে পরিবর্তিত হতে পারে। সুতরাং এটি পরিবর্তে সময়ের অনুমানে উল্লেখযোগ্য পরিবর্তন আনবে।

Comments

আমি মনে করি না যে আপনি এটির পক্ষে একদম ঠিক আছেন - আপনি কেবল 2 সংখ্যা ব্যবহার করে লেখার ব্যবহারযোগ্য গড় বজায় রাখতে পারেন - বর্তমান গড় [ A] এবং সেই গড় পেতে ব্যবহৃত ডেটার পয়েন্টগুলির সংখ্যা [ n]। তারপরে এটি আপডেট করার জন্য এটি কেবল একটি ঘটনা (A*n + [New value])/[n+1]। এছাড়াও, যেহেতু অনুলিপি ক্রিয়াকলাপগুলি প্রায়শই আইও-আবদ্ধ না হয় সিপিইউ-আবদ্ধ, তাই প্রতি কয়েক সেকেন্ডের মতো একটি সাধারণ গণনা কিছুই হয় না। অন্যদিকে, সর্বশেষের nলেখার গড় রাখার জন্য একটি অ্যারের / ক্যু / nউপাদানগুলির স্ট্যাকের প্রয়োজন হয় - সুতরাং আপনি জানেন যে কোন মানটি উচ্ছেদ হওয়ার কারণে।

— মৌলিক

ভাল যুক্তি! তাহলে হেক কেন এত জায়গা জুড়ে? : পি

— ব্রায়ান গ্রেডিন

আমি ধরে নিলাম তারা কেবলমাত্র কয়েকটি শেষ লেখাকে বিবেচনায় নিয়ে আরও প্রতিক্রিয়াশীল গড় করে চালাক হওয়ার চেষ্টা করেছিল - এবং খুব কম বেছে নিয়েছিল। বলেছিল, আমার কাছে সোর্স নেই তাই কে জানে?

— বেসিক

Answer 10

আমলে নেওয়ার জন্য 3 টি কারণ রয়েছে:

1. স্থানান্তর মোট আকার।
2. স্থানান্তরিত করার জন্য ফাইলের সংখ্যা।
3. মিডিয়া "ব্যস্ত-নেস", এবং সম্ভবত সংযোগ।

নম্বর 1 এবং 3 হ'ল স্থানান্তর সময় গণনার সবচেয়ে সুস্পষ্ট প্রভাব রয়েছে বলে মনে হয়, তবে অনেক বড় লোক 2 নম্বরের জন্য অ্যাকাউন্ট করে না , স্থানান্তরটি কতটা সময় নেবে তার উপর এটি বিশাল প্রভাব ফেলতে পারে এবং এটি পরিমাণ নির্ধারণ করা শক্ত।

মূলত, প্রতিটি সময় ফাইল ফাইল লিখলে ফাইল সম্পর্কে কিছুটা মেটাডেটা লিখতে হবে, যেমন। মালিকানা, অনুমতি, তৈরি / পরিবর্তন / অ্যাক্সেসের সময় ইত্যাদি files নির্দিষ্ট ফাইল সিস্টেমের উপর নির্ভর করে এই তথ্যটি ডিস্কের একটি অংশে লেখা যেতে পারে যেখানে তারা ফাইল করছেন সেখান থেকে খুব দূরে। এই ফাইল সিস্টেমের ওভারহেড এমনটি যা আপাতদৃষ্টিতে সহজ স্থানান্তরকে দীর্ঘ সময় নিতে পারে, এবং / অথবা সময়ের অনুমানকে বন্যভাবে ওঠানামা করতে পারে।

উদাহরণস্বরূপ: একটি বৃহত ফাইল স্থানান্তরিত আপনি লক্ষ্য করবেন যে অনুমানটি স্থির এবং মোটামুটি নির্ভুল, তবে বিভিন্ন আকারের শত শত ফাইল হস্তান্তর করা, তবে একই মোট আকার, আরও বেশি সময় নিতে পারে এবং সময়ের অনুমানকে ফিট করে।

Answer 11

বর্তমান অনুমানের অ্যালগরিদমে তিনটি ঘাটতি রয়েছে।

জনপ্রিয় বিশ্বাসের বিপরীতে তারা আমাদের হাত উপরে ফেলে দেওয়া প্রায় কঠিন নয়।

বেশিরভাগ লোকেরা ব্লগ লেখার কারণ এবং এখানকার লোকেরা যে সম্ভাবনা সম্পর্কে অবগত নয় সে কারণেই পড়াশোনার ক্ষেত্র এবং বিদ্যালয়ের প্রশস্ততার কারণে আমি বলতে পারি যতটা ভাল। [ব্লগ লেখকদের তুলনায় সাম্প্রতিক প্রশিক্ষণ প্রাপ্ত স্নাতক] [একটি বহু মিলিয়ন ডলার সংস্থা] মাইক্রোসফ্টের পক্ষে একটি বিনয়ী তবে খুব আরামদায়ক প্রতিকারও হওয়া উচিত should

আমি কেন মোটামুটিভাবে ব্যাখ্যা করার চেষ্টা করব।

---

ব্যর্থতার পয়েন্টগুলি নিম্নরূপ: কার্নেল:

১. কার্নেলের আওতার বাইরে অবস্থানের কারণে ভবিষ্যতের আইও লোডকে নির্ভরযোগ্যভাবে পূর্বাভাস দিতে পারে না

• এটি খুব সীমাহীন পি = এনপি সমস্যা হিসাবে এটি সম্পর্কে কিছুই করা উচিত নয়।

২. কোনও কার্যকর স্তরের বিশদে আইও হিউরিস্টিক্স ট্র্যাক করে না । ইউটিলাইজেশন ডিস্ক চেয়ে অনেক বৃহত্তর ধারণা / নেটওয়ার্ক পড়া / লেখা গতি ।

• খুব প্রাথমিক আইও ব্যবহারের তথ্য ট্র্যাক করার চেয়ে এ সম্পর্কে খুব কম কাজ করা দরকার

  • ডিস্ক থেকে
    • গড় পড়ার গতির মাত্রা 1 এ
    • ফাইলের মাত্রা 2a গড় লেখার গতি
  • অনুযায়ী প্রতি কোয়ান্টা * ভিত্তিতে
    • ফাইলের আকারের মাত্রা খ
    • ডিস্কের মাত্রায় ফাইলটির অবস্থান সি
  • * [সম্ভবত] 3 টির বেশি বিভাগে কোয়ান্টাইজড। মাত্রা হ্রাস আমাদের নির্দিষ্টকরণের জন্য নির্ধারণ করতে সহায়তা করবে তবে 3-এর পূর্বে ভবিষ্যদ্বাণী ব্যবস্থার চেয়ে বেশি-কিছু (সম্ভবত বরং কার্যকর) ভাল হওয়া উচিত:
    • ফাইলের আকার
      • আলো
      • মধ্যম
      • ভারী
    • অবস্থান [সন্ধানের বিলম্বের খবর]
      • শুরুতে
      • মধ্যম
      • আপনি পয়েন্ট পেতে
    • ফাইলের আকার এবং অবস্থানগুলি রিডান্ট্যান্ট / রিড / রাইট গতির সাথে ওভারল্যাপ হয়, এটি উদ্দেশ্যমূলক
  • আমাদের ডিস্কটি কীভাবে "ব্যস্ত" হয়েছে তা জানতে হবে যাতে আমরা ধরে নিতে পারি যে এটি ব্যস্ত মাত্রা হবে d
    • ফাইলগুলি পড়ার পরিমাণ থেকে তাদের গণ্য করা, তাদের নিজ নিজ ওজনের সাথে মিলিত
    • অনুলিপি করার সময় সময় অনুমান করার জন্য ব্যবহৃত হত ... ভবিষ্যতের প্রত্যাশিত লোডের ভিত্তিতে ডায়ালগটি যদি এই অনুলিপি কথোপকথনটি বাদ দিয়ে অন্য সব কিছু এখন অবধি চলতে থাকে
  • এর উদ্দেশ্যে রেকর্ডিংয়ের পদ্ধতি ... এখানে পেটেন্টেবল

৩. যদি তাদের অনুসরণ করা হয় , তবে এটি হিউরিস্টিকদের জন্য ব্যবহার না করে

• এখানে খুব কম কাজ করা হয়েছে, যেখানে আমরা বেশিরভাগ কাজ করি
• এটি ব্যবহার করতে আমরা # 2 থেকে ডেটা রেখেছি
  • ফাইলের ওজন এবং অবস্থানগুলির মোটামুটি পরিসংখ্যান বিশ্লেষণ যা আমরা কতটা হ্যাপিং করতে যাচ্ছি তা নির্ধারণ করে। ওজন + অবস্থান আমাদের পূর্বাভাস দেয়
  • বর্তমান ডিস্ক লোড ওজন এবং অবস্থানের সাথে একত্রিত করুন
  • অনুমান করার জন্য কি আমরা মনে ফাইলের সংখ্যা গড় পঠন / লিখন গতি মাত্রা চ হতে হবে
  • যা আমরা আমাদের মডেলকে সূক্ষ্ম সুরের সাথে তুলনা করি
  • যা আমাদের অগ্রগতি বার এবং সমাপ্তির সময়টি সম্পর্কে নির্ভুলভাবে অনুমান করতে দেয়
• পূর্বাভাসের উদ্দেশ্যে বিশ্লেষণ পদ্ধতি ... এখানে patentable হয়

---

এই সমস্তগুলির মূল বিষয়টি হল আমাদের মডেলটি কেবল 2 এ = এফ * (বিএক্সসি) + ডি কমপ্লেক্স

যেখানে a, b, এবং c এর প্রত্যেকটিতে 3 টি স্টেট রয়েছে: ফাইল ম্যানেজার অনুলিপি করার আগে ফাইলগুলিতে (বা কেবল মেটাডেটা) উঁকি দেয় এবং F * (bxc) + d ব্যয়বহুল গণনা নয়; আপনি আরও সঠিক কিছু চাইলে আরও রাজ্যের সাথে একটি সন্ধানের টেবিলটি ব্যবহার করুন - এর পক্ষে খুব কমই কোনও গণনা নেই।

দ্রষ্টব্য: এখানে মাত্রা একটি প্ল্যাটারের জন্য, একটি এসএসডি -র সাথে আলাদা হবে - শুরু / মাঝারি / শেষ কোনও বিষয় নয়

আমি যে বর্ণনা করেছি এবং পূর্ববর্তী বাস্তবায়ন যা এখন পর্যন্ত আমরা দেখেছি তার মধ্যে মূল পার্থক্য হ'ল সংক্ষেপে, ফাইল সাইজ এবং ডিস্কে বিভক্তি / এনট্রপি ফাইল ফাইল করা এবং [আরও] সঠিকভাবে ডিস্ক ব্যবহারের সময় উপাদানটির জন্য অ্যাকাউন্টে নিবন্ধ ব্যবহার করা।

(পেটেন্টটি পাঠকের অনুশীলন হিসাবে ছেড়ে গেছে ...)

Comments

@ তুইস্টি আমি হয়ে গেলাম, এখন কেমন?

— প্যানক্রিস

অনেক ভাল. ভাগ্যবান সাইটটি ব্যবহার করে এবং সম্প্রদায়টিতে যোগদানের জন্য ধন্যবাদ।

— আমি বলছি মনিকা পুনরায়

Answer 12

আপনি যখন ভবিষ্যদ্বাণী করতে চেষ্টা করছেন যে কতক্ষণ সময় লাগবে তা অনেকগুলি "অজানা" ভেরিয়েবল রয়েছে। উদাহরণস্বরূপ, যখন প্রোগ্রামটি জানে যে 3500 ফাইল রয়েছে এবং ফাইলগুলি 3.5 গিগাবাইট (3500 এমবি) হয়, তার অর্থ কি প্রতিটি ফাইল 1 এমবি হয়? অগত্যা। এখানে প্রচুর 4 কেবি ফাইল, এবং 100 এমবি ফাইলের অনেকগুলি এবং এর মধ্যে কিছু অন্যান্য থাকতে পারে। এছাড়াও, আপনাকে বিবেচনা করতে হবে যে ফাইলগুলি কোথা থেকে আসছে এবং কোথায় যাচ্ছে (যেমন মিডিয়া)) বৃহত্তম বাধাটি কী? আপনি কীভাবে কোনও ভিপিএন টানেলের মাধ্যমে এইচডিডি থেকে ফাইলগুলি অনুলিপি করার চেষ্টা করছেন ? আপনি একটি সেরা কেস দৃশ্যাবলী দেন এবং তারপরে রিয়েল টাইমে আপনার কাউন্টারগুলি সামঞ্জস্য করুন। এই কারণেই আপনি সেই অগ্রগতি মিটারগুলি ফ্লাইতে পরিবর্তন দেখতে পান।

Answer 13

গাণিতিকভাবে সঠিক মডেলটি হ'ল গড়পড়তা গড় এবং এক্সট্রোপোলেশন:

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

কারণটি হ'ল বড় সংখ্যাগুলির আইন অনুসারে স্থানীয় ওঠানামা গড় স্থানান্তর গতিতে বাতিল হয়ে যাবে এবং এটি আপনাকে সবচেয়ে স্থিতিশীল ফলাফল দেবে give

কি মাইক্রোসফট বলে মনে হয় না নিরূপণ করা হয় স্থানান্তর গতি সর্বশেষ সময় ফ্রেম এ। এর অর্থ প্রতিটি স্থানীয় ওঠানামা ফলাফলকে উল্লেখযোগ্যভাবে পরিবর্তন করে changes

Comments

আপনার মডেলটি সমান্তরালভাবে অন্যান্য ফাইল স্থানান্তর শুরু করার মতো দীর্ঘস্থায়ী ব্যাঘাতগুলি সঠিকভাবে পরিচালনা করবে না এবং একই পরিমাণ ডেটা মাত্র 20 মিনিট সময় নিয়েছে যদিও আমাকে আরও বলতে হবে 5 মিনিট সময় লাগবে tell একটি ওজনযুক্ত চলমান গড় আরও সঠিক হতে পারে।

— ড্যানিয়েল বেক

@ ড্যানিয়েলবেক: একদম সঠিক নয়। প্রত্যাশিত সময় ধীরে ধীরে বৃদ্ধি পাবে। প্রশ্নটি কত দ্রুত বাড়বে? ঠিক আছে, এটি বিগত সময়ের উপর নির্ভর করে। যদি এটি দীর্ঘ অপারেশন হয়, যেমন এটি ইতিমধ্যে 5 ঘন্টা অনুলিপি করে চলেছে, তবে এটি প্রত্যাশাটি বেশি বাড়ায় না। তবে কি 15 মিনিটের অসম্পূর্ণতা 5 ঘন্টা অপারেশনের জন্য গুরুত্বপূর্ণ? না। মুল বক্তব্যটি হ'ল এটি আপনাকে আপেক্ষিক ত্রুটির ক্ষেত্রে সেরা সান্নিধ্য দেয়। এছাড়াও আপনি কিছু যে অনেক ভালো কাজ করবে ব্যবহার করতে পারবেন না যে দৃশ্যকল্প।

— ybungalobill

আপনার মডেলটির সমস্যাটি হ'ল এটি হস্তান্তরিতকরণের মধ্য দিয়ে রেট পরিবর্তনগুলি স্থানান্তর করতে একেবারে প্রতিক্রিয়া জানায় না। এটি দ্রুত প্রতিক্রিয়াশীল উইন্ডোজ ফাইল স্থানান্তর হিসাবে যেমন অপ্রয়োজনীয় উদাহরণ হবে : প্রথমে 10 এমবি / এস এ 60 জিবি স্থানান্তর। শুরুর সময় বাকি: 100 মিনিট। 54GB স্থানান্তর করুন এবং 2MB / s এ ড্রপ করুন। 90 মিনিটের পরে: 54 জিবি: 10 মিনিটে আনুমানিক সময় বাকি। 54 জিবি: 50 মিনিটে আসল সময় বাকি left 115 মিনিটের পরে : 57 জিবি: 6 মিনিটে আনুমানিক সময় বাকি। 57 জিবি: 25 মিনিটে আসল সময় বাকি left 131.67 মিনিটের পরে : আনুমানিক সময়টি 59 জিবি: ২.২৩ মিনিটে ছেড়ে যায়। আসল সময়টি 59 জিবি: 8.33 মিনিটে বাকি ছিল।

— ড্যানিয়েল বেক

@ ড্যানিয়েলবেক: পুরো স্থানান্তরটি 150 মিনিট স্থায়ী হয়, সুতরাং স্থানান্তর শুরুর দিকে সর্বাধিক আপেক্ষিক ত্রুটি 50% যেখানে আপনি আরও ভাল করতে পারবেন না। 54 তম গিগাবাইটে এটি মোট 14% ডলার। (যদি এটি আপনার 150 মিনিট সময় নেয় তবে 20 মিনিটের ব্যাপার কেন?) আসলে খুব ভাল অনুমান ... এটি বলেছিল, আমি আপনার বক্তব্যটি বুঝতে পারি। এই উন্নত করতে উপায় হয় না গড় চলন্ত কারণ আপনার উইন্ডোর কি আকার এটি হওয়া উচিত জানতে পারে না পরিমেয় (এই অপারেশন, একটি ফাইল কপি মত মিনিট সময় নিতে বলে আশা করা নেই

— ybungalobill

বা কয়েক ঘন্টা পি 2 পি ফাইল শেয়ারিং প্রোটোকল যেখানে আপনি 10 এমবি / সেকেন্ডের 10 মিনিট এবং 0 এমবি / সেকেন্ডের 10 মিনিট পান)। এটির উন্নতির উপায় হ'ল আকার দ্বারা নয় সময় দ্বারা গড় ওজন নেওয়া।

— ybungalobill

Answer 14

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

যেমন রোল্ড ভ্যান ডুর বলেছেন, এটি মূলত কেবল অনুমান করা। অবশ্যই, এর অর্থ এই নয় যে এটি আরও ভাল উপার্জনকারী হতে পারে না। এটি গণনা করার জন্য প্রচুর পরিমাণে হিউরিস্টিকস ব্যবহার করা যেতে পারে।

1. সবচেয়ে ভাল উপায়, সবচেয়ে ব্যয়বহুল উপায়, হ'ল পূর্ববর্তী 'অনুলিপি'র ইতিহাস রাখা এবং তারপরে অনুমানের গণনা করার জন্য কৃত্রিম বুদ্ধিমত্তা অ্যালগরিদম ব্যবহার করা
2. এটি কতক্ষণ লাগবে সে সম্পর্কে গবেষণার ভিত্তিতে একটি সূত্র তৈরি করতে পারে। এগুলি অ্যাকাউন্টের জিনিসগুলি গ্রহণ করতে পারে যেমন: ফাইল সিস্টেম, ফাইলের সংখ্যা, ফাইলের আকার, ডিস্কের জন্য সময় চাইনা, ডিস্ক বাল্ক পড়ার / লেখার গতি, ডিস্কে ফাইলগুলির অবস্থান (খণ্ডিতকরণ), বর্তমান ডিস্কের ব্যবহার।
3. দুজনের মিশ্রণ। অর্থাৎ। কিছু নির্দিষ্ট ক্রিয়াকলাপ কত সময় নেয় তা খুঁজে বের করার জন্য কিছু বেঞ্চমার্ক করুন এবং তারপরে সেগুলিকে সাধারণ সূত্রগুলির জন্য ইতিহাস হিসাবে ব্যবহার করুন।

স্পষ্টতই এর কোনওটিই সহজেই প্রয়োগ করা হয় না .. এবং আমি কেবল ফাইল অনুলিপি উল্লেখ করেছি। সব ধরণের স্থানান্তরের জন্য অনুরূপ কাজ করা দরকার।
আপনার নিজের কাছে যে প্রশ্নটি জিজ্ঞাসা করতে হবে- আপনি কি মাইক্রোসফ্টের চেয়ে বরং আরও ভাল অনুমান দেওয়ার জন্য সময় ব্যয় করবেন বা তারা বরং আপনার ফাইলগুলিকে দ্রুত স্থানান্তর করতে চান?

তবে, আপনি যদি 7-জিপ দিয়ে কিছু সংকুচিত করেন তবে আপনি লক্ষ্য করবেন যে এটি উইন্ডোজগুলির চেয়ে অনুমান করার চেয়ে অনেক ভাল। আমি সন্দেহ করি যে এটি এমন জটিল কিছু করছে যা কিছুটা ভাল উত্তম।

Answer 15

সংক্ষেপে, গণনাটি বর্তমান স্থানান্তর গতির উপর ভিত্তি করে ।

উদাহরণস্বরূপ: যদি আপনার ট্রান্সফার রেট ডুবে যায় কারণ উইন্ডোজগুলিকে বিশাল পরিমাণে ক্ষুদ্র ফাইলগুলি অনুলিপি করতে হয়, প্রত্যাশিত সময়টি বৃহত্তর ফাইলগুলির জন্য রৈখিকভাবে এবং তদ্বিপরীত হয় ।

পুরো স্থানান্তর প্রক্রিয়ার উপরে স্থানান্তর গতিটি কী হবে তা পূর্বাভাস দেওয়া প্রায় অসম্ভব , কারণ এটি ফাইলাইজ, সিপিইউ ব্যবহার, সংক্রমণ এরো ইত্যাদি ইত্যাদির মতো অনেক কারণের উপর নির্ভর করে

Answer 16

এমএসডিএন ব্লগ পোস্টে কিছু আকর্ষণীয় উত্তর রয়েছে আমাদের ফাইল ম্যানেজমেন্টের বেসিকগুলি উন্নত করা: এটি সম্পর্কে অনুলিপি করুন, সরান, নাম পরিবর্তন করুন এবং মুছুন । কেন এটি কঠিন:

কোনও অনুলিপি সম্পন্ন করার জন্য অবশিষ্ট সময় অনুমান করা কোনও নির্ভুলতার সাথে প্রায় অসম্ভব কারণ এর সাথে অনেক অনাকাঙ্ক্ষিত এবং অনিয়ন্ত্রিত ভেরিয়েবল জড়িত রয়েছে - উদাহরণস্বরূপ, অনুলিপি কাজের দৈর্ঘ্যের জন্য নেটওয়ার্ক ব্যান্ডউইথ কতটা উপলব্ধ থাকবে? আপনার অ্যান্টি-ভাইরাস সফ্টওয়্যার স্পিন আপ এবং ফাইল স্ক্যান শুরু করবে? অন্য অ্যাপ্লিকেশনটির হার্ড ড্রাইভ অ্যাক্সেস প্রয়োজন? ব্যবহারকারী কি আর একটি অনুলিপি কাজ শুরু করবেন?

এবং কীভাবে তারা উন্নতি করছে,

স্বল্প আত্মবিশ্বাসের প্রাক্কলনের সাথে প্রচুর সময় বিনিয়োগ করার পরিবর্তে বর্তমানের তুলনায় কেবল সামান্য উন্নতি হবে, আমরা কার্যকর এবং বাধ্যযোগ্য উপায়ে আত্মবিশ্বাসী তথ্য উপস্থাপনের দিকে মনোনিবেশ করেছি। এটি আপনার কাছে আমাদের কাছে উপলব্ধ সবচেয়ে নির্ভরযোগ্য তথ্য তৈরি করে যাতে আপনি আরও অবগত সিদ্ধান্ত নিতে পারেন।

এটি বলেছে, আপনি যদি কেবলমাত্র প্রদত্ত অনুমানের উন্নতি করতে চান এবং অগ্রগতিটি যেমন হয় তেমন রাখতে চান, আপনি স্ল্যাশডট মন্তব্যে প্রস্তাবিত কিছু করতে পারেন :

ফাইল সিস্টেমে প্রতিটি স্টোরেজ ডিভাইসের জন্য প্রত্যাশিত গতির একটি টেবিল বজায় রাখুন। ফাইল সিস্টেমের তথ্য পড়তে কত সময় লাগে তা রেকর্ড করুন। যখন কোনও ডিভাইস মাউন্ট করা হয়, যদি এটি ডিভাইসের প্রকারের জন্য যুক্তিসঙ্গত হয় তবে মাঝারি এবং শেষের দিকে যান এবং সেখানে গতিও মাপুন। অবস্থানগুলি জুড়ে পড়ার এবং লেখার গতির জন্য আনুমানিক বক্ররেখা পান এবং ভবিষ্যতের অনুমানের জন্য সেগুলি ব্যবহার করুন। ভবিষ্যতে পড়তে এবং লেখার ক্রিয়াকলাপগুলির জন্য, তারা কোথায় রয়েছে এবং কত দ্রুত যায় সেগুলি নোট করুন এবং সেগুলি অনুসারে বক্ররেখা সামঞ্জস্য করুন।

যখন কোনও অপারেশন শুরু হয়, তখন সংশ্লিষ্ট ডিভাইসের জন্য ইনপুট এবং আউটপুটের জন্য বক্ররেখার দিকে তাকান। লক্ষ্য অবস্থানের জন্য প্রত্যাশিত গতি খুঁজুন। যা গতি কম তা অনুমানের জন্য ব্যবহার করা উচিত।

Answer 17

কেবলমাত্র এটি যুক্ত করতে চেয়েছিলেন যে পিসিতে ফাইল অনুলিপি করার জন্য ফাইলগুলির মোট সংখ্যা সহজেই সবচেয়ে বেশি সময় গ্রহণকারী ফ্যাক্টর। আমি সর্বদা একজন তরুণ ছাত্র হিসাবে মনে রাখতে পারি, ইচ্ছাকৃতভাবে কোনও কম্পিউটারে কোনও বিষয়বস্তুবিহীন 1 ফাইল দিয়ে শুরু করে, এবং এটি অনুলিপি করে, তারপরে 2 টি ফাইল নির্বাচন করে এবং আবার অনুলিপি করে আমার কম্পিউটারের ক্লাসে পিসির ব্যর্থতা প্ররোচিত করে। এটি প্রায় 1024 টি ফাইল অতিক্রান্ত হয়ে গেলে ফাইলের শিরোনামের জন্য কোনও তথ্য সংরক্ষণ না করে এমনকি কোনও কিছু করার জন্য এটি প্রচুর পরিমাণে সময় নিতে শুরু করে। এমনকি এটি একটি নতুন ওএস, সূচকীয় ফাইল অনুলিপিতে নিজেই চেষ্টা করে দেখুন এবং কী হবে তা আপনি দেখতে পাবেন। চিন্তার জন্য খাদ্য.

Comments

আকর্ষণীয় হলেও, এটি প্রশ্নের উত্তর দেয় না। উত্তর দেওয়ার আগে কীভাবে উত্তর দিতে হয় তা পড়ুন ।

— ব্যবহারকারী 99572

Answer 18

আমি সবেমাত্র আমার মূল ড্রাইভে ইউএসবি এইচডিডি থেকে 200 জিপি অনুলিপি করেছি। প্রায় 130000 ফাইল ছিল

প্রথম 4-5 মিনিটের পরে আমি এটি পর্যবেক্ষণ করেছি:

• ক্ষুদ্রতম ফাইলগুলির জন্য, প্রতি সেকেন্ডে প্রায় 600 ফাইলের পরিমাণ ছিল প্রায় 600 কেবি / সেকেন্ডে 100
• এবং বড় ফাইলগুলির জন্য এটি 70MB / s এর মতো ছিল

শুরুতে উইন্ডোজ অনুমানটি 1 ঘন্টা থেকে 5+ ঘন্টা এবং তারপরে 1 ঘন্টা এবং আরও কিছুতে পরিবর্তন করে। 95% এর মতো শেষে এটি এখনও 10 মিনিট থেকে 10+ ঘন্টা ধরে অনুমানটি পরিবর্তন করে চলেছিল। সুতরাং এটি আরও সঠিক হওয়ার পরিবর্তে এটি কম এবং সুনির্দিষ্টভাবে চলছিল।

সাধারণ গণিত শো:

১৩০,০০০ ফাইল প্রতি সেকেন্ডে = 22 মিনিটে 100 টি ফাইল

প্রতি সেকেন্ড = 47 মিনিটে 70 এমবিতে 200,000 এমবি

22 মিনিট - আকারের কয়েক কিলোবাইটের ফাইল অনুলিপি করার সময় সন্ধানে ছেড়ে দেওয়া হয়েছে। 47 মিনিট - সময় অনুসন্ধানের সময় না থাকলে আসল ডেটা স্থানান্তর করতে হবে।

22 মিনিট + 47 মিনিটের যোগফল সম্ভবত এটি গ্রহণ করতে পারে এমন পরম সর্বোচ্চ সময়।

সুতরাং স্পষ্টতই অনুমানটি কোথাও 47 এবং 69 মিনিটের মধ্যে হওয়া উচিত ।

কথোপকথনটি প্রায় 90% এ কী দেখায়: "আমি 1MB / s তে কিছু ছোট ফাইল অনুলিপি করছি, আরও 20 জিবি ডেটা রয়েছে, এটি সম্পূর্ণ হতে 5:30 ঘন্টা সময় লাগবে।

কয়েক সেকেন্ড পরে: "আমি এখানে একটি বড় ফাইলটি অনুলিপি করছি, 70 এমবি / সেকেন্ডে এটি শেষ হতে 4 মিনিট সময় লাগবে।

মানুষ একই ডায়ালগ থেকে আসলে যা দেখছে: 120,000 ফাইল এবং 180 গিগাবাইট ইতিমধ্যে 40 মিনিটের জন্য অনুলিপি করা হয়েছে। বাকি 10000 ফাইল এবং 20 গিগাবাইটের প্রায় 5 মিনিট সময় নেওয়া উচিত

ডায়ালগটি গণনা করার জন্য পর্যাপ্ত তথ্য দেয় যা প্রতি সেকেন্ডে আরও এবং আরও নির্ভুল হয়। ছোট ফাইলগুলি অনুলিপি করা হয়েছে এমন হার এটি জানে। এটি কী গতিতে বড় ফাইলগুলি অনুলিপি করা যায় তা জানে। এটি কতগুলি ফাইল এবং কতগুলি বাইট বাকি রয়েছে তাও জানে।

কেবলমাত্র উপরের এবং নিম্ন সীমাটি নির্ধারণ করে এত নির্ভুল ধারণা করা এত সহজ।

বড় ফাইলগুলি যখন ছোট ফাইলগুলির আগে হয় তখন ডায়ালগটি আরও কিছুটা সঠিক ডেটা দেখায়। যদি এটি হয় তবে এটি 40 মিনিটে শুরু হয় এবং 30 মিনিটের পরে এটি ছোট ফাইলগুলি অনুলিপি করা শুরু করে এবং বলে "ভাল আমার আরও 20 মিনিট প্রয়োজন"।

শুরুতে যখন ছোট ফাইলগুলি হয় এবং বড় ফাইলগুলি শেষ হয়। ডায়ালগটি আসলে "প্রতি সেকেন্ডে ফাইলগুলি" কীভাবে ছোট ফাইলগুলিকে স্থানান্তর করে সেদিকে লক্ষ্য করে না। এটি ছোট ফাইলগুলির গণনা অসীমের মতো এর গণনা তৈরি করে এবং এগুলি চিরকালের জন্য ছোট হবে।

Comments

এটি আসলে প্রশ্নের উত্তর দেয় না।

— ডেভিডপস্টিল

এটি আসলে এর উত্তর দেয়, আপনি যদি মনোযোগ সহকারে পড়ছেন। এগুলি দুটি ধরণের খারাপ অনুমান এবং আমি ব্যাখ্যা করেছি যে তারা উদাহরণ ভিত্তিক বিপরীত প্রকৌশল দৃষ্টিকোণ থেকে কেন ঘটে।

— জিজিরিও