• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

APU4b4: Die MTU ist schuld! Schon wieder... diesmal aber anders rum.

SierraX

Well-Known Member
Themenstarter #1
In einem etwas älteren Thread wo ich über die "Erste Erfahrungen mit der APU4b4" geschrieben hatte, kam die Frage wegen der Netzwerk Geschwindigkeit auf.
Ich fand sie (bei einem OpenBSD-6.3 current) relativ enttäuschend, weil ich das ganze zu dem Zeitpunkt nur in die nähe von 450MBit/s beim iPerf3 zwischen 2 der APUs gekriegt habe.
Hatte aber eine Weile keine Lust mich nochmal mit dem Thema zu beschäftigen.
Heute hat mich dann der Rappel gepackt und da ich mit nem Mac als iPerf3 Client jenseits der 900MBits erreicht hatte dacht ich mir heut abend... "guck dich nochmal im internet um das kann doch nicht angehen".
Ich bin im pcengines forum auf einen Thread gestossen wo die Frage gestellt wurde, ob es irgendwelche Nachteile gäbe die MTU bei einer APU2c4 dauerhaft auf 9000 zu stellen, der Begriff Jumboframes ist dafür gefallen, damit man wenigstens annähernd an das eine GBit /s kommt.
Ich hab es jetzt mal temporär auf die maximalen 9216 o_0 ein zu stellen und hatte bei iperf3 (mit disableten pf's) ein Ergebnis von bis zu 930Mbit/s.

Ich hab mir den Thread noch nicht ganz durchgelesen, kenne also noch nicht das Fazit ob es jetzt gut oder schlecht ist.
 

Anhänge

mark05

Well-Known Member
#2
hi

also grosse MTU funktioniert nur dann wenn alle beteiligten devices sie eingestellt haben , und dann auch gleiche size .
d.h. client , switch , server , router , firewall .

jetzt muss man auch daran denken das eine firewall die grossen datenpakete verarbeiten ( paketfilter , routing , ggf ids/ids )
muss was cpu intensiv ist, wenn du das dann hochrechnest auf viele verbindung ist eine firewall schnell am schwitzen.

daüberhinaus wird es dann schwirig wen ein client mit nicht grosser mtu mit einem server über die fw redet mit grosser mtu,

hier kann es zu fragmentierung kommen bzw eine ellenlange mtu discovery aushandlung , bis sie sich korrekt unterhalten
können.

grosse mtu nutze ich z.b. bei iscsi wo der netzwerk strang klar ist , von anfang bis ende.


holger
 

SierraX

Well-Known Member
Themenstarter #3
Da taucht bei mir natürlich die Frage auf: Afaik behaupten die meisten anderen Betriebssysteme, sie hätten eine MTU von 1500, kriegen die Geschwindigkeiten von 1Gbit/s aber hin.
Das lässt eigentlich 2 Schlüsse zu: Entweder die anderen lügen und schicken Jumboframes wenn das Ziel sie verträgt obwohl ein Standard von 1500 eingetragen ist. Oder sie schaffen es 2-3x mehr Pakete in der Sekunde zu schicken als OpenBSD es mit einer I21{0,1}AT kann.
 

mr44er

Well-Known Member
#4
Die lügen nicht. ;)
Meine Tests mit iperf3 geben mir auch mit MTU 1500 oder genauen 9000 unterschiedliche Werte je nach Lust. Als ich dann wieder zurück auf 1500 war und zfs send über nc gefahren hab, hats die GBIT-Leitung dennoch voll ausgelastet.
 

SierraX

Well-Known Member
Themenstarter #6
Übertragung einer 1200MByte grossen Datei via nc die gleich nach /dev/null umgeleitet wurde... mit ~34MByte/s zeugt es nicht gerade von adäquater Geschwindigkeit. So gerne ich OpenBSD mag und auch noch weiter benutzen werde...
Als router/firewall auf APU2/3/4 ist es z.Z. offenbar nur sehr bedingt geeignet.
 

mark05

Well-Known Member
#8
hi

du kopierst auf die apu ?

das ist punkt zu punkt , und damit misst du keine firewall / routing leistung.

