Christoph Emsenhuber f15dea6d16 TP6 geschlossen -- und der kritische Pfad ist leer ...

Abschluss wie entschieden. CAKE-Queue vom Geraet entfernt, Template-Abschnitt [11]
bleibt als BEGRUENDET LEER stehen: er traegt jetzt die Messreihe und die zwei
Fallen, damit der naechste QoS-Gedanke nicht bei null anfaengt.

  ohne CAKE 42,4 ms | 88 % 43,3 | 73 % 44,0 | 52 % der Linerate 44,6  (idle 12,9)

Die ComplianceRule `queue` BLEIBT und bewacht den Abschnitt weiter -- als leer.
Das ist derselbe Gedanke wie bei wifi-access-list: ein leerer Soll-Zustand ist
eine Aussage, kein fehlender Eintrag. 100/100 compliant, keine Drifts.

NEU: TP6.1 -- Saettigung vermeiden statt Bufferbloat bekaempfen.
Christophs Einwand beim Abschluss ("dann koennten wir zumindest den Sync von der
NAS zurueckhalten") trifft eine echte Luecke im TP6-Urteil: die 30 ms Zusatzlatenz
sind nicht wegzushapen, aber sie treten NUR unter Saettigung auf -- im Leerlauf
misst dieselbe Strecke 12,9 ms. Ein NAS-Sync, der bei laufendem Call zurueckweicht,
haelt die Leitung aus der Saettigung. Das ist eine groessere Verbesserung, als
Bufferbloat-Bekaempfung hier je gebracht haette.

Entwurf steht als TP6.1, bewusst NICHT gebaut:
  - Global-HTB (in TP6 als wirksam bewiesen) + zwei Prioritaetsklassen
  - Prioritaet statt hartem Cap: nimmt dem Sync die Bandbreite nur, solange
    jemand anders sie braucht
  - src-address=10.40.20.10, NICHT ganz VLAN20 -- dort haengen auch HA, Nautobot
    und pve, die nicht pauschal hinten anstehen sollen
  - Vorbedingung: /ip firewall mangle steht unter KEINER ComplianceRule
  - Abnahme misst den Call, nicht die Queue
  - und zuerst pruefen, ob der Fall ueberhaupt auftritt oder DSM schon drosselt

Kritischer Pfad: LEER. deny-by-default steht, Golden Config steht, WLAN steht,
VLAN1 ist weg, TP6 ist beantwortet statt offengelassen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-23 06:18:52 +02:00

32 KiB

Raw Blame History

View Raw