QoS

[gm]

Hi,

Folgende QoS-Regel für einfache ICMP-Pings scheint zu funktionieren (Pings bleiben niedrig, trotz parallelem FTP-Upload, Gesamtuploadkapazität der Leitung 640 kBit):

Code: Alles auswählen

	Name	Prot.	Quelle	Ziel		Aktion	verknuepft	Prio	Aktiv	VPN-Regel	Stateful	Rtg-Tag	Kommentar
QOS_OUT_PRIO_ICMP	ICMP	QOS_OUT_PRIO_ICMP0 QOS_OUT_PRIO_ICMP1	ANYHOST	QOS_OUT_PRIO_ICMP0	nein	9	ja	nein	ja	0	QOS: 4 KBit global fuer ICMP

Objekttabelle:
ICMP	%P1
QOS_OUT_PRIO_ICMP0	%A192.168.1.0 %M255.255.255.0 %A192.168.2.0 %M255.255.255.0
QOS_OUT_PRIO_ICMP1	%A192.168.3.0 %M255.255.255.0 %A192.168.0.0 %M255.255.255.0


Aktionstabelle:
QOS_OUT_PRIO_ICMP0	%Lctwds0 @i %A %Ft256 @i %Qgtds4 @i %Qgrds16 @i

Diese Regeln hier für die Priorisierung von Gameserver-Daen greifen zwar laut LANMONITOR (ersichtlich an den Reservierten QoS-Werten und der aktiven Fragmentierung), aber die Pings sind dennoch extrem hoch (wenn man ein Diagramm von den Laufzeiten macht kommt eine Treppenstruktur zu tage, siehe Bild1):

Code: Alles auswählen

Name								 Prot.		Quelle	Ziel	Aktion	verknuepft	Prio	Aktiv	VPN-Regel	Stateful	Rtg-Tag	Kommentar
QOS_OUT_TAG_CSTRIKE_QOS_EF	UDP	ANYHOST	%S27015 %A192.168.3.11	%Lctwp50 @i %GEF	ja	3	ja	nein	ja	0	QOS: QoS.EF tag setzen bei 192.168.3.11:27015 ab 50. Paket
QOS_OUT_PRIO_CSTRIKE	UDP	ANYHOST	%S27015 %A192.168.3.11	QOS_OUT_PRIO_CSTRIKE0	nein	2	ja	nein	ja	0	QOS: 40 KBit pro Verb., bei QoS.EF., 192.168.3.11:27015

Aktionstabelle:
QOS_OUT_PRIO_CSTRIKE0	%Lctwds0 @idEF %A %Ft256 @idEF %Qctds40 @idEF %Qgrds640 @i

Hat jemand eine Idee wieso das so ist?
Vielen Dank für Eure Hilfe schon mal im Voraus.

Gruß
gm

[backslash]

Hi gm

Hat jemand eine Idee wieso das so ist?

nun ja, du hast die Regeln für Verbinungen erstellt, die von aussen auf den Server zugreifen (Quelle: ANYHOST)... Ich vermute mal, die pings in dem Diagramm wurden vom Server aus gestartet - dann greifen die Regeln aber nicht...

Gruß
Backslash

[gm]

Hi backslash,

die Pings haben ich passiv auf der Konsole des Gameservers beobachtet (Latenzzeiten). Sollten daher repräsentativ sein und stimmen. Auch die Treppenstruktur bei den Pingzeiten spricht dafür dass die Pings die richtigen sind (die Abstände zwischen den Balken sind ca. 400 ms).

Gruß
gm

[backslash]

Hi gm

die Pings haben ich passiv auf der Konsole des Gameservers beobachtet (Latenzzeiten).

wie willst du passiv pings messen?

Sollten daher repräsentativ sein und stimmen. Auch die Treppenstruktur bei den Pingzeiten spricht dafür dass die Pings die richtigen sind (die Abstände zwischen den Balken sind ca. 400 ms).

ich habe auch nicht bezweifelt, daß das die pings sind... ich meinte nur, daß du die pings vom Server aus gestartet hast und daß deshalb die Regeln nicht greifen, weil sie ja auf eingehende Verbindungen reagieren...

Gruß
Backslash

[gm]

Hi backslash,

wie willst du passiv pings messen?

"Aktiv", also mit einer gesonderten Verbindung, könnte man die Pings in meinem Fall gar nicht messen:
Der Server sitzt hinter einem NAT. Auch die die Clients sind zu 90% hinter einem NAT-Router verborgen. Da nur ein einziger Port vom LANCOM zum Gameserver weitergeleitet wurde und die Clients auch genattet sind scheidet ein Ping wie auch immer geartet aus. Es sei denn es wird die bestehende UDP-Verbindung zwischen Client und Server verwendet. Die Latenzzeiten müssen folglich aus den Laufzeiten des normalen Nutzdatenstrom bzw. von darin eingebettete Sonderpaketen berechnet werden. Wenn nun nur ein Client hohe Latenzen (Pings) hätte, könnte man sagen es liegt am Client, aber wenn bei 10 bis 12 Verbindungen gleichzeitig mit einem FTP-Upload die Pings hochgehen, dann stimmt etwas nicht und genau das verstehe ich nicht.

Komisch ist, dass die Uploadgeschwindigkeit mit der der FTP läuft durchaus durch das QoS ausreichend runtergedrückt wird. Pro Verbindung zum Gameserver benötige ich ca. 25 kBit Bandbreite und es fehlen beim FTP-Upload auch wirklich n*40 KBit (QoS-Menge laut Regel pro Client), aber trotzdem sind die Pings so miserabel. Könnte es sein, dass die QoS-Regelung zu träge für solche Echtzeitanwendungen reagiert?

