Dave, I've been working on a TCP session monitor. It reports MB/Second + changes to the TCP parameters, such as change in window size, buffer size etc. all of which affect throughput.
I can let you have a copy of the program if you are interested. [email protected] it reports //SYSPRINT Using --PORT 22 --SLEEP 10 --COUNT 10 --TCPIP TCPIP HH:MM:SS,remote ,BytesI,BytesO,,SegsI , SegsO,,BI/Sec,BO/Sec,,ReXmtC, 08:33:23,10.1.0.2:41984 , 0, 0,, 0, 0,, 0, 0,, 0, 08:33:23,10.1.0.2:55554 , 676, 45832,, 54, 63,, 67, 4583,, 0, 08:33:33,10.1.0.2:41984 , 0, 0,, 0, 0,, 0, 0,, 0, 08:33:33,10.1.0.2:55554 , 52, 27452,, 15, 28,, 5, 2745,, 0, 08:33:43,10.1.0.2:55554 , 0, 0,, 0, 0,, 0, 0,, 0, Freeing entry 10.1.0.2:41984 08:33:53,10.1.0.2:37728 , 156, 1164,, 14, 11,, 15, 116,, 0, 08:33:53,10.1.0.2:55554 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:04,10.1.0.2:37728 , 416, 71932,, 50, 77,, 37, 6539,, 0, 08:34:04,10.1.0.2:55554 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:14,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:14,10.1.0.2:55554 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:24,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:24,10.1.0.2:55554 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:34,10.1.0.2:37728 , 0, 0,, 0, 0,, 0, 0,, 0, 08:34:34,10.1.0.2:55554 , 0, 0,, 0, 0,, 0, 0,, 0, The first time the program sees a connection it dumps out 10.1.0.2:41984 JOBNAME SSHD4 Interface TAP0 10.1.0.2:41984 ResourceId: 45 InSegs: 37 OutSegs: 31 SSThresh: 65535 10.1.0.2:41984 OutBuffered: 0 InBuffered: 0 10.1.0.2:41984 ReXmtCount: 0 CongestionWnd: 41760 RoundTripTime: 4 RoundTripVar: 11 10.1.0.2:41984 SndBufSize: 65536 SndWnd: 64128 MaxSndWnd: 64256 SendMSS: 1452 10.1.0.2:41984 RcvBufSize: 65536 RcvWnd:131020 Lcl0WindowCount: 0 Rmt0WindowCount: 0 10.1.0.2:41984 If TCPIP parameters change, such as window size you get in //CHANGE 08:33:23 10.1.0.2:55554 NWMConnRoundTripTime n:2 - o:4 = -2 08:33:23 10.1.0.2:55554 NWMConnRoundTripVar n:2 - o:7 = -5 08:33:33 10.1.0.2:55554 NWMConnRoundTripTime n:3 - o:2 = 1 08:33:33 10.1.0.2:55554 NWMConnRoundTripVar n:3 - o:2 = 1 08:33:53 10.1.0.2:37728 NWMConnCongestionWnd n:36000 - o:20160 = 15840 08:33:53 10.1.0.2:37728 NWMConnRoundTripTime n:6 - o:10 = -4 08:33:53 10.1.0.2:37728 NWMConnRoundTripVar n:17 - o:29 = -12 08:33:53 10.1.0.2:37728 NWMConnRcvWnd n:131020 - o:130176 = 844 On Thu, 28 Mar 2024 at 12:31, Jousma, David < [email protected]> wrote: > All, > > Grasping at straws here, IBM support center is baffled too. > > To clone z/OS maintenance to various disconnected sysplex’s I do a DFDSS > dump, and FTP it everywhere it needs to be. Its roughly a 50Gb file > transfer. There is some environmental issue causing slow file transfers to > some systems (40mb’s a sec) and fast file transfers (150Mb/sec) to other > systems on the same CEC. With IBM support help, we’ve narrowed down the > problem to the specification of MODE B and EBCDIC on the transfer since it > is a DSS dump. Remove those, and the transfer is fast on the slow > systems, and still fast on the fast systems. Obviously that isn’t a > solution though. > > So, we are a GDPS shop. The oddity is that all the “fast” transfers are > to the K systems(control systems), and all the “slow” transfers are to the > traditional application systems. TEST, DEV, PROD makes no difference, nor > does LPAR busy or not busy. > > It seems there is something configured differently on the “slow” systems > that is affecting mode b, ebcdic file transfers, but for the life of me, I > cannot put my finger on what, nor can the support center, except that the > issue is at the remote end, in that the OS cannot offload the data fast > enough, so TCPIP/FTP is slowing the transfer pace. > > A virtual adult beverage of choice to the one that can point in a > direction to look…. > > > Dave Jousma > Vice President | Director, Technology Engineering > > > > > > This e-mail transmission contains information that is confidential and may > be privileged. It is intended only for the addressee(s) named above. If > you receive this e-mail in error, please do not read, copy or disseminate > it in any manner. If you are not the intended recipient, any disclosure, > copying, distribution or use of the contents of this information is > prohibited. Please reply to the message immediately by informing the sender > that the message was misdirected. After replying, please erase it from your > computer system. Your assistance in correcting this error is appreciated. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
