Thanks Colin,

We’ve already taken packet traces of both, and sent to IBM.   They see the send 
window being reduced automatically by TCPIP because the remote end cannot keep 
up.   the problem only surfaces when doing EBCDIC and BLOCK transfers.


Dave Jousma
Vice President | Director, Technology Engineering





From: IBM Mainframe Discussion List <[email protected]> on behalf of 
Colin Paice <[email protected]>
Date: Thursday, March 28, 2024 at 8:45 AM
To: [email protected] <[email protected]>
Subject: Re: Slow FTP's
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. 


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

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
  • Slo... Jousma, David
    • ... Colin Paice
      • ... Jousma, David
    • ... rpinion865
      • ... Jousma, David
    • ... Joe Monk
      • ... Jousma, David
        • ... Joe Monk
          • ... Jousma, David
            • ... Styles, Andy (CIO GS&S - Core Infrastructure & IT Operations )
              • ... Massimo Biancucci
                • ... Jousma, David
                • ... David Spiegel

Reply via email to