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 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 .

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..

[Fuerchau]

Kannst du uns auch mitteilen welche Regel und wo diese definiert wurde?
Meistens hat das mit ADMIN's weniger zu tun sondern der Durchsatz für alle Beteiligten im Netz soll gleich gut oder schlecht laufen.
Bei 10MB kann das ja noch gut gehen, wenn die Regel weg ist. Kopierst du aber mal 10GB oder mehr kann das gesamte Netz darunter leiden.
Ins besonders die 5250-Terminals können sich ggf. sogar verabschieden wenn keine Daten übertragen werden können und die AS/400 glaubt, dass die Terminals weg sind (Disconnected/beendete Job's).
Das kann beim Arbeiten lästig werden.

[MGJ79]

Diese Regeln wurden auf unserer SonicWall defniert. Hier hat ausschließlich unsere Netzwerktruppe zugang...Leider für uns eine BlackBox, nachdem die öfter mit diesen Regeln Jonglieren bleibt an dieser Stelle ein immer währendes offenes schwarzes Loch.