expertenaustausch > comm.* > comm.protocols.tcp-ip

Marc Haber (08.04.2019, 08:45)
So, dann wollen wir mal schauen, ob hier noch jemand lebt.

Ich habe zwei hinreichend starke Linux-Rechner mit e1000e
Netzwerkinterfaces, die ich mit iperf3 so weit wie möglich auslasten
möchte.

Ich habe also in auf beiden Systemen ein iperf3 --server und ein
iperf3 --client <andereseite> --udp --bitrate 0 --time 1800
ausgeführt. Dabei komme ich auf ~ 940 Mbit/s Datenrate, habe aber auch
~ 0.2 % Packet loss.

Entspricht das (Datenrate deutlich unter den erreichbaren 1000 Mbit/s,
meßbarer Packetloss) den Erwartungen oder ist da was kaputt?

Grüße
Marc
Ulli Horlacher (08.04.2019, 13:08)
Marc Haber <mh+usenetspam1118> wrote:

> Ich habe zwei hinreichend starke Linux-Rechner mit e1000e
> Netzwerkinterfaces, die ich mit iperf3 so weit wie möglich auslasten
> möchte.


Mit welchem Motiv?
Eventuell benutzt du nur das falsche Werkzeug...
Marc Haber (08.04.2019, 15:35)
Ulli Horlacher <framstag> wrote:
>Marc Haber <mh+usenetspam1118> wrote:
>> Ich habe zwei hinreichend starke Linux-Rechner mit e1000e
>> Netzwerkinterfaces, die ich mit iperf3 so weit wie möglich auslasten
>> möchte.

>Mit welchem Motiv?


Kabeltests. Ich möchte später durch Einstrahlung ins das Kabel
CRC-Fehler erzeugen, und die sehe ich nur, wenn zu dem Zeitpunkt auch
wirklich Daten auf dem Kabel waren. Und wenn ich schon auf der
unbelasteten Verbindung so viele Fehler sehe, taugt das nicht.

Grüße
Marc
Bonita Montero (08.04.2019, 17:12)
> Kabeltests. Ich möchte später durch Einstrahlung ins das Kabel
> CRC-Fehler erzeugen, und die sehe ich nur, wenn zu dem Zeitpunkt
> auch wirklich Daten auf dem Kabel waren. Und wenn ich schon auf
> der unbelasteten Verbindung so viele Fehler sehe, taugt das nicht.


Ne Datei übertragen zwischen den Rechner und dann ...
"netstat -s | grep -i retrans"
.... machen ist keine Lösung?
Marc Haber (08.04.2019, 19:11)
Bonita Montero <Bonita.Montero> wrote:
>Ne Datei übertragen zwischen den Rechner und dann ...
> "netstat -s | grep -i retrans"
>... machen ist keine Lösung?


Das ist in erster Näherung zu einfach. Man will halt wissen, ob es
besser geht.
Frank Graf (08.04.2019, 19:39)
Am Mon, 08 Apr 2019 08:45:22 +0200 schrieb Marc Haber:

> So, dann wollen wir mal schauen, ob hier noch jemand lebt.
> Ich habe zwei hinreichend starke Linux-Rechner mit e1000e
> Netzwerkinterfaces, die ich mit iperf3 so weit wie möglich auslasten
> möchte.
> Ich habe also in auf beiden Systemen ein iperf3 --server und ein iperf3
> --client <andereseite> --udp --bitrate 0 --time 1800 ausgeführt. Dabei
> komme ich auf ~ 940 Mbit/s Datenrate, habe aber auch ~ 0.2 % Packet
> loss.
> Entspricht das (Datenrate deutlich unter den erreichbaren 1000 Mbit/s,
> meßbarer Packetloss) den Erwartungen oder ist da was kaputt?


Eben hier ausprobiert:

iperf3 --client 192.168.1.208 --udp --bitrate 0 --time 30
Connecting to host 192.168.1.208, port 5201
[ 5] local 192.168.1.212 port 44119 connected to 192.168.1.208 port 5201
[ ID] Interval Transfer Bitrate Total Datagrams
[ 5] 0.00-1.00 sec 114 MBytes 957 Mbits/sec 83040
[ 5] 1.00-2.00 sec 114 MBytes 956 Mbits/sec 83000
......
[ 5] 29.00-30.00 sec 114 MBytes 956 Mbits/sec 82990
- - - - - - - - - - - - - - - - - - - - - - - - -
Interval Transfer Bitrate Jitter Lost/Total Datagrams
0.00-30.00 sec 3.34 GBytes 956 Mbits/sec 0.000 ms 0/2489820 (0%) sender
0.00-30.04 sec 3.34 GBytes 955 Mbits/sec 0.019 ms 74/2489806 (0.003%)
receiver

