SASGIS - SAS.Планета |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0001716 | SAS.Планета | [All Projects] Баг | public | 28-11-2012 07:48 | 05-12-2012 13:20 |
|
| Reporter | Papazol | |
| Assigned To | | |
| Priority | normal | Severity | tweak | Reproducibility | have not tried |
| Status | confirmed | Resolution | open | |
| Platform | Windows | OS | XP | OS Version | Professional SP3 |
| Product Version | 110418 | |
| Target Version | 40xxxx | Fixed in Version | | |
|
| Summary | 0001716: Неточно считается оставшееся время при закачке |
| Description | Если качать большой полигон, и прервать закачку на 70-90%, либо изменить форму полигона, добавив к нему дополнительный участок, то при следующей закачке этого полигона оставшееся время считается неправильно. Это происходит из-за того, что программа довольно быстро определяет, что бОльшая часть полигона уже имеется в кэше. Оставшееся время считается исходя из общего количества тайлов, следовательно, на закачку оставшейся части, по мнению программы, остаётся совсем немного времени. По идее, время, потраченное на имеющиеся в кэше тайлы, учитывать не нужно, тогда оставшееся время будет более реальным. |
| Steps To Reproduce | Взять большой полигон, начать его скачивание. Когда останется скачать 20...10%, выйти из скачивания. Начать скачивание снова.
Или
Скачать полигон, затем изменить его форму, добавив дополнительный участок. Скачать этот полигон снова. |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 28-11-2012 07:48 | Papazol | New Issue | |
| 28-11-2012 12:23 | Dima2000 | Note Added: 0010078 | |
| 30-11-2012 21:06 | Papazol | Note Added: 0010096 | |
| 30-11-2012 21:43 | vasketsov | Note Added: 0010097 | |
| 01-12-2012 07:40 | Papazol | Note Added: 0010098 | |
| 01-12-2012 11:55 | Garl | Note Added: 0010105 | |
| 01-12-2012 15:08 | Papazol | Note Added: 0010111 | |
| 01-12-2012 19:21 | Garl | Note Added: 0010113 | |
| 02-12-2012 08:27 | Papazol | Note Added: 0010114 | |
| 05-12-2012 13:05 | vdemidov | Product Version | .Nightly => 110418 |
| 05-12-2012 13:05 | vdemidov | Target Version | => 40xxxx |
| 05-12-2012 13:05 | vdemidov | Summary | Неверно считается оставшееся время при закачке => Неточно считается оставшееся время при закачке |
| 05-12-2012 13:20 | vdemidov | Status | new => confirmed |
|
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
|
|
>А если сохранить закачку в файл и потом запустить его, как будет подсчитываться
>оставшееся время? Учитывается ли при этом то, что уже скачано?
будет показано невероятно быстрое время до окончания скачивания и при каждом скачанном тайле время будет расти и приближаться к реальному. |
|
|
|
|
|
Значит, так же работает, как и при обычном запуске. |
|