Во многих приложениях у нас есть некоторые индикаторы выполнения для загрузки файла, задачи сжатия, поиска и т. Д. Мы все часто используем индикаторы выполнения, чтобы пользователи знали, что что-то происходит. И если мы знаем некоторые детали, например, сколько работы было проделано и сколько еще осталось сделать, мы можем даже дать оценку времени, часто путем экстраполяции того, сколько времени понадобилось, чтобы добраться до текущего уровня прогресса.

Сжатие ETA скриншот http://jameslao.com/wp-content/uploads/2008/01/winrar-progress-bar.png

Но мы также видели программы, которые отображают «оставшееся время» «ETA» просто комично. Он утверждает, что копирование файла будет сделано через 20 секунд, затем через одну секунду он говорит, что это займет 4 дня, затем он снова начнет мигать, чтобы быть 20 минут. Это не только бесполезно, но и сбивает с толку! Причина, по которой ETA так сильно различается, заключается в том, что сам уровень прогресса может меняться, а математика программиста может быть слишком чувствительной.

Apple обходит это, просто избегая любых точных прогнозов и просто давая неопределенные оценки!Смутное уклонение от Apple http://download.autodesk.com/esd/mudbox/help2009/images/MED/DaliSP1/English/Install_licensing/install_progress_MAC.png

Это тоже раздражает, у меня есть время для быстрого перерыва, или моя задача будет выполнена еще через 2 секунды? Если прогноз слишком нечеткий, то делать прогноз вообще бессмысленно.

Простые, но неправильные методы

В качестве первого вычисления ETA, вероятно, мы все просто создаем функцию, например, если p - это уже сделанный дробный процент, а t - это время, которое потребуется, мы выводим t * (1-p) / p в качестве оценки сколько времени это займет, чтобы закончить. Это простое соотношение работает «ОК», но оно также ужасно, особенно в конце вычислений. Если из-за низкой скорости загрузки происходит медленное продвижение копии в одночасье и, наконец, утром, что-то срабатывает, и копия начинает работать на полной скорости со скоростью 100Х, ваш ETA на 90% завершится, может сказать «1 час» и 10 секунд позже вы наберете 95%, и ETA скажет «30 минут», что явно смущающе плохое предположение… в этом случае «10 секунд» - намного, намного, лучшая оценка.

Когда это происходит, вы можете подумать, чтобы изменить вычисление, чтобы использоватьнедавний скорость, а не средняя скорость, чтобы оценить ETA. Вы берете среднюю скорость загрузки или скорость завершения за последние 10 секунд и используете эту частоту, чтобы прогнозировать, как долго будет выполняться. Это довольно хорошо работает в предыдущем примере «загрузка за ночь, который ускорился в конце», поскольку в конце он даст очень хорошие окончательные оценки завершения. Но у этого все еще есть большие проблемы ... это заставляет ваш ETA сильно подпрыгивать, когда ваша скорость быстро меняется в течение короткого периода времени, и вы получаете "сделано за 20 секунд, сделано за 2 часа, сделано за 2 секунды, сделано за 30 минуты "быстрого отображения позора программирования.

Актуальный вопрос:

Каков наилучший способ вычисления предполагаемого времени выполнения задачи, учитывая историю вычислений? Я не ищу ссылки на наборы инструментов GUI или библиотеки Qt. Я спрашиваю оалгоритм генерировать наиболее разумные и точные оценки времени завершения.

Был ли у вас успех с математическими формулами? Какое-то усреднение, может быть, с использованием среднего значения ставки за 10 секунд со скоростью более 1 минуты со скоростью более 1 часа? Какой-то искусственный фильтр типа «если моя новая оценка слишком сильно отличается от предыдущей оценки, уменьшите ее, не дайте ей слишком сильно отскочить»? Какой-то необычный анализ истории, в котором вы интегрируете прогресс и прогресс по времени, чтобы найти стандартное отклонение скорости, чтобы получить статистические показатели ошибок по завершении?

Что вы пробовали и что работает лучше всего?