@Dusk Я наблюдал за provisioner’ом во время более плотного трафика и ожидал сначала обычное: давление на CPU, когда память начинает чувствовать себя неуютно, возможно, машина начнёт отставать.

Но ничего из этого не произошло.

Главной частью, к которой я постоянно возвращался, была сетевая линия.

Это изменило то, как я думаю об эффективности пропускной способности Dusk. Я в основном рассматривал Kadcast как решение для распространения: быстрее, чище доставка, меньше избыточного трафика. В порядке. Но provisioner’ы не платят счёт за «чистую сеть». Они платят за реальную инфраструктуру.

И меньше переданных байтов не обязательно означает, что этот счёт станет меньше.

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

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

Меньше повседневного трафика оставляет больше запаса до того, как это обновление станет необходимым. Та же машина. Тот же ежемесячный платёж пока что. Просто больше активности, помещающейся внутри него.

Это не то же самое, что утверждать, будто Dusk делает provisioner’ов дешевле. Иногда так не бывает.

На что мне стоило смотреть, — это моменты, когда provisioner’ы начинают обновлять связность по мере роста активности Dusk.

Если точка этого обновления продолжает отодвигаться всё дальше, значит Kadcast — это не только экономия пропускной способности.

Это задержка реальных операционных расходов.
#dusk $DUSK