Gruß
gm

[backslash]

Hi gm

Pro Verbindung zum Gameserver benötige ich ca. 25 kBit Bandbreite

wieso reservierst du dann 640 kBit im Download für den Server (%Qgrds640 @i )?

aber trotzdem sind die Pings so miserabel.

Bist du dir sicher, daß du nicht mehr Bandbreite brauchst? Bedenke, daß beim VoiP für einen G.729-Codec, der eigentlich nur 8 kBit/s benötigt, aufgrund des ADSL-Overheads tatsächlich 57 kBit reserviert werden müssen...

Könnte es sein, dass die QoS-Regelung zu träge für solche Echtzeitanwendungen reagiert?

solange die Mindestbandbreite nicht überschritten wird, werden die "betroffenen" Pakete bevorzugt weitergeleiete, d.h. Das QoS regiert *sofort*. Wenn du aber mehr Bandbreite benötigst, als du reserviert hast (siiehe obiges Beispiel mit G.729), dann stauen sich die Pakete in der Sendequeue auf und du bekommst solche effekte.

Versuch doch einfach mal mehr zu reservieren... Die benötigte Rate kannst du wie folgt ermitteln:

Durch PPPoE hast du einen Overhead von 14 (Ethernet) + 8 (PPPoE) = 22 Bytes. Das AAL-5 Framing schlägt nochmal 8 Bytes auf, d.h. der gesamte Byte-Overhead ist 30 Bytes. Und das ganze wird auf ATM-Zellen verteilt, daher ergibt sich die benötigte Bandbreite zu:

reine IP-Bandbreite * ( (Durchschnittslänge der Pakete + 30 -1) / 48 ) + 1) * 48

Die Division ist eine Integer-Division, d.h. Nachkommastellen werden abgeschnitten

Gruß
Backslash

[gm]

Hi Backslash,

wieso reservierst du dann 640 kBit im Download für den Server (%Qgrds640 @i )?

Das ist nur RX und ist global für alle Verbindungen, die auf diese Regel matchen. Soll eigentlich nur verhindern, dass große Downloads irgendwie die Pingzeiten drücken. Der Wert ist so groß, damit noch etwas Sicherheit mit dabei ist (Downstream habe ich ja genug...).

Bist du dir sicher, daß du nicht mehr Bandbreite brauchst? Bedenke, daß beim VoiP für einen G.729-Codec, der eigentlich nur 8 kBit/s benötigt, aufgrund des ADSL-Overheads tatsächlich 57 kBit reserviert werden müssen...

Also auf UDP/IP-Basis brauche ich ca. 25 kBits. Maximal 30 kBits. Habe zu Testzwecken die Reservierung für TX auf 56 kBits erhöht, aber leider noch keine Besserung festgestellt. Soll ich wie in dem Beispiel die 7fache Bandbreite reservieren die ich eigentlich brauche?!

reine IP-Bandbreite * ( (Durchschnittslänge der Pakete + 30 -1) / 48 ) + 1) * 48

Is diese Formel wirklich richtig? Der Faktor (Skalarwert) ist doch viel zu groß um richtig sein zu können. Bsp: 160 Byte/Paket im Schnitt: ( ( 160 + 30 -1) / 48 + 1) *48 = 192 (alle Berechnungen als int)

[Edit 22:00 Uhr]
Reicht es eigentlich eigentlich nicht diesen Overhead in den Parametern für das externe DSL-Modem einzustellen (meine Parameter siehe unten)?

Ein normaler Ping, der gemäß der geposteten QoS-Regeln auch priorisiert ist, produziert mit einem FTP-Upload im Hintergrund auch enorme Ping-Zeiten (schwankend zwischen 120 ms und 230 ms). Die Leitung hat ca. 640 KBit Upload und FastPath. Mit der QoS-Regel müssten sich doch Werte von max. 80 ms bei einem FTP-Upload im Hintergrund einstellen, wenn zum Ziel auf freier Leitung ein Ping 20 ms dauert?

Könnte es sein, dass ich bei den Einstellungen für das externe DSL-Modem einen Fehler drin habe:
Werte laut Speedport 200: Download: 6656 kBit, Upload: 672 kBit, Fastpath
Werte im Lancom unter Schnittstellen -> WAN -> Einstellungen DSL: Downstream-Rate 6028 kBit, Upstream-Rate 608 kBit und als Externer Overhead habe ich 36 Byte drinstehen.

Gruß
gm

[gm]

Hallo,

das Problem mit den schlechten Pingzeiten habe ich leider noch immer nicht mit den Mindestbandbreiten in den Griff bekommen. Habe die letzten Tage noch etwas mit DiffServ experimentiert. Wenn ich zusätzlich zu den Mindestbandbreiten noch DiffServ z.B. AF41 vergebe, dann klappt es auch halbwegs mit den Pingzeiten. Aber das kann nicht des Rätsels Lösung sein oder?

Hat jemand QoS-Regeln mit Mindestbandbreiten am Laufen die auch im Bezug auf die Pingzeiten funktionieren und könnte mir vielleicht ein paar Tips geben, was ich falsch mache?

Gruß
gm

[backslash]

Hi gm

Is diese Formel wirklich richtig? Der Faktor (Skalarwert) ist doch viel zu groß um richtig sein zu können. Bsp: 160 Byte/Paket im Schnitt: ( ( 160 + 30 -1) / 48 + 1) *48 = 192 (alle Berechnungen als int)

sorry, du mußt das Ganze natürlich wieder durch die Durchsnittslänge der Pakete teilen, in deinem Beispiel also 192/160 * Bandbreite. (die Division ist hier natürlich als Fließkomma auszuführen...)

Gruß
Backslash