Я знаю, что диалоговое окно копирования Windows (в Windows XP) сначала сохраняет копию в памяти, и оно все еще копируется после закрытия диалогового окна, поэтому время выключено, но почему оценка времени, необходимого для создания копии так неточно, даже когда копирование памяти было отключено (в Vista и Windows 7)? Это так произвольно! Как работает вся процедура копирования, и почему Windows не может правильно оценить ее?
Раймонд Чен однажды написал очень хорошую статью об этом. По сути, диалог просто угадывает :).
http://blogs.msdn.com/b/oldnewthing/archive/2004/01/06/47937.aspx
"Потому что диалог копирования просто угадывает. Он не может предсказать будущее, но вынужден пытаться. И в самом начале копии, когда очень мало истории, прогноз может быть очень плохим.
Вот аналогия: предположим, что кто-то говорит вам: «Я собираюсь сосчитать до 100, и вам нужно давать непрерывные оценки относительно того, когда я закончу». Они начинают «один, два, три ...». Вы замечаете, что они идут со скоростью примерно одно число в секунду, поэтому вы оцениваете 100 секунд. О-о, теперь они замедляются. «Четыре ... ... ... пять ... ... ...» Теперь вы должны изменить свою оценку, возможно, до 200 секунд. Теперь они ускоряются: «шесть-семь-восемь-девять» Вы должны обновить свою оценку снова.
Теперь кто-то, кто слушает только твои оценки, а не тот, кто считает, думает, что ты не в своем вкусе. Ваша оценка увеличилась с 100 до 200 секунд и до 50 секунд; в чем твоя проблема? Почему вы не можете дать хорошую оценку?
Копирование файлов это то же самое. Оболочка знает, сколько файлов и сколько байтов будет скопировано, но она не знает, насколько быстрым будет жесткий диск, сеть или Интернет, поэтому ей остается только догадываться. Если пропускная способность копирования изменяется, оценка должна измениться, чтобы учесть новую скорость передачи. "
Я собираюсь сосчитать до десяти, 1....2....3....4 сколько точек потребуется, чтобы добраться до 10?
5.6.7 Как насчет сейчас? Принимаете ли вы во внимание все прошлые точки между числами и усредняете их, берете ли вы только последние 4 интервала и используете это среднее значение, вы только смотрите на последний интервал?
У вас та же проблема с передачей файлов. Скорость передачи файла не является постоянной, она ускоряется и замедляется в зависимости от множества факторов. Причина, по которой число так много скачет, заключается в том, что Microsoft склоняется к стороне спектра "только считай последний интервал".
В этой части спектра нет ничего плохого, она дает вам более точные значения "секунды в секунду" (одна секунда в реальном времени приводит к уменьшению счетчика на одну секунду), но это приводит к тому, что общее ETA таймера сильно перепрыгивает ,
Хорошим примером противоположной стороны является 7-Zip, когда он сжимается. Если скорость сжатия падает в процессе обработки, вы можете увидеть, что ETA не сильно скачет, как ETA передачи файлов, но может пройти от 2 до 3 реальных секунд, прежде чем таймер сработает за одну секунду (или даже может начать отсчет ) пока не стабилизируется на новой скорости.
Короче говоря: плохие алгоритмы и скачкообразная оценка на самом деле являются слабостью реализации.
Другие инструменты, такие как TeraCopy, работают лучше. Я думаю, что не стоит объяснять, почему их реализация не является хорошей. Они это заметят и улучшат.
Что сложно:
Для этого играют роль не только количество байтов, но и количество создаваемых файлов. Если у вас есть миллион файлов по 1 КБ или тысячи файлов по 1 МБ, ситуация будет совершенно иной, поскольку у первого есть издержки на создание множества файлов. В зависимости от используемой файловой системы это может занять больше времени, чем фактическая передача данных.
Этот диалог сводил меня с ума также довольно много раз:
Современные средства копирования Windows не намного лучше:
На самом деле Рэймонд Чен из Microsoft почти канонически ответил на этот вопрос от WAAAAAY, и в этой загадке есть несколько частей.
Потому что диалог копирования просто угадывает. Он не может предсказать будущее, но вынужден пытаться. И в самом начале копии, когда очень мало истории, прогноз может быть очень плохим.
Во-первых, об этом говорит Windows. Он знает, сколько файлов и насколько они велики, но скорость передачи на файл сильно варьируется. В некоторых случаях это зависит от таких вещей, как размер или расположение диска. С течением времени он корректирует свои предположения исходя из текущих и прошлых условий, и поэтому вы получаете неточные расчетные скорости передачи в реальных условиях.
Вот объяснение Рэймонда Чена, главного инженера-разработчика программного обеспечения в Microsoft:
Почему диалог копирования дает такие ужасные оценки?
Потому что диалог копирования просто угадывает. Он не может предсказать будущее, но вынужден пытаться. И в самом начале копии, когда очень мало истории, прогноз может быть очень плохим.
Вот аналогия: предположим, что кто-то говорит вам: «Я собираюсь сосчитать до 100, и вам нужно давать непрерывные оценки относительно того, когда я закончу». Они начинают «один, два, три ...». Вы замечаете, что они идут со скоростью примерно одно число в секунду, поэтому вы оцениваете 100 секунд. О-о, теперь они замедляются. «Четыре ... ... ... пять ... ... ...» Теперь вы должны изменить свою оценку, возможно, до 200 секунд. Теперь они ускоряются: «шесть-семь-восемь-девять» Вы должны обновить свою оценку снова.
В сообщении, приведенном выше, подробно обсуждается этот вопрос с некоторыми интересными комментариями.
Рэймонд Чен - легендарный человек, «Чак Норрис» от Microsoft, я не думаю, что вы получите более авторитетный ответ. Я уверен, что он, по крайней мере, видел рассматриваемый код.
Очевидная причина заключается в том, что скорость передачи меняется со временем, равно как и среднее значение, а также прогноз. Чтобы объяснить это не-техническому другу, я использовал аналогию, связанную с путешествием по воздуху. Вы собираетесь лететь над Атлантикой. Когда вы прибываете на такси в аэропорт вылета, ваш ETA составляет около двух месяцев. Когда вы высадитесь в аэропорту прибытия, исходя из вашей средней скорости, вы достигнете дома вашего друга через 5 секунд.
Но вы должны оценить, насколько скорость на самом деле может варьироваться, даже с тем, что кажется предсказуемым сценарием, таким как копирование файлов на одном диске или между двумя локальными дисками. Одной из новых функций, которые мне нравятся в Windows 8, является возможность отображать скорость с течением времени, если вы нажмете "подробнее". Если у вас нет доступа к машине с Windows 8, найдите множество примеров в диалоговом окне копирования изображений для Windows 8 . Многие из них довольно плоские, но многие из них также беспорядочно неровные, и вы задаетесь вопросом, действительно ли жесткий диск здоров, когда он падает до нуля.
Некоторые из этих ударов, вероятно, связаны с различиями в размере файла - меньшие поля дают больший доступ, что замедляет работу, особенно на механическом жестком диске, который нужно искать, перемещая головку чтения, - но некоторые могут быть просто дешевым диском, который глохнет при малейшем прикосновении, чтобы не повредить пластины.
Существуют лучшие и худшие алгоритмы прогнозирования ETA, но для точного прогнозирования компьютер должен быть общеизвестным. Риск попытки сделать алгоритм "умным" состоит в том, что он может создать новые, непредвиденные, случаи, когда он еще более забавно ошибается.
Единственный способ узнать, сколько времени потребуется, чтобы сжать набор файлов, - это сжать их. Иногда предположение Windows близко, иногда оно совершенно неверно. То же самое верно и для копирования большого количества файлов, как я уверен, вы заметили.
Это не столько ошибка, сколько бесполезное отображение редко точной информации. Лучший способ исправить это - закрыть глаза. Игнорируй это. ;-)
Возможно, есть программа, которая может копировать / сжимать файлы и издавать звуковой сигнал по окончании. Это было бы действительно полезно. Мы могли бы немного вздремнуть, пока мы ждем, пока Windows закончит уборку.
Я думаю, что причина была хорошо объяснена в одном из комментариев к сообщению в блоге, связанном с ответом Роальда:
У него ужасный алгоритм оценки. Нет оправданий. Если ему нужно скопировать 1000 файлов по 1 КБ и 10 файлов по 1 МБ, он думает, что он будет так же занят с файлом 1 МБ, как и с файлами 1 КБ.
Причина, по которой он дает такие ужасные оценки, заключается в том, что это не очень хорошо сделано. Очевидно, что он никогда не может быть точным на 100%, но может быть намного лучше.
Чтобы ускорить процесс копирования (не тратить слишком много времени на вычисление оценок времени вместо выполнения операций, связанных с копированием), встроенная в Проводник утилита копирования Windows поддерживает ограниченный объем информации о том, как быстро выполнялись предыдущие операции записи. Каждый раз, когда ему нужно вычислить оставшееся время, он просто вычисляет среднее количество операций записи, которое заняло время, а затем умножается на количество оставшихся операций записи.
Проблема заключается в том, что время, необходимое для выполнения операции записи, не является постоянным - оно может значительно отличаться. Это, в свою очередь, приводит к значительным изменениям в оценке времени.
Вопреки распространенному мнению, они не достаточно сложны, чтобы бросить наши руки.
Причина, по которой большинство людей пишут блоги, а люди здесь не знают о такой возможности, настолько хороша, насколько я могу судить, из-за области обучения и широты обучения. Скромное, но в то же время очень удобное средство должно быть возможно для [выпускника с более недавним обучением, чем авторы блогов] [многомиллиардной компании] Microsoft.
Я попытаюсь примерно объяснить, почему.
1. не может надежно предсказать будущую загрузку ввода-вывода из-за обстоятельств, выходящих за рамки ядра
2. не отслеживает эвристику ввода-вывода на каком-либо полезном уровне детализации. Использование - гораздо более широкое понятие, чем скорость чтения / записи диска / сети.
очень мало нужно сделать для этого, чуть больше, чем отслеживать основную информацию об использовании ввода-вывода
3. если бы они отслеживались, не использовались бы для эвристики
Где a, b и c имеют 3 состояния в каждом: файловый менеджер просматривает файлы (или только метаданные) перед копированием, а F * (bxc) + d - не дорогостоящее вычисление; если вы хотите что-то более точное, используйте справочную таблицу с большим количеством состояний - вряд ли можно рассчитать вообще.
примечание: размеры здесь для диска, будут отличаться от SSD - начало / середина / конец не имеет значения
Одним из ключевых различий между тем, что я описал, и предыдущими реализациями, которые мы видели до сих пор, было бы, вкратце, наблюдение за размером файла и нарушением / энтропией файла на диске и его использование для [более] точного учета временного элемента использования диска.
(патент оставлен в качестве упражнения для читателя ...)
Есть 3 фактора, которые необходимо учитывать:
Числа 1 и 3, похоже, оказывают наиболее очевидное влияние на расчет времени передачи, но очень многие люди не учитывают номер 2. Это может оказать огромное влияние на то, сколько времени займет передача, и это трудно определить количественно.
По сути, каждый раз, когда файл записывается, файловая система должна записать немного метаданных о файле, например. владение, права доступа, время создания / изменения / доступа и т. д. В зависимости от конкретной файловой системы эта информация может быть записана на часть диска, расположенную очень «далеко» от места записи файла. Эти накладные расходы на файловую систему могут привести к тому, что, казалось бы, простая передача займет много времени и / или может привести к значительным колебаниям оценки времени.
Например: при переносе одного большого файла вы заметите, что оценка остается стабильной и достаточно точной, но при передаче сотен файлов разных размеров, но одинакового общего размера, может потребоваться больше времени, что приведет к подгонке оценки времени.
Есть много "неизвестных" переменных, когда вы пытаетесь предсказать, сколько времени займет что-то. Например, если программа знает, что существует 3500 файлов, и что файлы имеют размер 3,5 ГБ (3500 МБ), означает ли это, что каждый файл равен 1 МБ? Не обязательно. Там может быть много файлов по 4 КБ, много файлов по 100 МБ и некоторые другие между ними. Кроме того, вы должны принять во внимание, откуда приходят файлы и куда они идут (например, медиа). Какое самое большое узкое место? Как вы пытаетесь копировать файлы с жесткого диска через VPN- туннель? Вы даете лучший сценарий, а затем настраиваете свои счетчики в режиме реального времени. Вот почему вы видите, как эти индикаторы прогресса меняются на лету.
Математически правильная модель состоит в том, чтобы фактически выполнить наивное усреднение и экстраполяцию:
transfer speed = data copied / time elapsed
time remaining = data remaining / transfer speed
Причина в том, что по закону больших чисел локальные колебания компенсируют среднюю скорость передачи, и это даст вам наиболее стабильный результат.
Кажется, что Microsoft делает, чтобы вычислить скорость передачи в самый последний период времени. Это означает, что каждое локальное колебание значительно меняет результат.
Короче говоря, расчет основан на текущей скорости передачи.
Например: если скорость передачи снижается из-за того, что Windows вынуждена копировать огромное количество крошечных файлов, ожидаемое время увеличивается линейно, и наоборот для больших файлов.
Почти невозможно предсказать, какой будет скорость передачи в течение всего процесса передачи, поскольку она зависит от множества факторов, таких как размер файла, загрузка процессора, ошибки передачи и т.д.
There is some way to refine or correct this kind of "bug"?
Как сказал Роальд ван Доорн, это просто предположение. Конечно, это не значит, что он не может быть лучшим догадкой. Есть много эвристик, которые могут быть использованы для расчета этого.
Очевидно, что все это легко реализовать ... и я упомянул только копии файлов. Аналогичная работа должна быть сделана для всех видов переводов.
Вопрос, который вы должны задать себе. Вы бы предпочли, чтобы Microsoft потратила время на то, чтобы дать вам более точную оценку, или вы бы предпочли, чтобы ваши файлы быстрее передавались.
Однако, если вы сжимаете что-то с помощью 7-zip, вы заметите, что это гораздо лучше, чем угадывать, чем Windows. Я сомневаюсь, что он делает что-то сложное, просто немного лучше догадывается.
Просто хотел добавить, что общее количество файлов - это самый трудоемкий фактор операций копирования файлов на ПК. Я всегда помню, как в молодости я умышленно вызывал сбой ПК в своем компьютерном классе, начиная с 1 файла без содержимого и копируя его, затем выбирая 2 файла и снова копируя и так далее. Как только он получил около 1024 файлов, ему потребовалось огромное количество времени, чтобы что-то сделать, даже если он не копировал никакой информации, кроме заголовка файла. Попробуйте сами даже на новой ОС, экспоненциальной копии файла, и вы увидите, что произойдет. Пища для размышлений.
В блоге MSDN есть несколько интересных ответов. Совершенствуем основы управления файлами: копируем, перемещаем, переименовываем и удаляем об этом. Что касается того, почему это трудно:
Оценить время, оставшееся до завершения копирования, практически невозможно с какой-либо точностью, потому что здесь задействовано много непредсказуемых и неконтролируемых переменных - например, какая пропускная способность сети будет доступна для длины задания копирования? Будет ли ваше антивирусное программное обеспечение раскручиваться и запускать сканирование файлов? Нужно ли другому приложению доступ к жесткому диску? Будет ли пользователь начать другую работу копирования?
И как они улучшаются,
Вместо того, чтобы тратить много времени на оценку низкой достоверности, которая будет незначительно улучшена по сравнению с текущей, мы сосредоточились на том, чтобы представить информацию, в которой мы уверены, полезным и убедительным образом. Это делает самую надежную информацию, которую мы имеем в вашем распоряжении, чтобы вы могли принимать более обоснованные решения.
Тем не менее, если вы действительно хотите улучшить только данную оценку и сохранить индикатор выполнения таким, какой он есть, вы можете сделать что-то, предложенное в комментарии Slashdot:
Ведение таблицы ожидаемых скоростей для каждого устройства хранения в файловой системе. Запишите, сколько времени занимает чтение информации файловой системы. Когда устройство установлено, если это приемлемо для типа устройства, ищите середину и конец, измеряя скорости там же. Получите приблизительные кривые для скоростей чтения и записи в разных местах и используйте их для будущих оценок. Для будущих операций чтения и записи обратите внимание на то, где они находятся и как быстро они идут, и соответствующим образом скорректируйте кривые.
Когда операция начинается, посмотрите на кривые для ввода и вывода для соответствующих устройств. Найти ожидаемую скорость для целевого местоположения. Для оценки следует использовать любую скорость ниже.
Я только что скопировал 200 ГБ с жесткого диска USB на мой основной диск. Было около 130000 файлов
После первых 4-5 минут я заметил, что:
В начале окна изменили оценку с 1 часа на 5+ часов, затем обратно на 1 час и так далее. В конце, как и в 95%, он все еще менял оценку с 10 минут до 10+ часов. Так что вместо того, чтобы стать более точным, оно становилось все менее и менее точным.
Простые математические шоу:
130 000 файлов со скоростью 100 файлов в секунду = 22 минуты
200 000 МБ при 70 МБ в секунду = 47 минут
22 минуты - потеря времени на копирование файлов размером в несколько килобайт. 47 минут - время, необходимое для передачи фактических данных, если время поиска отсутствует.
Сумма 22 минут + 47 минут - это абсолютное максимальное время, которое это может занять.
Таким образом, очевидно, что оценка должна быть где-то между 47 и 69 минутами.
Диалоговое окно показывает примерно 90%: «Я копирую несколько небольших файлов со скоростью 1 МБ / с, данных больше на 20 ГБ, для завершения потребуется 5:30 часов.
Несколько секунд спустя:«Я копирую большой файл здесь, на скорости 70 Мбит / с это займет 4 минуты.
Что на самом деле видит человек из того же диалога:120 000 файлов и 180 ГБ уже скопированы за 40 минут. Остальные 10000 файлов и 20 ГБ должны занять около 5 минут
Диалог дает достаточно информации, чтобы сделать расчет, который становится все более и более точным каждую секунду. Он знает скорость, с которой копируются небольшие файлы. Он знает, с какой скоростью копируются большие файлы. Он также знает, сколько файлов и сколько байтов осталось.
Сделать такое точное предположение очень просто, только установив верхний и нижний пределы.
Диалог показывает немного более корректные данные только в случае, когда большие файлы находятся перед маленькими файлами. Если это так, то он начинается через 40 минут, а через 30 минут он начинает копировать небольшие файлы и говорит: «Ну, мне нужно еще 20 минут».
Но когда маленькие файлы в начале и большие файлы в конце. Диалог фактически не заботится о том, какие "файлы в секунду" он передает мелким файлам. Это делает его вычисление, как будто количество маленьких файлов равно бесконечности, и что они будут всегда маленькими.