hier gilt Rechner A aus Netz A kopiert zu Rechner B Netz B , verbunden sind die netze via der APU.

holger
 

SierraX

Well-Known Member
Themenstarter #9
Das ist mir klar.
Aber wenn PP also Router zu Router schon so niedrig ist (33% der Nennleistung bei eingeschaltetem pf, 45% der Nennleistung bei ausgeschaltetem pf), wird es durch zwei zwischen geschalteten Router bestimmt auch nicht besser.
Anyway...
Das zu testen würde gerade einen massiven Umbau meines Test Aufbaus benötigen... den ich z.Z. nicht bringen möchte.
 

mark05

Well-Known Member
#10
Du halt bedenken daß du durch deine Art zu testen auch erhebliche Io produziert für die ein Router/Firewall System nicht optimiert ist, z.b. Festplatten Io

Holger
 

SierraX

Well-Known Member
Themenstarter #11
Du halt bedenken daß du durch deine Art zu testen auch erhebliche Io produziert für die ein Router/Firewall System nicht optimiert ist, z.b. Festplatten Io
Das kann ich bei Gelegenheit mal prüfen... glaube aber ehrlich gesagt nicht, das wenn der Eingang nach /dev/null geleitet wird und keine weiteren Netzwerk Geräte angeschlossen sind (steuerung via com0) viel mit Platten IO ist.
 

TCM

Well-Known Member
#12
Trotzdem ist "Routen" lastmäßig was völlig Anderes als "lokal zustellen und damit erstmal noch sonstwas im Kernel machen".

Schon wenn das Paket an den Router per IP adressiert ist und er es auf weitere Protokolle auseinanderpflückt und dann noch einen Socket bedient und Daten annimmt, hast du x-fach mehr Codepfade durchlaufen, als wenn er es einfach weiterroutet.
 

mapet

Active OpenBSD User
#13
Die Bandbreite ist abhängig von der Anzahl Pakete pro Sekunde, die Netzwerkkarte und Treiber verarbeiten können. Man geht meistens von der kleinsten Paketgröße aus. Der Artikel hilft vielleicht weiter: https://kb.juniper.net/InfoCenter/index?page=content&id=kb14737 Jumboframes kann man im eigenen LAN fahren, bspw. bei Datenbank- oder Fileservern. Aber auf eine Firewall bzw. nach extern sollte man das tunlichst lassen. Dank PPPoE sinkt die MTU des externen Interface meistens auf 1492 und man muss die Maximum Segment Size meist noch niedriger setzen, um überhaupt auf https Seiten zugreifen zu können bzw. performante Verbindungen ohne retransmits zu bekommen.
 

SierraX

Well-Known Member
Themenstarter #14
Trotzdem ist "Routen" lastmäßig was völlig Anderes als "lokal zustellen und damit erstmal noch sonstwas im Kernel machen".

Schon wenn das Paket an den Router per IP adressiert ist und er es auf weitere Protokolle auseinanderpflückt und dann noch einen Socket bedient und Daten annimmt, hast du x-fach mehr Codepfade durchlaufen, als wenn er es einfach weiterroutet.
Seh ich ein...
Leider sind die ersten Versuche ein anderes BSD auf zu spielen (NetBSD 8.0), um zu schauen ob das was ändert, wegen der Fixen com0 Port Geschwindigkeit von 115200 Baud bei der APU und einer nicht so einfach veränderbaren Geschwindigkeit von 9600 Baud in der boot-conf , gescheitert.
für einen Routing test wie beschrieben hab ich leider keine Zeit bis zum WE
 

roema

Well-Known Member
#15
Ich habe sehr viele APUs im Einsatz unter anderem eine mit OPNSense. Vor einiger Zeit habe ich ein paar Tests gemacht um zu sehen wie der Durchsatz WAN -> LAN aussieht. Ich muss die Egebnise suchen, glaube aber mich zu erinnern, dass es rund 850 MBit waren.

Die MTU habe ich dabei sicher nicht angepasst.
 

foxit

