Alan Cox wrote:
The disk to disk aspect is distorting but he's using similar tests for
each case. In many case disk to disk is the right way to test anyway,
its what you actually do in the real world. ttcp can do similar testing
without the disk layer being involved if that matters.
The closer a
hipersocket
testing/benchmarking need help interpreting results.
Do a short transfer and tcpdump it. Look at the window size
offered by
the server in the syn frame, that is a good guide to the
buffering.
Got a window of 32767 from Linux to z/OS and 65535 from z/OS
to Linux using lukemftp
On Gwe, 2004-05-28 at 18:13, Lucius, Leland wrote:
Yepper, it does. I'm currently running with a 56KB MTU (on z/OS side) and have
tried lower. Never could get the FTP up very high. I even transferred files
between a TFS under z/OS and an ram disk under Linux. Thought it might be I/O
Specifically ftp ? The reason I ask is that the old BSD ftp client
always set 8K buffer limits and many vendors who reused the BSD
client code in other products never got around to fixing that.
Linux has it fixed, I'd have assumed z/Os did but you never know..
Hmmm, good point. Let me
On Gwe, 2004-05-28 at 20:43, Janek Jakubek wrote:
We had a TCPIP performance issue when we upgraded from
OS/390 2.7 to 2.10. The conclusion of that the problem is attached
below (from an IBM ETR record).
This could be another lead to follow
Except that the problem occurs with an 8K MTU
- Original Message -
From: Alan Cox [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Thursday, June 03, 2004 12:04 PM
Subject: Re: Did some extensive hipersocket testing/benchmarking need
help interpreting results.
On Gwe, 2004-05-28 at 20:04, James Tison wrote:
FTP is a __TERRIBLE__
Hmmm, good point. Let me see if I can play with the buffer size under
z/OS.
Well, I can set the default TCP buffer size to different values for the z/OS
stack and we have it set to 65535, so I'd say it's on the largish size.
But, I don't know if the FTP server issues a setsockopt() to set a
On Iau, 2004-06-03 at 22:26, Lucius, Leland wrote:
Well, I can set the default TCP buffer size to different values for the z/OS
stack and we have it set to 65535, so I'd say it's on the largish size.
But, I don't know if the FTP server issues a setsockopt() to set a different
value or not.
Do a short transfer and tcpdump it. Look at the window size offered by
the server in the syn frame, that is a good guide to the buffering.
Got a window of 32767 from Linux to z/OS and 65535 from z/OS to Linux
using lukemftp. Must dash right now, but it appears that changing the
sndbuf size in
To preface this, this all started when our z/OS tcp/ip person tested z/OS
to z/OS hipersocket performance and found it nearly the same as using GBE
osa connection. I immediately went 'huh' and went on to get hipersockets
configured in the z/VM Linux guests.
I then ran some testing after doing so,
125 Storing data set /it/public/Su810_001.iso
100% |*| 595 MB2.68
MB/s--:--
ETA
250 Transfer completed successfully.
624885855 bytes sent in 03:41 (2.68 MB/s)
Depressing isn't it? I've never been able to get much (or any) better than
what you
Just a thought.
Do you have to change the MTU size at all? I think it
defaults on linux to 1500.
Just a thought. Does the MTU size even play into the
hipersockets at all?
Yepper, it does. I'm currently running with a 56KB MTU (on z/OS side) and have tried
lower. Never could get the
On Friday, 05/28/2004 at 12:13 EST, Lucius, Leland
[EMAIL PROTECTED] wrote:
Yepper, it does. I'm currently running with a 56KB MTU (on z/OS side)
and have
tried lower. Never could get the FTP up very high. I even transferred
files
between a TFS under z/OS and an ram disk under Linux.
play into the hipersockets at all?
-Cameron
-Original Message-
From: Lucius, Leland [mailto:[EMAIL PROTECTED]
Sent: Friday, May 28, 2004 10:41 AM
To: [EMAIL PROTECTED]
Subject: Re: Did some extensive hipersocket testing/benchmarking
need help interpreting results.
125 Storing data
To: [EMAIL PROTECTED]
cc:
Subject:Re: Did some extensive hipersocket
testing/benchmarking need help interpreting results.
On Friday, 05/28/2004 at 12:13 EST, Lucius, Leland
[EMAIL PROTECTED] wrote:
Yepper, it does. I'm currently running with a 56KB MTU
To: [EMAIL PROTECTED]
cc:
Subject:Re: Did some extensive hipersocket
testing/benchmarking need help interpreting results.
On Friday, 05/28/2004 at 12:13 EST, Lucius, Leland
[EMAIL PROTECTED] wrote:
Yepper, it does. I'm currently running with a 56KB MTU (on z/OS side
Ummm...you have to have the same MTU on both sides. Make
sure you have
MFS (OS= in IOCDS) at 64K.
Oops, I did mislead with that didn't I? Sorry, 'bout that.
Here's the interface:
hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00
inet addr:10.2.32.30 Mask:255.255.255.0
Of
Lucius, Leland
Sent: Friday, May 28, 2004 12:41 PM
To: [EMAIL PROTECTED]
Subject: Re: Did some extensive hipersocket testing/benchmarking need
help interpreting results.
-snip-
Depressing isn't it? I've never been able to get much (or any) better than
what you have. I don't know why either
PM
To: [EMAIL PROTECTED]
Subject: Re: Did some extensive hipersocket testing/benchmarking need
help interpreting results.
Well to check THAT particular item (on the z/linux to z/linux transfers
anyway) I ipl'ed both guests to set the hsi1 tx/rx numbers back to 0, and
then ran the test. When I
]
Subject: Re: Did some extensive hipersocket testing/benchmarking need
help interpreting results.
So, what you're saying is that the problem isn't with Linux, or
HiperSockets, or TCP/IP (as such) on z/OS, it is the z/OS implementation of
FTP. Perhaps we just need a different/better tool to test
Maybe someone could try with NFS instead of FTP
Is anyone running NFS over HiperSockets to z/OS???
I tried that as well. Unfortunately, I can't remember (and didn't write
it down) the throughput. Let me see if I can get some #s real quick.
Leland
: Re: Did some extensive hipersocket testing/benchmarking need
help interpreting results.
FYI the MTU size being used was 8192
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED
Maybe someone could try with NFS instead of FTP
Is anyone running NFS over HiperSockets to z/OS???
I tried that as well. Unfortunately, I can't remember (and
didn't write
it down) the throughput. Let me see if I can get some #s real quick.
Okay, I NFS mounted an HFS directory
Please respond to Linux on 390 Port
To: [EMAIL PROTECTED]
cc:
Subject:Re: Did some extensive hipersocket
testing/benchmarking need help interpreting results.
On Friday, 05/28/2004 at 12:13 EST, Lucius, Leland
[EMAIL PROTECTED] wrote:
Yepper, it does. I'm
[EMAIL PROTECTED]
05/28/2004 12:40
Please respond to
Linux on 390 Port
To
[EMAIL PROTECTED]
cc
Subject
Re: Did some extensive hipersocket testing/benchmarking need help
interpreting results.
125 Storing data set /it/public/Su810_001.iso
100
: Did some extensive hipersocket testing/benchmarking need
help interpreting results.
The 8192 MTU was used on ALL tests in my original post. So I cant see how it
is the deciding issue.
Post, Mark K
[EMAIL PROTECTED]
m
I haven't tested zLinux-z/OS, but a few months ago I did some testing with
zLinux-zLinux hipersockets and GBe with both ftp and NFS. I tried various z990
chpids:
CHP Frame MTU
FA 16KB8KB
FB 24KB16KB
FC 40KB32KB
FD 64KB64KB
These tests were done during
: Re: Did some extensive hipersocket testing/benchmarking need
help interpreting results.
Well to check THAT particular item (on the z/linux to z/linux transfers
anyway) I ipl'ed both guests to set the hsi1 tx/rx numbers back to 0, and
then ran the test. When I did an ifconfig against each
3.82KB/s??? Is that supposed to be MB/s
Uh, can we all say...oops! ;-) Yes, that was supposed to be MB/s.
Leland
CONFIDENTIALITY NOTICE: This e-mail communication and any attachments may
contain proprietary and privileged information for the use of the designated
recipients named
We had a TCPIP performance issue when we upgraded from
OS/390 2.7 to 2.10. The conclusion of that the problem is attached
below (from an IBM ETR record).
This could be another lead to follow
... from looking at the trace and the dump, we see that
Optimal max segment size is 65,495 bytes,
PROTECTED] On Behalf Of James
Melin
Sent: Friday, May 28, 2004 2:50 PM
To: [EMAIL PROTECTED]
Subject: Re: Did some extensive hipersocket testing/benchmarking need
help interpreting results.
The 8192 MTU was used on ALL tests in my original post. So I cant see how
it
is the deciding issue
On Friday, 05/28/2004 at 03:19 EST, Lucius, Leland
[EMAIL PROTECTED] wrote:
I can live with that. What is the theoritical maximum for a
hipersocket?
It's a function of microcode. The faster the processor, the faster it
runs. Theoretically, of course.
Alan Altmark
Sr. Software Engineer
IBM
. -- Will Rogers
Lucius, Leland [EMAIL PROTECTED]
Sent by: Linux on 390 Port [EMAIL PROTECTED]
05/28/2004 16:19
Please respond to
Linux on 390 Port
To
[EMAIL PROTECTED]
cc
Subject
Re: Did some extensive hipersocket testing/benchmarking need help
interpreting results.
I don't know
Alan,
It's a function of microcode. The faster the processor, the faster it
runs. Theoretically, of course.
That sounds a lot like an 'It depends' answer.
Hummm ... Maybe Bill is rubbing off on you ...
;
Regards,
Jeff
--
Jeffrey C Barnard
Barnard Software, Inc. http://www.bsiopti.com
Phone
34 matches
Mail list logo