Server: FreeBSD mit: 82567LM-3 Gigabit Network Connection
Client: Linux mit: RTL8111/8168/8411 PCI Express Gigabit Ethernet

Switch: HP ProCurve 1400-8G

Frank
Friedemann Stoyan (08.04.2019, 21:11)
Marc Haber wrote:

> Ich habe also in auf beiden Systemen ein iperf3 --server und ein
> iperf3 --client <andereseite> --udp --bitrate 0 --time 1800
> ausgeführt. Dabei komme ich auf ~ 940 Mbit/s Datenrate, habe aber auch
> ~ 0.2 % Packet loss.


> Entspricht das (Datenrate deutlich unter den erreichbaren 1000 Mbit/s,
> meßbarer Packetloss) den Erwartungen oder ist da was kaputt?


Auch mal schnell hier probiert:

[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-893.00 sec 103 GBytes 989 Mbits/sec 0.081 ms 7/13474408 (5.2e-05%) receiver

Im Vergleich der Werte, erscheint mir Dein Packetloss etwas hoch.

mfg Friedemann
Ulli Horlacher (09.04.2019, 00:13)
Marc Haber <mh+usenetspam1118> wrote:

> Kabeltests. Ich möchte später durch Einstrahlung ins das Kabel
> CRC-Fehler erzeugen, und die sehe ich nur, wenn zu dem Zeitpunkt auch
> wirklich Daten auf dem Kabel waren. Und wenn ich schon auf der
> unbelasteten Verbindung so viele Fehler sehe, taugt das nicht.


Achso, deshalb udp, weil tcp ja selbststaendig verlorene Pakete erneut
verschickt.
Ich hatte (falsch) vermutet, es geht dir um reinen Durchsatztest.
Marc Haber (10.04.2019, 09:42)
Ulli Horlacher <framstag> wrote:
>Marc Haber <mh+usenetspam1118> wrote:
>Achso, deshalb udp, weil tcp ja selbststaendig verlorene Pakete erneut
>verschickt.


tcp ist zu gutmütig und tritt bei Störungen zu weit zurück.

Grüße
Marc
Ralph Aichinger (10.04.2019, 10:18)
Marc Haber <mh+usenetspam1118> wrote:
> tcp ist zu gutmütig und tritt bei Störungen zu weit zurück.


Wie wäre es mit UDP-Paketen in einem definierten Zeitlichen Abstand,
z.B. 100ms zwischen den Paketen, ohne Sender, Empfänger und Puffer irgendwo
in die Sättigung zu treiben?

/ralph
Marc Haber (11.04.2019, 08:38)
Ralph Aichinger <ra> wrote:
>Marc Haber <mh+usenetspam1118> wrote:
>> tcp ist zu gutmütig und tritt bei Störungen zu weit zurück.

>Wie wäre es mit UDP-Paketen in einem definierten Zeitlichen Abstand,
>z.B. 100ms zwischen den Paketen, ohne Sender, Empfänger und Puffer irgendwo
>in die Sättigung zu treiben?


Ich hatte eigentlich gehofft mit einem Standardtool auszukommen, bzw.
iperf3 entsprechend parametrieren zu können.

Und 100 ms Pause ist wohl viel zu lang.

Grüße
Marc
Marc Haber (11.04.2019, 08:38)
Frank Graf <f.graf> wrote:
[..]
>Server: FreeBSD mit: 82567LM-3 Gigabit Network Connection
>Client: Linux mit: RTL8111/8168/8411 PCI Express Gigabit Ethernet
>Switch: HP ProCurve 1400-8G


Must, dann muss ich mein Setup wohl nochmal genauer anschauen.

Grüße
Marc
Ralph Aichinger (11.04.2019, 09:31)
Marc Haber <mh+usenetspam1118> wrote:
> Und 100 ms Pause ist wohl viel zu lang.


War so als Hausnummer für "kann man mit einem Shellskript
noch auf jeden Fall abdecken" gedacht.

/ralph
Thomas Hochstein (14.04.2019, 10:35)
Marc Haber schrieb:

> Must, dann muss ich mein Setup wohl nochmal genauer anschauen.


Oder das Kabel, mit dem Du testest, ist bereits nicht in Ordnung ...
Marc Haber (14.04.2019, 16:05)
Thomas Hochstein <thh> wrote:
>Marc Haber schrieb:
>> Must, dann muss ich mein Setup wohl nochmal genauer anschauen.

>Oder das Kabel, mit dem Du testest, ist bereits nicht in Ordnung ...


Freilich nicht, das wurde getestet. Ich bin ja nicht auf der
Brennsuppn dahergeschwommen ;-)

Grüße
Marc

Ähnliche Themen