Как стать автором
Обновить

Комментарии 9

А если нужна средняя скорость за последние 24 часа — всю память отсчетами будем занимать? :)
Я ожидал, что в конце вы таки придете к вычислению скользящего среднего (как это, например, сделано в линуксовом load average).
Минусы:
1. Надо с равными интервалами вызывать функцию, пересчитывающую текущее значение.
2. Пересчитать из «среднего за час» в «среднее за минуту» не получится: нужно заранее решить, средние значения за какой период нас интересуют.
Плюсы:
1. Не надо хранить N последних отсчетов.
2. Код простой и быстрый.
Я не случайно описывал свой кейс в начале — я только на него и рассчитывал.
Да, среднюю за сутки считать так не получится, но у меня и задачи такой не стояло =)

В целом, счетчик сделан условно realtime, для отображения. Если нужна возможность нарисовать график, пересчитать в других единицах и прочее — надо куда то агрегировать уже посчитанные данные, т.е. делать дополнительную логику которая всё это сможет покрутить.

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

ПС: по линуксовому — первый раз вижу, почитаю и подумаю, спасибо =)
Не пробовал.

А можете пояснить, что это такое и что дает? По описанию кажется, что это аналог eventArgs у WebClient.DownloadProgressChanged, и там о скорости нет ничего.

Да, это аналог. Вычисления скорости остаются, но можно убрать GetBytesAsync:


using (var handler = new ProgressMessageHandler())
using (var client = HttpClientFactory.Create(handler))
{
    handler.HttpReceiveProgress += (s, e) => 
        NetworkSpeed.AddInfo(e.BytesTransferred  - lastRecorded);
    // use client here to download file
}
Вариант, спасибо =)

Я просто сам `HttpClient` не использую, поэтому был не в курсе.

Вы своё приложение на гигабите (с задержками) тестировали? Меня смущает буфер в 80КБ. В худшем случае может же ограничивать скорость передачи.

Гигабита у меня под рукой нигде нет.
80кб — стандартная реализация MS, взято прямо оттуда же:
        //We pick a value that is the largest multiple of 4096 that is still smaller than the large object heap threshold (85K).
        // The CopyTo/CopyToAsync buffer is short-lived and is likely to be collected at Gen0, and it offers a significant
        // improvement in Copy performance.
        private const int _DefaultCopyBufferSize = 81920;

Почему смущает? За один вызов Read вы все равно не сможете прочитать больше данных, чем содержится в приёмном буфере сокета. Значение по умолчанию в Windows — 64K.


На самом деле можно читать и кусками меньшего размера — даже 8K для гигабита будет нормально. На производительности это не скажется. На гигабите будет около 15K IOPS на чтение и столько же на запись при работе с буферами по 8К.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории