Лучший способ вычислить ETA операции?
Из приведенных выше комментариев ясно, что общий балл и среднее время, затрачиваемое обратно пропорционально. То есть соотношение total_score и average_time_taken должно дать нам некоторое значение, которое мы теперь будем использовать для позиционирования или упорядочения наших записей. Следовательно, сначала я бы ввел в таблицу еще один столбец и рассчитал соотношение. Предполагая, что мы вызываем столбец ratio_average
, чтобы получить значения для нашего столбца, просто возьмите total_score / average_time_taken
, поэтому теперь при получении наших результатов из таблицы нам нужно будет только сделать следующее:
TotalScore::orderBy('ratio_average', 'desc')->get();
Выше теперь даст вам результаты в правильном порядке позиций с первой позиции
6 ответов
Я на самом деле презираю обе эти идеи, потому что они обе укусили меня раньше, как разработчика.
Первая не принимает во внимание ситуацию, когда операция действительно ускоряется, говорится в сообщении. что осталось 10 минут, и я вернусь через 3, и все будет готово.
Второе не учитывает замедление работы - я думаю, что проводник Windows должен использовать этот метод, так как он всегда, кажется, занимает 90% времени. время на копирование 90% файлов, затем еще 90% на копирование последних 10% файлов: -).
Я давно привык вычислять оба этих числа и усреднять их. Клиентам все равно (им было наплевать и на два других варианта, они просто хотели увидеть некоторый прогресс), но от этого мне становится легче, и это '
Что-то вроде этого должно помочь:
void ReportProgress(double position, double total)
{
static TimeType startTime;
if (position == 0)
{
startTime = GetTime();
return; // to avoid a divide-by-zero error
}
TimeType elapsedTime = GetTime() - startTime;
TimeType estimatedRemaining = elapsedTime * total / position;
TimeType estimatedEndTime = GetTime() + estimatedRemaining;
// Print the results here
}
Оценка приближается к истине, когда прогресс приближается к 100%
Я думаю, что эта проблема в значительной степени неразрешима, но можно сделать некоторые точные оценки с помощью немного больше знаний о выполняемом процессе. А в случаях, когда есть большие неизвестные, лучше проинформировать пользователя об этих неизвестных, чтобы они могли их принять во внимание.
Чтобы взять простой пример загрузки пакета файлов, у вас есть две известные переменные:
- ] Количество файлов
- Размер файлов
Для каждого файла существуют постоянные накладные расходы (время, необходимое для установления соединения, и время, необходимое для открытия файла в файловой системе). Существует также очевидное время загрузки, связанное с размером файлов. Создать функцию, которая могла бы выразить это как оставшееся время с точки зрения текущей скорости загрузки, легко и точно при условии, что скорость загрузки не слишком сильно колеблется. Но вот в чем проблема.
Имея точную модель выполняемой вами операции, легко предсказать, сколько времени она займет при отсутствии внешних воздействий. И это редко возможно.
Однако вы могли бы найти решение, которое пытается понять и объяснить эти внешние влияния. Пользователь может счесть полезным предупреждение, когда скорость резко меняется, поскольку он может скорректировать свои планы в соответствии с новым расчетным временем прибытия. Также может быть полезно объяснить, какие факторы влияют на текущую операцию. например,
Your download will complete in 6 minutes, if the download speed stays at 50k/s
Это позволяет пользователю делать обоснованные предположения, если они знают, что скорости могут измениться. И в конечном итоге приводит к меньшему количеству разочарований.
If you're wanting an ETA rather than a 'progress bar' then can you supply more than one figure?
Calculate the average download speed over a set period of time (depending on how long the overall download is likely to last, if you're looking at 10+ minutes then every 5s or so would be ok) and keep a record of the averages.
Then you can provide two figures, an upper and lower estimate.
If you're confident that the averages are going to be a good indication of the total time to download, then you could display the 40th percentile and the 60th - if the average download times vary widely then the 10th and 90th might be better.
I'd rather see a ballpark '21-30 minutes' and it be accurate than be told 29 min 35.2 seconds and it be miles out, and varying wildly from one update to the next.
Это будет зависеть от согласованности времени работы. Если он согласован, было бы вполне разумно использовать среднее время предыдущих операций. Если это не так, вам лучше рассчитать время для текущей операции и экстраполировать.
Изменить: Если операция несовместима с предыдущими запусками, а также несовместима от начала до конца, то у вас есть неразрешимая проблема. Предсказывать непредсказуемое всегда весело :)
Вы можете заранее решить, хотите ли вы недооценить или переоценить, и добавить к оценке фактор ошибочности. Например, если вы хотите завысить оценку, и первые 10% занимают 6 секунд, вы можете экстраполировать до 60 секунд, а затем умножить на 1,5, чтобы получить общую оценку в 90 секунд. По мере увеличения процента завершения
Брэм Коэн немного говорил об этом. Он приложил много усилий для расчета ETA в BitTorrent (однако в своем выступлении он упомянул, что никто еще не подошел к нему и сказал: «Эй! Отличные вычисления ETA в BitTorrent Man!»). Это не простая проблема.
Некоторые соответствующие ссылки: