flowgrind – Online in der Cloud

PROGRAMM:

NAME/FUNKTION

flowgrind – erweiterter TCP-Verkehrsgenerator für Linux, FreeBSD und Mac OS X

ZUSAMMENFASSUNG

Fließmahlen [zur Auswahl] ...

BESCHREIBUNG

Fließmahlen ist ein fortschrittlicher TCP-Verkehrsgenerator zum Testen und Benchmarking von Linux.
FreeBSD- und Mac OS X TCP/IP-Stacks. Im Gegensatz zu anderen Leistungsmessungstools ist es
verfügt über eine verteilte Architektur, in der der Durchsatz und andere Metriken gemessen werden
zwischen beliebigen Flowgrind-Serverprozessen, Flowgrind-Daemon Flowgrindd(1).

Flowgrind misst neben dem Goodput (Durchsatz) auch die Interarrival-Zeit der Anwendungsschicht
(IAT) und Round-Trip-Time (RTT), Blockanzahl und Netzwerktransaktionen/s. Im Gegensatz zu den meisten Cross-
Mit den Plattformtesttools sammelt und meldet Flowgrind die von der Plattform zurückgegebenen TCP-Metriken
TCP_INFO-Socket-Option, die normalerweise im TCP/IP-Stack intern ist. Unter Linux und
Bei FreeBSD umfasst dies unter anderem die Einschätzung des Kernels zur End-to-End-RTT, der Größe
des TCP-Überlastungsfensters (CWND) und des langsamen Startschwellenwerts (SSTHRESH).

Flowgrind verfügt über eine verteilte Architektur. Es gliedert sich in zwei Komponenten: das Fließmahlwerk
Daemon, Flowgrindd(1) und die Fließmahlen Regler. Mit dem Controller fließt zwischen
Es können zwei beliebige Systeme eingerichtet werden, auf denen der Flowgrind-Daemon ausgeführt wird (Tests von Drittanbietern). Regelmäßig
In bestimmten Intervallen während des Tests sammelt der Controller die gemessenen Ergebnisse und zeigt sie an
die Dämonen. Es können mehrere Flows gleichzeitig mit denselben oder unterschiedlichen Einstellungen ausgeführt werden
Planen Sie jeden individuell. Prüf- und Steueranschluss können optional umgeleitet werden
verschiedene Schnittstellen.

Die Datenverkehrsgenerierung selbst erfolgt entweder in großen Mengen, ist ratenbegrenzt oder komplex
Anfrage-/Antworttests. Flowgrind verwendet libpcap, um den Datenverkehr automatisch zu entleeren
qualitative Analyse.

OPTIONAL

Dabei handelt es sich um zwei wichtige Gruppen von Optionen: Controller-Optionen und Flow-Optionen. Wie
Wie der Name schon sagt, gelten Controller-Optionen global und wirken sich möglicherweise auf alle Flüsse aus
Flow-spezifische Optionen gelten nur für die Teilmenge der Flows, die mit ausgewählt wurden -F .

Erforderliche Argumente für lange Optionen ist obligatorisch für eine zu kurze Optionen.

Allgemeines Optionen
-h, --help[=WAS]
Hilfe anzeigen und beenden. Optional kann WAS entweder „socket“ sein, um Hilfe zum Socket zu erhalten
Optionen oder „Traffic“-Hilfe zur Traffic-Generierung

-v, --Version
Versionsinformationen drucken und beenden

Controller Optionen
-c, --show-colon=TYP[,TYP] ...
Anzeige der Zwischenintervallberichtsspalte TYPE in der Ausgabe. Zulässige Werte für
TYPE sind: „interval“, „through“, „transac“, „iat“, „kernel“ (alle werden standardmäßig angezeigt),
und 'blocks', 'rtt', 'delay' (optional)

-d, --debuggen
Erhöhen Sie die Ausführlichkeit des Debuggings. Fügen Sie die Option mehrmals hinzu, um die Ausführlichkeit zu erhöhen

-e, --dump-Präfix=PRE
Präfix PRE dem Dump-Dateinamen voranstellen (Standard: „flowgrind-“)

-i, --report-interval=#.#
Berichtsintervall, in Sekunden (Standard: 0.05 s)

--Logdatei[=FILE]
Ausgabe in Protokolldatei FILE schreiben (Standard: flowgrind-'timestamp'.log)

-m Berichtsdurchsatz in 2**20 Byte/s (Standard: 10**6 Bit/s)

-n, --flows=#
Anzahl der Testflüsse (Standard: 1)

-o Vorhandene Protokolldateien überschreiben (Standard: nicht)

-p Geben Sie keine symbolischen Werte (wie INT_MAX) anstelle von Zahlen aus

-q, --ruhig
Seien Sie leise, loggen Sie sich nicht auf dem Bildschirm ein (Standard: Aus)

-s, --tcp-stack=TYP
Bestimmen Sie die Einheit der Quell-TCP-Stacks nicht automatisch. Einheit auf TYPE zwingen, wo
TYP ist „Segment“ oder „Byte“

-w Ausgabe in die Protokolldatei schreiben (dasselbe wie --Logdatei)

Flow Optionen
Alle Flüsse haben zwei Endpunkte, eine Quelle und ein Ziel. Die Unterscheidung zwischen Quelle
und Zielendpunkte wirken sich nur auf den Verbindungsaufbau aus. Beim Starten eines Flows wird der
Der Zielendpunkt lauscht an einem Socket und der Quellendpunkt stellt eine Verbindung zu ihm her. Für die
Im tatsächlichen Test macht dies keinen Unterschied, beide Endpunkte verfügen über genau die gleichen Fähigkeiten.
Daten können in beide Richtungen gesendet werden und viele Einstellungen können individuell konfiguriert werden
jeden Endpunkt.

Einige dieser Optionen verwenden den Flow-Endpunkt als Argument, der in der Option durch „x“ gekennzeichnet ist
Syntax. „x“ muss entweder durch „s“ für den Quellendpunkt oder „d“ für ersetzt werden
Zielendpunkt oder „b“ für beide Endpunkte. Um jeweils unterschiedliche Werte anzugeben
Endpunkte, trennen Sie sie durch Komma. Zum Beispiel -W s=8192,d=4096 legt die angekündigte fest
Fenster auf 8192 an der Quelle und 4096 am Ziel.

-A x Verwenden Sie die minimale Antwortgröße, die für die RTT-Berechnung erforderlich ist
(gleich wie -G s=p,C,40)

-B x=# Legen Sie den angeforderten Sendepuffer in Bytes fest

-C x Stoppen Sie den Fluss, wenn es zu einer lokalen Überlastung kommt

-D x=DSCP
DSCP-Wert für Type-of-Service (TOS) IP-Header-Byte

-E Zählen Sie Bytes in der Nutzlast auf, anstatt Nullen zu senden

-F #[,#] ...
Flow-Optionen, die dieser Option folgen, gelten nur für die angegebenen Flow-IDs. Nützlich in
Kombination mit -n um bestimmte Optionen für bestimmte Abläufe festzulegen. Die Nummerierung beginnt
mit 0, also -F 1 bezieht sich auf den zweiten Fluss. Mit -1 können alle Flüsse referenziert werden

-G x=(q|p|g) :(C|U|E|N|L|P|W):#1:[#2]
Aktivieren Sie die stochastische Verkehrsgenerierung und stellen Sie die Parameter entsprechend den verwendeten Parametern ein
Verteilung. Weitere Informationen finden Sie im Abschnitt „Option zur Traffic-Generierung“.

-H x=HOST[/STEUERN[:PORT]]
Test vom/zum HOST. Ein optionales Argument ist die Adresse und der Port für das CONTROL
Verbindung zum selben Host. Es wird davon ausgegangen, dass es sich um einen nicht angegebenen Endpunkt handelt
localhost

-J # Verwenden Sie eine zufällige Startnummer (Standard: read / Dev / urandom)

-I Aktivieren Sie die Berechnung der Einwegverzögerung (keine Taktsynchronisierung).

-L Rufen Sie connect() auf dem Test-Socket auf, unmittelbar bevor Sie mit dem Senden von Daten beginnen (spät).
verbinden). Wenn nicht angegeben, wird die Testverbindung in der Vorbereitung hergestellt
Phase vor Testbeginn

-M x Dump-Verkehr mit libpcap. Flowgrindd(1) muss als Root ausgeführt werden

-N Shutdown() jede Socket-Richtung nach dem Testablauf

-O x=OPT
Setzen Sie die Socket-Option OPT auf den Test-Socket. Weitere Informationen finden Sie im Abschnitt
'Socket-Optionen'

-P x Iterieren Sie nicht über select(), um mit dem Senden fortzufahren, falls dies bei der Blockgröße nicht der Fall war
reicht aus, um die Sendewarteschlange zu füllen (aufdringlich)

-Q Nur zusammenfassen, es werden keine Zwischenintervallberichte berechnet (ruhig)

-R x=#.#(z|k|M|G)(b|B)
Senden Sie mit der angegebenen Rate pro Sekunde, wobei: z = 2**0, k = 2**10, M = 2**20, G =
2**30 und b = Bits/s (Standard), B = Bytes/s

-S x=# Setzt die Blockgröße (Nachrichtengröße) in Bytes (dasselbe wie -G s=q,C,#)

-T x=#.#
Flussdauer einstellen, in Sekunden (Standard: s=10,d=0)

-U # Legen Sie die Größe des Anwendungspuffers in Bytes fest (Standard: 8192). Bei Verwendung mit werden Werte abgeschnitten
stochastische Verkehrserzeugung

-W x=# Legen Sie den angeforderten Empfängerpuffer (angekündigtes Fenster) in Bytes fest

-Y x=#.#
Legen Sie die anfängliche Verzögerung in Sekunden fest, bevor der Host mit dem Senden beginnt

DER VERKEHR GENERATION zur Auswahl

Per Option -G flowgrind unterstützt die stochastische Verkehrsgenerierung, die eine Durchführung ermöglicht
Neben normalen Massendatenübertragungen gibt es auch erweiterte ratenbegrenzte und Request-Response-Datenübertragungen.

Die Option zur stochastischen Verkehrsgenerierung -G nimmt den Flow-Endpunkt als Argument, bezeichnet
durch 'x' in der Optionssyntax. „x“ muss für die Quelle durch ein „s“ ersetzt werden
Endpunkt, „d“ für den Zielendpunkt oder „b“ für beide Endpunkte. Bitte beachten Sie jedoch
dass die Erzeugung bidirektionalen Datenverkehrs zu unerwarteten Ergebnissen führen kann. Anders zu spezifizieren
Geben Sie die Werte für jeden Endpunkt ein und trennen Sie sie durch Komma.

-G x=(q|p|g) :(C|U|E|N|L|P|W):#1:[#2]

Durchflussparameter:

q Anfragegröße (in Bytes)

p Antwortgröße (in Bytes)

g Lücke zwischen Paketen anfordern (in Sekunden)

Distributionen:

C konstant (#1: Wert, #2: nicht benutzt)

U Uniform (#1: Mindest, #2: max)

E exponentiell (#1: lamba – Lebenszeit, #2: nicht benutzt)

N normal (#1: mu - Mittelwert, #2: sigma_square - Varianz)

L lognormal (#1: zeta - bedeuten, #2: Sigma - Standard-Entwickler)

P Pareto (#1: k - Form, #2: x_min - Maßstab)

W Weibull (#1: Lambda - Skala, #2: k - Form)

Erweiterte Distributionen wie Weibull sind nur verfügbar, wenn Flowgrind kompiliert ist
mit libgsl-Unterstützung.

-U # Geben Sie bei Bedarf eine Obergrenze für die berechneten Werte für die Anforderungs- und Antwortgrößen an
weil die erweiterten verteilten Werte unbegrenzt sind, aber wir müssen die kennen
Puffergröße (wird für konstante Werte oder gleichmäßige Verteilung nicht benötigt). Werte
außerhalb der Grenzen werden neu berechnet, bis ein gültiges Ergebnis auftritt, höchstens jedoch 10
mal (dann wird der gebundene Wert verwendet)

STECKDOSE zur Auswahl

Flowgrind ermöglicht die Einstellung der folgenden Standard- und Nicht-Standard-Socket-Optionen über die Option
-O.

Alle Socket-Optionen verwenden den Flow-Endpunkt als Argument, der in der Option durch „x“ gekennzeichnet ist
Syntax. „x“ muss entweder durch „s“ für den Quellendpunkt oder „d“ für ersetzt werden
Zielendpunkt oder „b“ für beide Endpunkte. Um jeweils unterschiedliche Werte anzugeben
Endpunkte, trennen Sie sie durch Komma. Darüber hinaus ist es möglich, dasselbe wiederholt zu passieren
Endpunkt, um mehrere Socket-Optionen anzugeben.

Normen Buchse Optionen
-O x=TCP_CONGESTION=ALG
Stellen Sie den Überlastungskontrollalgorithmus ALG auf dem Test-Socket ein

-O x=TCP_CORK
Setzen Sie TCP_CORK auf den Test-Socket

-O x=TCP_NODELAY
Deaktivieren Sie den Nagle-Algorithmus am Test-Socket

-O x=SO_DEBUG
Setzen Sie SO_DEBUG auf den Test-Socket

-O x=IP_MTU_DISCOVER
Setzen Sie IP_MTU_DISCOVER auf den Test-Socket, falls dies nicht bereits standardmäßig im System aktiviert ist

-O x=ROUTE_RECORD
Setzen Sie ROUTE_RECORD auf den Test-Socket

Nicht-Standard Buchse Optionen
-O x=TCP_MTCP
Setzen Sie TCP_MTCP (15) auf den Test-Socket

-O x=TCP_ELCN
Setzen Sie TCP_ELCN (20) auf den Test-Socket

-O x=TCP_LCD
Setzen Sie TCP_LCD (21) auf den Test-Socket

Beispiele:

Fließmahlen
Testen der IPv4-TCP-Leistung von localhost mit Standardeinstellungen, genau wie flowgrind -H
b=127.0.0.1 -T s=10,d=0. Der Flowgrind-Daemon muss auf localhost ausgeführt werden

Fließmahlen -H b=::1/127.0.0.1
wie oben, aber Testen der IPv6-TCP-Leistung von localhost mit Standardeinstellungen

Fließmahlen -H s=host1,d=host2
Massen-TCP-Übertragung zwischen Host1 und Host2. Host1 fungiert als Quelle, Host2 als
Zielendpunkt. Auf beiden Endpunkten muss der Flowgrind-Daemon ausgeführt werden. Der
Es werden Standardflussoptionen mit einer Flussdauer von 10 Sekunden und einem Datenstrom verwendet
von Host1 nach Host2

Fließmahlen -H s=host1,d=host2 -T s=0,d=10
Dasselbe wie oben, aber stattdessen mit einem Fluss, der 10 Sekunden lang Daten von Host2 an sendet
host1

Fließmahlen -n 2 -F 0 -H s=192.168.0.1,d=192.168.0.69 -F 1 -H s=10.0.0.1,d=10.0.0.2
Richten Sie zwei parallele Flüsse ein, den ersten Fluss zwischen 192.168.0.1 und 192.168.0.69, den zweiten
Durchfluss zwischen 10.0.0.1 und 10.0.0.2

Fließmahlen -p -H s=10.0.0.100/192.168.1.100,d=10.0.0.101/192.168.1.101 -A s
Richten Sie einen Flow zwischen 10.0.0.100 und 10.0.0.101 ein und verwenden Sie die IP-Adressen 192.168.1.x
zur Verkehrssteuerung. Aktivieren Sie die minimale Reaktion für die RTT-Berechnung

Fließmahlen -i 0.001 -T s = 1 | egrep ^S | Gnuplot -fortdauern -e 'Handlung "-" Verwendung von 3:5 mit Linien
Titel „Durchsatz“ '
Richten Sie einen Flow über ein Loopback-Gerät ein und zeichnen Sie mithilfe der Hilfe die Daten des Absenders auf
von gnuplot

Fließmahlen -G s=q,C,400 -G s=p,N,2000,50 -G s=g,U,0.005,0.01 -U 32000
-G s=q,C,400: konstante Anforderungsgröße von 400 Bytes verwenden
-G s=p,N,2000,50: normalverteilte Antwortgröße mit durchschnittlich 2000 Bytes verwenden und
Varianz 50
-G s=g,U,0.005,0.01: Verwenden Sie eine gleichmäßig verteilte Lücke zwischen den Paketen mit mindestens 0.005 s und
und maximal 10 ms
-U 32000: Blockgrößen auf 32 KB kürzen (für Normalverteilung erforderlich)

DER VERKEHR SZENARIEN

Die folgenden Beispiele zeigen, wie die Fähigkeit von Flowgrind zur Traffic-Generierung sein kann
gebraucht. Diese sind in verschiedenen Tests zum Fließmahlen eingeflossen und haben sich bewährt
sinnvoll. Da der Internetverkehr jedoch vielfältig ist, gibt es keine Garantie dafür
in jeder Situation angemessen.

PREISANFRAGE (Request) Antwort Design (HTTP)
Dieses Szenario basiert auf der Arbeit in
http://www.3gpp2.org/Public_html/specs/C.R1002-0_v1.0_041221.pdf.

Fließmahlen -M s -G s=q,C,350 -G s=p,L,9055,115.17 -U 100000
-M s: Datenverkehr auf der Absenderseite entsorgen
-G s=q,C,350: Konstante Anforderungsgröße von 350 Bytes verwenden
-G s=p,L,9055,115: Lognormalverteilung mit Mittelwert 9055 und Varianz 115 verwenden für
Antwortgröße
-U 100000: Antwort auf 100 KB kürzen

Für dieses Szenario empfehlen wir, sich auf RTT (niedrigere Werte sind besser) und Netzwerk zu konzentrieren
Transaktionen/s als Metrik (höhere Werte sind besser).

Interaktiv Session (Telnet)
Dieses Szenario emuliert eine Telnet-Sitzung.

Fließmahlen -G s=q,U,40,10000 -G s=q,U,40,10000 -O b=TCP_NODELAY
-G s=q,U,40,10000 -G s=q,U,40,10000: einheitliche verteilte Anfrage und Antwort verwenden
Größe zwischen 40B und 10kB
-O b=TCP_NODELAY: Setzt die Socket-Optionen TCP_NODELAY, wie sie von Telnet-Anwendungen verwendet werden

Für dieses Szenario sind RTT (niedriger ist besser) und Netzwerktransaktionen/s nützliche Metriken
(höher ist besser).

Bewerten Limitiert (Streaming Medien)
Dieses Szenario emuliert eine Videostreamübertragung mit einer Bitrate von 800 kbit/s.

Fließmahlen -G s=q,C,800 -G s=g,N,0.008,0.001
Verwenden Sie eine normalverteilte Lücke zwischen Paketen mit einem Mittelwert von 0.008 und einer kleinen Varianz
(0.001). In Verbindung mit einer Anfragegröße von 800 Bytes ergibt sich eine durchschnittliche Bitrate von ca. 800
kbit/s wird erreicht. Die Varianz wird hinzugefügt, um eine variable Bitrate so zu emulieren, wie sie ist
Wird in heutigen Video-Codecs verwendet.

Für dieses Szenario gilt: IAT (niedriger ist besser) und minimaler Durchsatz (höher ist besser).
interessante Kennzahlen.

AUSGABE COLUMNS

Fluss/Endpunkt Identifikatoren
# Flow-Endpunkt, entweder „S“ für Quelle oder „D“ für Ziel

ID numerische Flusskennung

beginnen und Ende
Grenzen des Messintervalls in Sekunden. Die angezeigte Zeit ist die verstrichene Zeit
Zeit seit dem Empfang der RPC-Nachricht, um den Test vom Daemon-Punkt aus zu starten
view

Anwendung Schicht Metriken
bis
Übermittlung des Goodputs des Flussendpunkts während dieses Messintervalls,
gemessen in Mbit/s (Standard) oder MB/s (-m)

transac
Anzahl erfolgreich empfangener Antwortblöcke pro Sekunde (wir nennen es Netzwerk).
Transaktionen/n)

requ/bzw
Anzahl der während dieses Messintervalls gesendeten Anfrage- und Antwortblöcke (Spalte
standardmäßig deaktiviert)

IAT Block-Inter-Arrival-Time (IAT). Zusammen mit dem Minimum und Maximum
Das arithmetische Mittel für das jeweilige Messintervall wird angezeigt. Wenn kein Block vorhanden ist
Während des Berichtsintervalls empfangene Daten werden als „inf“ angezeigt.

DLY und RTT
1-Wege- und 2-Wege-Blockverzögerung bzw. Blocklatenz und Block-Roundtrip
Zeit (RTT). Für beide Verzögerungen gelten die dabei auftretenden minimalen und maximalen Werte
Messintervall werden zusammen mit dem arithmetischen Mittel angezeigt. Wenn kein Block vorhanden ist,
bzw. eine Blockbestätigung während dieses Berichtsintervalls eintrifft, ist „inf“.
angezeigt. Sowohl die 1-Wege- als auch die 2-Wege-Blockverzögerung sind standardmäßig deaktiviert (siehe
zu erhalten -I und -A).

Kernel Metriken (TCP_INFO)
Alle folgenden TCP-spezifischen Metriken werden vom Kernel über TCP_INFO abgerufen
Steckdosenoption am Ende jedes Berichtsintervalls. Die Abtastrate kann über geändert werden
zu erhalten -i.

cwnd (tcpi_cwnd)
Größe des TCP-Überlastungsfensters (CWND) in Anzahl der Segmente (Linux) oder Bytes
(FreeBSD)

ssth (tcpi_snd_sshtresh)
Größe des Slow-Start-Schwellenwerts in Anzahl der Segmente (Linux) oder Bytes (FreeBSD)

uack (tcpi_unacked)
Anzahl der derzeit nicht bestätigten Segmente, d. h. Anzahl der Segmente im Flug
(FlightSize) (nur Linux)

Sack (tcpi_sacked)
Anzahl selektiv bestätigter Segmente (nur Linux)

verloren (tcpi_lost)
Anzahl der vermutlich verloren gegangenen Segmente (nur Linux)

retr (tcpi_retrans)
Anzahl der unbestätigten erneut übertragenen Segmente (nur Linux)

tret (tcpi_retransmits)
Anzahl der Neuübertragungen, die durch ein Neuübertragungs-Timeout (RTO) ausgelöst werden (nur Linux)

fack (tcpi_fackets)
Anzahl der Segmente zwischen SND.UNA und der höchsten selektiv bestätigten Anzahl
Sequenznummer (SND.FACK) (nur Linux)

reor (tcpi_reordering)
Segment-Neuordnungsmetrik. Der Linux-Kernel kann Neuordnungen erkennen und damit umgehen
ohne nennenswerten Leistungsverlust, wenn die Distanz, um die ein Segment verschoben wird, zunimmt
die Neuordnungsmetrik nicht überschreiten (nur Linux)

rtt (tcpi_rtt) und rttvar (tcpi_rttvar)
TCP-Umlaufzeit und ihre Varianz in ms

rto (tcpi_rto)
das Zeitlimit für die erneute Übertragung, angegeben in ms

bkof (tcpi_backoff)
Anzahl der RTO-Backoffs (nur Linux)

ca Zustand (tcpi_ca_state)
Interner Zustand der TCP-Überlastungskontroll-Zustandsmaschine, wie in der implementiert
Linux Kernel. Kann einer von sein XNUMXh geöffnet, Störung, cwr, Erholung or Verlust (nur Linux)

Offen ist der Normalzustand. Es zeigt an, dass keine doppelte Bestätigung (ACK) vorliegt
empfangen und kein Segment gilt als verloren

Störung
wird beim Empfang des ersten aufeinanderfolgenden Duplikats von ACK oder eingegeben
selektive Quittierung (SACK)

CWR wird eingegeben, wenn eine Benachrichtigung von Explicit Congestion Notification (ECN)
Ist angekommen

Recovery
wird eingegeben, wenn drei doppelte ACKs oder eine entsprechende Anzahl von SACKs vorhanden sind
erhalten. In diesem Zustand gibt es Verfahren zur Kontrolle von Überlastungen und zur Wiederherstellung von Verlusten
Fast Retransmit und Fast Recovery (RFC 5861) werden ausgeführt

Verlust wird eingetragen, wenn das RTO abläuft. Erneut Staukontrolle und Verlustbeseitigung
Prozeduren werden ausgeführt

SMS und pmtu
Maximale Segmentgröße des Absenders und maximale Übertragungseinheit des Pfads in Bytes

Intern Fließmahlen Zustand (nur freigegeben in debuggen baut)
Status Zustand der Strömung im Fließmahlwerk zu Diagnosezwecken. Es ist ein Tupel aus zwei
Werte, der erste zum Senden und der zweite zum Empfangen. Idealerweise die Staaten von
Sowohl der Quell- als auch der Zielendpunkt eines Flusses sollten jedoch symmetrisch sein
Sie sind nicht synchronisiert und dürfen sich nicht gleichzeitig ändern. Die möglichen Werte
sind:

c Richtung hat das Senden/Empfangen abgeschlossen

d Warten auf die anfängliche Verzögerung

f Fehlerzustand

l Aktiver Zustand, es wurde noch nichts gesendet oder empfangen

n Normale Aktivität, einige Daten wurden gesendet oder empfangen

o Der Fluss hat in dieser Richtung keine Dauer, es werden keine Daten ausgetauscht

AUTOREN

Flowgrind wurde ursprünglich von Daniel Schaffrath gegründet. Die verteilte Messung
Architektur und fortschrittliche Verkehrsgenerierung wurden später von Tim Kosse und hinzugefügt
Christian Samsel. Derzeit wird Flowgrind von Arnd Hannemann entwickelt und gepflegt
Alexander Zimmermann.

Nutzen Sie Flowgrind online über die Dienste von onworks.net