Вычисление предполагаемого времени копирования / перемещения файла?

Question

Вдохновленный этим мультфильмом xckd Я задавался вопросом, каков наилучший механизм для предоставления пользователю оценки копирования / перемещения файла?

Тег alt на xkcd выглядит следующим образом:

Они могли бы сказать, что "соединение, вероятно, потеряно", но гораздо интереснее провести наивное усреднение по времени, чтобы дать вам надежду, что, если вы подождете около 1163 часов, оно наконец закончится.

Не обращая внимания на смешное, это действительно так, как это делается в Windows? Как насчет других ОС? Есть ли лучший способ?

Answer 1

Посмотрите мой ответ на аналогичный вопрос (и другие ответы там) о том, как оставшееся время оценивается в Проводнике Windows.

На мой взгляд, есть только один способ получить хорошие оценки:

• Рассчитать точное количество байтов, которые будут скопированы, прежде чем начать процесс копирования
• Пересчитайте, что вы оцениваете регулярно (каждые 1, 5 или 10 секунд, YMMV) на основе текущей скорости передачи
• Текущая скорость передачи может сильно колебаться при копировании в сети, поэтому используйте среднее значение, например, на основе количества байтов, переданных с момента последней оценки.

Обратите внимание, что первый пункт может потребовать некоторых усилий, если вы копируете много файлов. Наверное, поэтому ребята из Microsoft решили обойтись без него. Вам нужно решить, стоит ли дополнительные накладные расходы, создаваемые этими вычислениями, дать вашему пользователю более точную оценку.

Answer 2

Я сделал нечто похожее, чтобы оценить, когда очередь будет пустой, учитывая, что элементы удаляются из очереди быстрее, чем они ставятся в очередь. Я использовал линейную регрессию по самым последним значениям N (время, размер очереди).

Это дает лучшие результаты, чем наивный

(bytes_copied_so_far / elapsed_time) * bytes_left_to_copy

Answer 3

Я думаю, что диалоги должны просто признать свои ограничения. Это не раздражает, потому что не дает полезной оценки времени, это раздражает, потому что она авторитетно предлагает оценку, которая является очевидной ерундой.

Итак, оцените, сколько хотите, на основе текущего или среднего на данный момент курса, скользящих средних, отбрасывающих выбросы или что-то еще. Зависит от операции и типичной продолжительности событий, которые ее задерживают, поэтому у вас могут быть разные алгоритмы, если вы знаете, что копирование файла связано с сетевым диском. Но до тех пор, пока ваша оценка не будет достаточно последовательной в течение периода времени, равного меньшим 30 секундам или 10% от расчетного времени, покажите «о, дорогой, похоже, что-то вроде задержки», когда она сильно замедлена, или просто игнорируйте это, если это сильно ускорилось.

Например, диалоговые сообщения, принимаемые с интервалом в 1 секунду, когда соединение на короткое время останавливается:

remaining: 60 seconds               // estimate is 60 seconds
remaining: 59 seconds               // estimate is 59 seconds
remaining: delayed [was 59 seconds] // estimate is 12 hours
remaining: delayed [was 59 seconds] // estimate is infinity
remaining: delayed [was 59 seconds] // got data: estimate is 59 seconds
// six seconds later
remaining: 53 seconds               // estimate is 53 seconds

Answer 4

• Запустите глобальный таймер, который запускает, скажем, каждые 1000 миллисекунд и обновите счетчик общего времени. Давайте назовем эту переменную "elapsedTime"
• Пока файл копируется, обновите некоторую локальную переменную с уже скопированным количеством. Давайте назовем эту переменную "totalCopied"
• В событии таймера, которое периодически вызывается, разделите totalCopied на totalElapsed, чтобы получить количество скопированных байтов за интервал таймера (в данном случае 1000 мс). Давайте назовем эту переменную "bytesPerSec"
• Разделите общий размер файла на bytesPerSec и получите общее количество секунд, теоретически необходимое для копирования этого файла. Давайте назовем эту переменную remainingTime
• Вычтите elapsedTime из remainingTime, и вы несколько точно рассчитаете время копирования файла.

Answer 5

Я сам обдумывал это. У меня есть процедура копирования - через интерфейс в стиле Windows Explorer - которая позволяет передавать выбранные файлы с устройства Android на ПК.

В начале я знаю общий размер файла (ов), который должен быть скопирован, и, поскольку я использую C # .NET, я использую секундомер, чтобы получить истекшее время, и пока копия В процессе выполнения я сохраняю общее количество копий в байтах.

На самом деле я еще не тестировал его, но, кажется, лучший способ -

оценочный = истекший * ((totalSize - copiedSoFar) / copiedSoFar)

Answer 6

Если говорить о сетевой копии файла, то лучше всего рассчитать размер передаваемого файла, сетевой ответ и т. Д. Подход, который я однажды использовал, был:

Скорость соединения = Ping и вычисление времени туда и обратно для пакетов с 15 Кбайт.

Получите мой размер файла и теоретически посмотрите, сколько времени потребуется, если я его сломаю 15 КБ пакетов, используя мою скорость соединения.

Пересчитайте скорость моего соединения после начала передачи и отрегулируйте время, которое будет потрачено.

Answer 7

Больше всего я бы никогда не отображал секунды (только часы и минуты). Я думаю, это действительно расстраивает, когда вы сидите и ждете минуту, пока таймер прыгает между 10 и 20 секундами. И всегда отображать реальную информацию, например: xxx / yyyy MB скопировано.

Я бы также добавил что-то вроде этого:

if timeLeft > 5h --> Inform user that this might not work properly
if timeLeft > 10h --> Inform user that there might be better ways to move the file
if timeLeft > 24h --> Abort and check for problems

Я бы также проинформировал пользователя, если расчетное время слишком сильно меняется

И если это не слишком сложно, должна быть функция автоматической проверки, которая проверяет, все ли процесс еще жив и работает ли он корректно каждые 1-10 минут (в зависимости от приложения).