Moderator
Mitarbeiter
#16
Ich hatte gestern mal noch kurz Zeit und habe das hier gemessen: [NAS] == [APU2] == [NUC]. Iperf3 als Beispiel (60 Sekunden):
Code:
[  5]   1.00-2.00   sec  73.0 MBytes   612 Mbits/sec
[  5]   2.00-3.00   sec  69.3 MBytes   581 Mbits/sec
[  5]   3.00-4.00   sec  70.6 MBytes   592 Mbits/sec
[  5]   4.00-5.00   sec  68.9 MBytes   578 Mbits/sec
[  5]   5.00-6.00   sec  71.2 MBytes   598 Mbits/sec
[  5]   6.00-7.00   sec  69.4 MBytes   582 Mbits/sec
[  5]   7.00-8.00   sec  70.1 MBytes   588 Mbits/sec
[  5]   8.00-9.00   sec  69.3 MBytes   581 Mbits/sec
[  5]   9.00-10.00  sec  71.3 MBytes   598 Mbits/sec
[  5]  10.00-11.00  sec  69.7 MBytes   584 Mbits/sec
...
...
...
[  5]  51.00-52.00  sec  73.6 MBytes   618 Mbits/sec
[  5]  52.00-53.00  sec  72.2 MBytes   606 Mbits/sec
[  5]  53.00-54.00  sec  73.1 MBytes   613 Mbits/sec
[  5]  54.00-55.00  sec  72.7 MBytes   610 Mbits/sec
[  5]  55.00-56.00  sec  75.7 MBytes   635 Mbits/sec
[  5]  56.00-57.00  sec  72.9 MBytes   612 Mbits/sec
[  5]  57.00-58.00  sec  74.7 MBytes   626 Mbits/sec
[  5]  58.00-59.00  sec  74.3 MBytes   623 Mbits/sec
[  5]  59.00-60.00  sec  74.7 MBytes   627 Mbits/sec
CPU Auslastung:
Code:
  1  [||||||||||||||||||||||                                           30.4%]   Tasks: 16, 0 thr; 2 running
  2  [|||||||||||||||||||||||||||||||||||||||||                        56.0%]   Load average: 2.78 1.14 0.60
  3  [|||||||||||||||||||||||||||                                      36.6%]   Uptime: 7 days, 00:06:54
  4  [|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||99.0%]
  Mem[||||||||||||||||||||||||||||||||||||||||||||||              667M/3.95G]
  Swp[                                                              0K/2.00G]
Ich halte diese Werte für realistisch, da ich z.B. auch von Steam Downloads mit einem Speed von fast 60 MB/s [WAN Interface] fahren kann.
 

SierraX

Well-Known Member
Themenstarter #17
@roema : OPNSense und pfSense stehen bei mir auch noch auf dem testplan Plan. Aber erst nachdem ich pf beherrsche

@foxit : Da wären jetzt wieder die OS's der Komponenten Interessant ... OpenBSD 6.4 beta auf der APU2?
 

SierraX

Well-Known Member
Themenstarter #20
@mark05 Wenns darum geht zu lernen wie man pf bedient, eine pf.conf schreibt etc. geb ich dir recht. pfSense und OPNSense haben aber Kunden im Einsatz und solange es kein annähernd so gutes Webfrontend auf OpenBSD gibt, wird sich "Wenn pf dann nur OpenBSD" aus der Nerd Nische kaum befreien können.
 

mapet

Active OpenBSD User
#23
@mark05 Wenns darum geht zu lernen wie man pf bedient, eine pf.conf schreibt etc. geb ich dir recht. pfSense und OPNSense haben aber Kunden im Einsatz und solange es kein annähernd so gutes Webfrontend auf OpenBSD gibt, wird sich "Wenn pf dann nur OpenBSD" aus der Nerd Nische kaum befreien können.
Falls die Kunden ein Webfrontend brauchen, sollten sie lieber jemanden beauftragen, ihre Regeln zu schreiben ;). Dafür gibt es Supportverträge.
 

mark05

Well-Known Member
#24
hi

Kunden die ein Webfrontend brauchen , sollten die Finger von Firewalls und aehnlichen
Geräten lassen.

selbst die Oberklasse an Firewalls , Adminnistrist du per CLI.

Trotz Centralen Management System und webgui.


PF ist so Logisch klar das du keine GUI brauchst.

Holger