RADs ETX-202A zeigte im Gegensatz zum getesteten Mitbewerb leichte, aber messbare Datenverluste unter Volllast. Allerdings lagen sie mit Werten zwischen 0,01 und 0,12 Prozent im unkritischen Bereich.
Bei der Latency lag das RAD-Produkt allerdings bei den Messungen mit kleinen Datenrahmen gleich eine Zehnerpotenz über den anderen Systemen. Mit über 72 µs konnten wir die höchste Latenzzeit im Betrieb mit den kleinsten Frames feststellen.
Den besten Latency-Wert erreichte das RAD-Produkt bei unserer Messung mit den 1280 Byte großen Paketen. Hier lag die Latenzzeit bei gut 30 µs. Der Betrieb mit Jumbo-Frames war mit dem RAD-Gerät nicht möglich. Die ermittelten Werte für den Jitter schwanken zwischen 0,9 und fast 45 µs, wobei wir den höchsten Wert bei der Messung mit den kleinsten Frames feststellen konnten. Im Mittel lag der Jitter bei rund 20 µs.
In der zweiten Testreihe untersuchte das Labor das Bandbreitenmanagement. Hierzu haben wir vier Datenströmen mittels Diffserv-Datenpriorisierung die DSCP-Werte 0, 16, 32 und 48 zugeordnet. Für diese vier Prioritäten wurden Bandbreitenlimitierungen von 10, 20, 30 und 40 MBit/s festgelegt.
Als Last dienten vier Datenströme mit den vier Prioritäten und einer Bandbreite von jeweils 250 MBit/s. Somit lag eine Gesamtlast von 1 GBit/s unidirektional an.
Das zu testende System sollte dann alle Daten verwerfen, die die Bandbreitenlimitierungen überstiegen. Die Analyse der empfangenen Datenströme ermöglichte dann Aussagen darüber, wie präzise das implementierte Bandbreitenmanagement in Abhängigkeit zum Frame-Format arbeitet.
Accedian Networks AMN-1000-TE-R lag bei allen Frame-Formaten durchgängig sehr exakt am Sollwert. Diesen überschritt das Accedian-System durchweg um Werte, die unter 0,01 MBit/s lagen.
Ciscos MES-3400G-12CS-D lag bei den gemessenen Bandbreiten dagegen teils deutlich über den geforderten Sollwerten. Dabei war festzustellen, dass die gemessen Durchsatzwerte umso höher über den Sollwerten lagen, desto kleiner die Frame-Formate waren.
RADs ETX-202A verhielt sich ähnlich wie die Cisco-Teststellung. Allerdings lag das RAD-System nicht ganz so hoch über den Sollwerten.
Die Abweichungen von den Sollwerten bei den Teststellungen von Cisco und RAD ist sicherlich darauf zurück zu führen, dass diese Systeme Algorithmen folgen, die gezielt über die Sollwerte gehen, um die für die Applikationen nutzbaren Bandbreiten nicht unter die Sollwerte fallen zu lassen.
Oder anders formuliert: Die einzustellenden Sollwerte regeln nicht die gesamte Bandbreite, sondern die nutzbare Bandbreite. Protokoll-bedingte Datenvolumen, die nicht der Applikation zur Verfügung stehen, kommen zur Nutzbandbreite hinzu.
Die Kenntnis des genauen Bandbreitenmanagement-Verhaltens ist wichtig für die Konfiguration des Netzwerks. Entscheidend ist, ob das Bandbreitenmanagement genutzt wird, um die notwendigen Bandbreiten für Applikationen sicherzustellen oder um Überlasten im Netzwerk zu verhindern. Gilt es, Überlastsituationen vorzubeugen, ist die Deckelung der gesamten Bandbreite einschließlich Protokoll-Overhead erforderlich. Ist das Ziel die Sicherstellung der erforderlichen Bandbreiten für die Applikationen, dann ist es wichtig, die nutzbare Bandbreite sicherzustellen.