Performance Netzwerk, IFS

[MGJ79]

Hallo Zusammen,

wir haben V6R1M1 auf einer P720 laufen.
Wenn ich eine Datei über unsere ESX-Server (Win2008) auf die Iseries kopiere habe ich einen Durchsatz von 3~4Mb/sek. Was daran liegt dass wir wohl direkt über die FC-Switches laufen.

Wenn ich jedoch über mein WindowsNetzwerk Dateien ins IFS kopiere habe ich gerade mal lahme 250-400Kb/s. Jetzt kommt der Gag. Wenn ich direkt im Serverraum den Laptop anschließe und nur noch über diesen Switch gehe habe ich trotzdem nur 250-400Kb/s??
D.h. Infratrukturprobleme sind da schonmal ausgehebellt.

Ist das Normal? Mir kommt das doch sehr arg mager vor...

Grüße


Hier mal unsere Leitungsbeschreibung


Ressourcen name . . . . . . . . . : CMN03
Bei IPL anhängen . . . . . . . . . : *YES
Wartezeit bei Anhängen . . . . . . : *NOWAIT
Netzwerksteuereinheit . . . . . . : ETHLINET
Ethernet-Standard . . . . . . . . : *ALL
Übertragungsgeschwindigkeit . . . : 1G
Aktuelle Übertragungsgeschw. . . . : 1G
Duplex . . . . . . . . . . . . . . : *FULL
Aktueller Duplexwert . . . . . . . : *FULL
Serviceoptionen . . . . . . . . . : *NONE
Maximale Rahmengröße . . . . . . . : 1496
Max. Anzahl Steuereinheiten . . . : 40
Fehlerschwelle . . . . . . . . . . : *OFF
Testrahmen generieren . . . . . . : *YES
Nachricht- warteschl. . . . . . . : *SYSVAL
Akt. Nachrichtenwarteschlange . . : QSYSOPR
Bibliothek . . . . . . . . . . . : QSYS
Text . . . . . . . . . . . . . . . : Ethernet Leitung 1





MGJ79

[Fuerchau]

Ggf. gibt es QoS-Regeln (Quality of Service), die den Datentransfer beschränken um die Bandbreite besser gleichmäßig zu verteilen.

[MGJ79]

Der Antwort zu schließen sind die 400Kb/s schon ziemlich mager. Was wäre denn als "Normaldurchschitt" zu betrachten?
QoS-Regeln liegen meiner Meinung nach aber dann nicht auf der AS400 vor sondern werden von der "Netzwerktruppe" bestimmt oder?

[Fuerchau]

Die Frage ist auch, ob der Switch so intelligent ist und nicht immer über den Router geht obwohl die beiden Anschlüsse ja direkt nebeneinander liegen.
Ich habe in meinem WLAN ähnliche Probleme gehabt, bis ich den richtigen Switch fand, der z.B. meinen PC direkt mit meiner Netzwerkplatte verband und nicht erst über WLAN mit dem Router kommunizierte.
Dies senkt nicht nur die Datenlast sondern steigert eben auch die Geschwindigkeit.
Ich weiß nicht, ob es z.B. für TRACERT auf dem PC, TRACEROUTE auf der AS/400 eine Alternative gibt, die auch die Switches auf dem weg mit aufzeigt.
Aber versuche trotzdem mal den TRACERT auf dem PC für die Weg-Analyse.

[holgerscherer]

Ist das Normal? Mir kommt das doch sehr arg mager vor...


Das ist schon Magersucht... Kabel geprüft? Switchkonfig? Wie sieht CHGTCPA aus?

[angelone]

Ich würd so Durchsatzsachen vor allem eher mit FTP testen
Wenn FTP viel schneller ist, dann ists irgend ein dubioses QoS oder Windows Problem

[MGJ79]

Leider genauso langsam:


ftp> get heapdump.20131220.082155.267227.0008.phd
200 PORT subcommand request successful.
150 Retrieving file /home/LIPSUM/heapdump.20131220.082155.267227.0008.phd
226 File transfer completed successfully.
FTP: 10215834 Bytes empfangen in 65,99Sekunden 154,82KB/s
ftp>



