@Dusk Ich habe einen Provisioner während eines Zeitfensters mit deutlich höherem Verkehrsaufkommen beobachtet und erwartete zuerst das Übliche: CPU-Druck, dass der Speicher langsam unbequem wird, vielleicht, dass die Maschine anfängt, hinterherzuhinken.

Nichts davon ist eingetreten.

Die Netzwerkverbindung war der Teil, zu dem ich immer wieder zurückkam.

Das hat meine Sicht auf die Bandbreiten-Effizienz von Dusk verändert. Ich hatte Kadcast bisher hauptsächlich als eine Designentscheidung für die Übertragung betrachtet: schneller, sauberere Verteilung, weniger redundanten Traffic. In Ordnung. Aber Provisioner zahlen keine Rechnung für „sauberes Networking“. Sie zahlen für echte Infrastruktur.

Und weniger übertragene Bytes machen die Rechnung nicht zwangsläufig kleiner.

Wenn der Server ohnehin mit großzügiger Bandbreite geliefert wird, könnte der Betreiber in diesem Monat genau gar nichts sparen. Das hat mich zunächst gestört. Dann merkte ich, dass ich auf den falschen Zeitpunkt schaute.

Der wirtschaftliche Effekt dürfte sich wahrscheinlich dann zeigen, wenn der Knoten andernfalls die nächste Netzwerklaufstufe benötigen würde.

Weniger alltäglicher Verkehr lässt mehr Spielraum, bevor dieses Upgrade nötig wird. Dieselbe Maschine. Dieselbe monatliche Rechnung fürs Erste. Nur mehr Aktivität, die in den Rahmen passt.

Das ist nicht dasselbe wie zu sagen, dass Dusk Provisioner günstiger macht. Manchmal wird es so sein, manchmal nicht.

Worauf ich stattdessen achten würde, ist, wann Provisioner beginnen, ihre Konnektivität aufzurüsten, während die Aktivität von Dusk wächst.

Wenn sich dieser Upgrade-Punkt weiter und weiter nach hinten verschiebt, dann spart Kadcast nicht nur Bandbreite.

Es verschiebt echte laufende Betriebskosten.

#dusk $DUSK