Рассчитать общий процент передачи пакетной загрузки с ограниченной информацией

Question

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

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

Bytes Sent/Total Bytes Для отправки = Первый прогресс бар

Это прекрасно работает (например, 512KB от 1024 Кб (50%).). Предположим, что у меня осталось еще два файла для загрузки, но оба размера файла неизвестны (так как это известно только после того, как файл начнет загружать, после чего он будет сжат, и размер файла будет определен), как бы я пошел сделать мой третий индикатор прогресса?

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

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

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

("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% второго файла загрузился), мы вернулись к 13%. Мне нужно лишь немногим более 33%! Я попробовал инверсию в 0.80 и a (2/3 * (2/3 * 0,2))

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

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

Answer 1

О господи, я не считал простой подход:

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

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

и контрольных испытаний на случай 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. 

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

Answer 2

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

ряд обходных путей приходят на ум:

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

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

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

Answer 3

Как заметил @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, вместо того, чтобы добавлять пропорцию текущего файла.

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