|
Notes |
|
|
|
Тоже долго удивлялся странностям в подсчёте оставшегося времени и объёма для скачки. Думал как надо считать чтобы было точнее и лучше. Потом с калькулятором в руках понял КАК именно оно считается - и дошло, что лучше просто не сделать потому что нет данных для такого расчёта.
Программа не имеет понятия сколько тайлов из списка уже выкачаны в кэш, она знает лишь сколько всего тайлов нужно, сколько осталось проверить и сколько тайлов удалось скачать (и за какое время), вот по этим данным и расчитывает, что если качать все оставшиеся тайлы с той же средней скоростью, то ... А есть они в кэше или нет - сиё никому неведомо и быстро проверить это нереально.
Потому расчёт верен, просто другой (видимо не совсем очевидный). И предлагаю закрыть тикет как нерешаемый. |
|
|
|
|
А вот если просто не учитывать файлы, которые уже есть в кэше, при подсчёте скорости скачивания?
Я понимаю алгоритм подсчёта так (если ошибаюсь, поправьте):
Tост = Nост / Vскач,
где Tост - оставшееся время, Nост - оставшееся количество файлов, подлежащее обработке, Vскач - скорость скачивания.
В свою очередь,
Vскач = Nзад / Tскач,
где Nзад - некоторое заданное количество файлов, Tскач - время, за которое скачалось это количество файлов,
Nост = Nобщ - Nобр,
где Тобщ - общее количество файлов в полигоне, Nобр - количество уже обработанных (и скачанных, и проверенных) файлов.
Тогда формула получается
Tост = ((Nобщ - Nобр) * Tскач) / Nзад.
Если считать оставшееся время только после того, как будут именно СКАЧАНЫ очередные Nзад файлов, ошибка за счёт уже имеющихся в кэше файлов устремится к нулю. Пусть первые данные по оставшемуся времени придут лишь после проверки большого количества уже имеющихся файлов, на это нужно некоторое время, но на скачивание его нужно на несколько порядков больше. |
|
|
|
|
>ошибка за счёт уже имеющихся в кэше файлов устремится к нулю
Неправда. Проблема в общем виде до нуля нерешаема, так как неизвестно, сколько тайлов будет ещё пропущено впереди (потому что они уже есть). То что есть тайлы в _начале_ полигона и они пропукаются в _начале_ скачки - лишь частный случай.
>Vскач = Nзад / Tскач
Да. В такой оценке тоже есть смысл. Более того, чаще всего именно она будет точнее существующей (не только из-за дыр, но и из-за неравномерности скорости скачки, разной скорости отдачи http 200 и http 404 по областям где нет покрытия, и т.п. локальным эффектам).
>Пусть первые данные по оставшемуся времени придут лишь после проверки
Надо просто не точное время скачки показывать, а диапазон из этих двух значений, старого и по этому алгоритму. Или просто максимальное ))) |
|
|
|
|
|
Максимальное время как раз и важно, ибо для чего оно (оставшееся время) вообще нужно? При существующем алгоритме указывается, напротив, минимальное время. В общем, есть над чем поразмыслить. |
|
|
|
(0010105)
|
|
Garl
|
|
01-12-2012 11:55
|
|
тут примерна та же ситуация как с подсчётом оставшегося времени копирования файлов в windows один в один!
побороть её не получается даже у micrsoft. |
|
|
|
|
|
А если сохранить закачку в файл и потом запустить его, как будет подсчитываться оставшееся время? Учитывается ли при этом то, что уже скачано? |
|
|
|
(0010113)
|
|
Garl
|
|
01-12-2012 19:21
|
|
>А если сохранить закачку в файл и потом запустить его, как будет подсчитываться
>оставшееся время? Учитывается ли при этом то, что уже скачано?
будет показано невероятно быстрое время до окончания скачивания и при каждом скачанном тайле время будет расти и приближаться к реальному. |
|
|
|
|
|
Значит, так же работает, как и при обычном запуске. |
|