Warum sind QoS Regeln auf ein Protokoll (FTP) beschränkt??

>>> Kann ggf. ein Neustart des Interfac eth0 was bringen??

[MGJ79]

@Holger Scherer. CHGTCPA von der Mager400 :D schaut so aus


TCP Keep Alive . . . . . . . . . TCPKEEPALV 120
TCP-Dringlichkeitszeiger . . . . TCPURGPTR *BSD
Größe d. Empfangspuffers (TCP) TCPRCVBUF 8192
Größe des Sendepuffers (TCP) . . TCPSNDBUF 8192
TCP-R1-Wiederholungszähler . . . TCPR1CNT 3
TCP-R2-Wiederholungszähler . . . TCPR2CNT 16
Min. vor TCP-Neuübertragung . . TCPMINRTM 250
TCP-Wartezeitlimit . . . . . . . TCPCLOTIMO 120
TCP-Verbindungsende-Nachricht . TCPCNNMSG *THRESHOLD
UDP-Kontrollsumme . . . . . . . UDPCKS *YES
MTU-Pfaderkennung: IPPATHMTU
Aktivierung . . . . . . . . . *YES
Intervall . . . . . . . . . . 10
IP-Datagrammweiterleitung . . . IPDTGFWD *YES
IP-Quellenweiterleitung . . . . IPSRCRTG *YES
Zeitüberschr. bei IP-Neuaufbau IPRSBTIMO 10
IP Time to Live (Hop-Limit) . . IPTTL 64
IP-QoS-Aktivierung . . . . . . . IPQOSENB *NO
Inaktiver IP-Gateway: IPDEADGATE
Aktivierung . . . . . . . . . *YES
Intervall . . . . . . . . . . 2
Zeitüberschreit. bei ARP-Cache ARPTIMO 15
ECN aktivieren . . . . . . . . . ECN *NO
Netzwerkdatei-Cache: NFC
Aktivierung . . . . . . . . . *YES
Zeitlimit für Datei im Cache 300
Cache-Größe . . . . . . . . . 10
Protokollfehler protokollieren LOGPCLERR *NO
Blockgrenze ICMPv6-Fehlernach. IP6ERRLMT 10
Senderate ICMPv6-Fehlernachr. . IP6ERRRATE 10
IPv6 Hop-Limit . . . . . . . . . IP6HOPLMT 64
Lastvert. dopp. IPv6-Leitweg . . IP6DUPRTLS *RTR
Gültigkeit der temp. IPv6-Adr. IP6TMPAVL 7,0
Bevorzugung temp. IPv6-Adr. . . IP6TMPAPL 1,0



Update: Hab grad das Kabel geprüft..da war ein "Haxerl" draussen.Jetzt ist es mir klar warum die Leistung nicht da war..

[holgerscherer]

Update: Hab grad das Kabel geprüft..da war ein "Haxerl" draussen.Jetzt ist es mir klar warum die Leistung nicht da war..

Watt iss dann ein "Haxerl"? Ich kenn ja nur "Haxn" und "Hackl" ;-)

Kabel können böse sein - Link da, Verbindung da, Rate mies...

Übrigens, setz im CHGTCPA mal

Größe d. Empfangspuffers (TCP) TCPRCVBUF 65536
Größe des Sendepuffers (TCP) . . TCPSNDBUF 65536

[MGJ79]

Sorry für die späte Übersetzung ;-)
Haxerl ist quasi ein Fuß also der RJ45 wie der Techniker unter uns sagen würde.

Buffersize wurde geändert, Danke für den Tipp.

Es hat sich herrausgestellt dass hier eine Firewallregel uns As400 Admins beeinträchtigt.
Was total sinnvoll ist :o.

Danke @All

edit: Lt. Auskunft gibt es übrigens kein TC/IP Protokoll über FiberChannel.Dh. die Ursprüngliche Annahme dass das Zeug über den FC läuft war falsch..