Рассчитать общий процент передачи пакетной загрузки с ограниченной информацией - PullRequest
1 голос
/ 17 марта 2010

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

Информация и алгоритмы, которые я могу выработать:

Отправлено байт / Всего отправлено байт = Первый индикатор выполнения (например, 512 КБ из 1024 КБ (50%))

Это отлично работает. Однако предположим, что у меня осталось еще два файла для загрузки, но оба размера файлов неизвестны (так как это известно только после того, как файл собирается начать загрузку, после чего он сжимается и размер файла определяется), как мне поступить? мой третий индикатор выполнения?

Я не думал, что это будет возможно, так как мне понадобится «Всего отправлено байт» / «Всего байт для отправки», чтобы воспроизвести логику моего первого индикатора выполнения в большем масштабе, однако я получил работающую версию : «Текущий номер файла, на котором мы находимся» / «общее количество отправляемых файлов», возвращающий процент в пакете, однако, очевидно, он не будет обновляться постепенно, и это довольно сыро.

Итак, подумав, я подумал, что если бы я мог включить текущий файл% с этим алгоритмом, я мог бы получить правильный процент прогресса от текущей точки моей партии.

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

("Current file number we are on" / "total number of files to send") * ("Bytes Sent" / "Total Bytes To Send")

Например, я думал, что был на правильном пути при тестировании с этим примером: 2/3 (2-й из 3-го файла) = 66% (пока это правильно), но потом, когда я добавил * 0,20 (для указания только 20 % 2-го файла загружено) мы вернулись к 13%. Что мне нужно, это чуть более 33%! Я попробовал инверсию в 0,80 и (2/3 * (2/3 * 0,2))

Можно ли это сделать, не зная целых байтов в пакете для загрузки?

Пожалуйста, помогите! Спасибо!

Ответы [ 3 ]

1 голос
/ 17 марта 2010

Как заметил @Carl, не зная, сколько еще нужно отправить, вы не сможете получить точную оценку уже отправленной доли. Отложив на минуту научную точность и достоверность, ваш расчет:

("Current file number we are on" / "total number of files to send") * 
("Bytes Sent" / "Total Bytes To Send")

должно быть расширено, чтобы включить идею фракций файлов. Если, скажем, вы отправили 6 файлов из 11 и 30% 7-го файла, вам нужно рассчитать

(6.3 / 11) * ("Bytes Sent" / "Total Bytes To Send")

Где-то в этой строке вы умножили количество отправленных файлов на пропорцию уже отправленного текущего файла, т. Е. Вычислили 0.66*0.2=0.13 вместо добавления пропорции текущего файла.

Снова поднимая научную точность и целостность, почему бы не использовать скорость передачи на втором индикаторе прогресса? Если вы интегрируете это в течение разумного периода, это должно дать наблюдателю удовлетворяющее чувство, что что-то происходит и прогресс достигнут.

1 голос
/ 17 марта 2010

Если вы не знаете, насколько велики другие файлы в очереди, то невозможно точно отобразить процентное значение, которое соответствует и пропорционально требуемому времени.

На ум приходит множество обходных путей:

  • Один из подходов, который выглядит, как вы знаете, но на самом деле обманывает пользователя, состоит в том, чтобы предположить, что все файлы в очереди имеют тот же размер, что и обрабатываемый файл, или среднее число файлов, обработанных до сих пор. Исходя из этого, индикатор выполнения будет показывать «правду», если все файлы действительно имеют одинаковый размер, и будет очень отключен, если размеры существенно различаются.

  • Другой подход заключается в том, чтобы ваш второй индикатор выполнения отображал не процент переданных байтов, а процент файлов. Таким образом, если у вас есть 4 файла, эта полоса будет меняться от 0 до 25%, от 50% до 75%, до 100%. Это не будет точно отражать затраченное время, но, по крайней мере, вы не будете лгать.

  • Вы можете сделать еще хуже с подходом, подобным подходу Microsoft: сделайте асимптотически медленный рост вашего индикатора выполнения при приближении к 100%, чтобы он никогда не достигал конца. Все, что видит пользователь, постоянно приближает значения «почти закончено». Такой дисплей выглядит круто, но в действительности дает пользователю как можно меньше информации.

0 голосов
/ 17 марта 2010

О, черт возьми, я не рассматривал самый простой подход:

(double)((ProcessedFileCount + DecimalBytesTransferred) / TotalFileCount)

(где processingFileCount всегда указывает на полностью переданные и завершенные файлы)

и контрольный тест на 3 файла:

Eg. ((2 + 1.0) / 3) (File 1+2+3: 100%) == batch 100% complete.
Eg. ((2 + 0.9) / 3) (File 1+2: 100%, File 3: 90%) == batch 96% complete.
Eg. ((1 + 0.9) / 3) (File 1: 100%, File 2: 90%) == only 63% complete.

Работает угощение! Спасибо за ваш вклад, хотя, ребята, я буду учитывать все внешние советы.

...