Re: Question About LGR and Hipersocket using RHEL 7.7

[Grzegorz Powiedziuk]

On Thu, Apr 8, 2021, 12:12 PM Davis, Larry (National VM Capability) <
larry.dav...@dxc.com> wrote:

> We are seeing an Issue when Using Hipersockets connected to a DB2 system
> on z/OS
>
> When we perform a VMRELOCATE (LGR) to another member in the complex we
> lose the HS device and it goes offline
> The Relocate works fine the HS devices have the same EQID and we see the
> devices attached on the receiving system
> OSA 3A00 ATTACHED TO LXCGG01D 08A0 BY LXCGG01D
> OSA 3A01 ATTACHED TO LXCGG01D 08A1 BY LXCGG01D
> OSA 3A02 ATTACHED TO LXCGG01D 08A2 BY LXCGG01D
>
> Then we need to perform
> cio_ignore -r 0.0.08A0
> cio_ignore -r 0.0.08A0
> cio_ignore -r 0.0.08A0
>
> Then we have to restart the network devices
>
> For some reason during the LGR and/or reboot the devices are getting
> varied off and/or disabled.
>
> Am I missing something in the devices characteristics
>
> Also We are using a VSWITCH for 1G and 10G OSA's and they are reconnecting
> as expected, but HS is disappearing
>
> Larry Davis
> Senior z/VM systems Architect, Enterprise Services
> T +1.813.394.4240
> DXC Technology dxc.technology
>
>
>
How are you activating these HSI devices? Did you use the znet_conf and did
you add a ifcfg-enccw0. script ? Or you have some other way for
configuring those on boot?
I also use rhel 7.x with hipersockets and I haven't noticed a problem like
this. I used znet_conf initially to configure it live, and then added a
proper ifcfg script.
Gregory

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Question About LGR and Hipersocket using RHEL 7.7

[Mark Post]

On 4/20/21 2:04 PM, Stefan Raspl wrote:
> This is really a shot in the dark, but: Could it be a case where the
> device number from source and target system are different, and you have
> the target system's device IDs on the cio ignore list prior to the
> migration? I.e. what happens in case you run the cio_ignore commands
> prior to an LGM?

Better yet, for z/VM and KVM guests, get rid of cio_ignore altogether.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Question About LGR and Hipersocket using RHEL 7.7

[Davis, Larry (National VM Capability)]

Thanks we are testing again soon, just looking for others that may have tried 
and had similar issues

Larry Davis (z/VM Team)

-Original Message-
From: Linux on 390 Port  On Behalf Of Bill Bitner
Sent: Tuesday, April 20, 2021 12:49 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Question About LGR and Hipersocket using RHEL 7.7

Larry,
If this isn't resolved, I'd suggest you open a z/VM support case and the team 
and take a closer look.

Thanks,
Bill
___

Bill Bitner - z/VM Client Focus and Care - 607-429-3286 bitn...@us.ibm.com 
"Making systems practical and profitable for customers through virtualization 
and its exploitation." - z/VM

--
For LINUX-390 subscribe / signoff / archive access instructions, send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
https://clicktime.symantec.com/3MtjfDJabpB1V2YzGv9uirN7Vc?u=http%3A%2F%2Fwww2.marist.edu%2Fhtbin%2Fwlvindex%3FLINUX-390




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Question About LGR and Hipersocket using RHEL 7.7

[Stefan Raspl]

Hi Larry,

On 4/8/21 6:11 PM, Davis, Larry (National VM Capability) wrote:

We are seeing an Issue when Using Hipersockets connected to a DB2 system on z/OS

When we perform a VMRELOCATE (LGR) to another member in the complex we lose the 
HS device and it goes offline
The Relocate works fine the HS devices have the same EQID and we see the 
devices attached on the receiving system
OSA 3A00 ATTACHED TO LXCGG01D 08A0 BY LXCGG01D
OSA 3A01 ATTACHED TO LXCGG01D 08A1 BY LXCGG01D
OSA 3A02 ATTACHED TO LXCGG01D 08A2 BY LXCGG01D

Then we need to perform
cio_ignore -r 0.0.08A0
cio_ignore -r 0.0.08A0
cio_ignore -r 0.0.08A0


I assume this is a typo and should be A0, A1 and A2, right?


Then we have to restart the network devices

For some reason during the LGR and/or reboot the devices are getting varied off 
and/or disabled.


This is really a shot in the dark, but: Could it be a case where the device 
number from source and target system are different, and you have the target 
system's device IDs on the cio ignore list prior to the migration? I.e. what 
happens in case you run the cio_ignore commands prior to an LGM?



Mit freundlichen Grüßen / Kind regards

Stefan Raspl


Linux on Z
---
IBM Deutschland
Schoenaicher Str. 220
71032 Boeblingen
Phone: +49-7031-16-2177
E-Mail: stefan.ra...@de.ibm.com
---
IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: 
Gregor Pillen

Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 
243294


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: Question About LGR and Hipersocket using RHEL 7.7

[Bill Bitner]

Larry,
If this isn't resolved, I'd suggest you open a z/VM support case and the
team and take a closer look.

Thanks,
Bill
___

Bill Bitner - z/VM Client Focus and Care - 607-429-3286
bitn...@us.ibm.com
"Making systems practical and profitable for customers through
virtualization and its exploitation." - z/VM

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Question About LGR and Hipersocket using RHEL 7.7

[Davis, Larry (National VM Capability)]

We are seeing an Issue when Using Hipersockets connected to a DB2 system on z/OS

When we perform a VMRELOCATE (LGR) to another member in the complex we lose the 
HS device and it goes offline
The Relocate works fine the HS devices have the same EQID and we see the 
devices attached on the receiving system
OSA 3A00 ATTACHED TO LXCGG01D 08A0 BY LXCGG01D
OSA 3A01 ATTACHED TO LXCGG01D 08A1 BY LXCGG01D
OSA 3A02 ATTACHED TO LXCGG01D 08A2 BY LXCGG01D

Then we need to perform
cio_ignore -r 0.0.08A0
cio_ignore -r 0.0.08A0
cio_ignore -r 0.0.08A0

Then we have to restart the network devices

For some reason during the LGR and/or reboot the devices are getting varied off 
and/or disabled.

Am I missing something in the devices characteristics

Also We are using a VSWITCH for 1G and 10G OSA's and they are reconnecting as 
expected, but HS is disappearing

Larry Davis
Senior z/VM systems Architect, Enterprise Services
T +1.813.394.4240
DXC Technology dxc.technology




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390

Re: How to configure hipersocket for Ubuntu on LPAR

[Frank Heimes]

Hi, I did not yet worked with zACI,
but the setup and configuration of HiperSockets in Ubuntu is quite straight
forward:

Just check for configured devices:
znetconf -c | grep HiperSockets
or better check for unconfigured devices for this example:
znetconf -u | grep HiperSockets

And configure a new HiperSocket device (taken from the list with the
unconfigured):
sudo znetconf -a d200
Scanning for network devices...
Successfully configured device 0.0.d200 (encd200)

You should now see it as configured here:
znetconf -c | grep HiperSockets
0.0.d200,0.0.d201,0.0.d202 1731/05 HiperSockets  D2 qeth encd200
   online
(a udev rule was automatically created - for persistence)

The 'device' was automatically named based on the first address of the
triple: encd200
as shown above or verified here:
cat /sys/devices/qeth/0.0.d200/if_name
encd200

You can now configure the HiperSocket device like other qeth devices:
sudo ip addr add 192.0.1.2 dev encd200
and/or using: /etc/network/interfaces

Bring the link up afterwards:
sudo ip link set encd200 up

And verify if everything is fine:
ip addr show d200
lsqeth

In case you don't like the default device name (what I can fully
understand),
you can rename it (for example to hsi0) with the help of a udev rule like
this:
cat /etc/udev/rules.d/70-network-d200-to-hsi0.rules
# rename s390x qeth device 0.0.d200 to HiperSocket device hsi0
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="qeth", KERNELS=="0.0.d200",
ATTR{type}=="1", KERNEL=="hsi*", NAME="hsi0"

So from an Ubuntu point of view the HiperSockets can be handled as usual ...

Bye, Frank

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: How to configure hipersocket for Ubuntu on LPAR

[Alan Altmark]

Answered on IBMVM.

Regards,
  Alan


   Archana P --- Re: [LINUX-390] How to configure hipersocket for Ubuntu on 
LPAR --- 
From:"Archana P" <dollarpo...@gmail.com>To:LINUX-390@VM.MARIST.EDUDate:Wed, 
Oct 26, 2016 4:21 AMSubject:Re: [LINUX-390] How to configure hipersocket for 
Ubuntu on LPAR
  
Hi guys,I need your help regarding setting up the hipersocket between the 
Ubuntuand zACI lpars , the Ubuntu is directly installed on the LPAR something 
asshown below.Regards,ArchanaOn Tue, Oct 25, 2016 at 10:11 PM, Mark Post 
<mp...@suse.com> wrote:> >>> On 10/25/2016 at 10:35 AM, Archana P 
<dollarpo...@gmail.com> wrote:> > Hi guys,> >> >> > I need your help regarding 
setting up the hipersocket between the Ubuntu> > and zACI lpars , the Ubuntu is 
directly installed on the LPAR something> as> > shown below.>> Since this is 
not a question even remotely related to z/VM you should> probably post your 
question to the linux-390 listserv instead.>>> Mark 
Post>--For 
LINUX-390 subscribe / signoff / archive access instructions,send email to 
lists...@vm.marist.edu with the message: INFO LINUX-390 or 
visithttp://www.marist.edu/htbin/wlvindex?LINUX-390--For
 more information on Linux on System z, visithttp://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: How to configure hipersocket for Ubuntu on LPAR

[Archana P]

Hi guys,


I need your help regarding setting up the hipersocket between the Ubuntu
and zACI lpars , the Ubuntu is directly installed on the LPAR something as
shown below.


Regards,
Archana

On Tue, Oct 25, 2016 at 10:11 PM, Mark Post <mp...@suse.com> wrote:

> >>> On 10/25/2016 at 10:35 AM, Archana P <dollarpo...@gmail.com> wrote:
> > Hi guys,
> >
> >
> > I need your help regarding setting up the hipersocket between the Ubuntu
> > and zACI lpars , the Ubuntu is directly installed on the LPAR something
> as
> > shown below.
>
> Since this is not a question even remotely related to z/VM you should
> probably post your question to the linux-390 listserv instead.
>
>
> Mark Post
>

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Optimum Hipersocket MTU

[Donald J.]

Can anyone recommend the best hipersocket MTU size for DB/2 Text Search from 
z/OS to z/Linux ?
Choices are 8k/16k/32k/56k.

--
  Donald J.
  dona...@4email.net

--
http://www.fastmail.com - Access all of your messages and folders
  wherever you are

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Optimum Hipersocket MTU

[Donald J.]

Not sure about massive, but fairly large, 16.5M rows.
The initial build and index setup took 8.1G diskspace on Linux.
I will get a packet trace.

--
  Donald J.
  dona...@4email.net

On Wed, Jan 28, 2015, at 05:33 AM, Rob van der Heij wrote:
 On 28 January 2015 at 14:20, Donald J. dona...@4email.net wrote:

 Can anyone recommend the best hipersocket MTU size for DB/2 Text Search
  from z/OS to z/Linux ?
  Choices are 8k/16k/32k/56k.
 

 In many cases it probably will not matter unless the data volume is really
 massive. If it does matter, then you need very specific configuration
 information or a representative packet track to study. It's not just
 bigger is better and we had a case where the large MSS actually was the
 reason for very poor throughput.

 Rob

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/

--
http://www.fastmail.com - Does exactly what it says on the tin

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Optimum Hipersocket MTU

[Rob van der Heij]

On 28 January 2015 at 15:03, Donald J. dona...@4email.net wrote:

 Not sure about massive, but fairly large, 16.5M rows.
 The initial build and index setup took 8.1G diskspace on Linux.
 I will get a packet trace.


That sounds like enough to at least consider to worry about things.

The benefit of a large MSS is in less packets traveling through the stack,
so less CPU overhead. But the difference is not as large that it would
break the project. I think modern distributions set the QDIO buffers at
maximum already, otherwise you would need that too.Make sure the TCP window
size matches the effective packet size. With a low latency connection like
hipersockets, it is tempting to ignore that, but pretty close is not good
enough to avoid Nagle's Algorithm kick in. Unless the window is very large.
If the application takes the default, you can set it with tcp_wmem, but
many applications have their own configuration options to override the
defaults even when you don't want that.

Now if you're sending a lot of data, that must come from somewhere. You
really need to look at all resources. It is very well possible the network
is not the bottleneck. I have frequently looked at assumed network issues
that turned out to be disk I/O. We'll be happy to give a hand.

Rob
http://www.velocitysoftware.com/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Optimum Hipersocket MTU

[Rob van der Heij]

On 28 January 2015 at 14:20, Donald J. dona...@4email.net wrote:

Can anyone recommend the best hipersocket MTU size for DB/2 Text Search
 from z/OS to z/Linux ?
 Choices are 8k/16k/32k/56k.


In many cases it probably will not matter unless the data volume is really
massive. If it does matter, then you need very specific configuration
information or a representative packet track to study. It's not just
bigger is better and we had a case where the large MSS actually was the
reason for very poor throughput.

Rob

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Dean, David (I/S)]

I am sure that I have ever heard a better word for programming than 
Entwicklung

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Peter 
Linnell
Sent: Wednesday, August 07, 2013 5:53 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: TX-Errs on hipersocket interface.

Hi all,

I will not be at SHARE in Boston, there will be some new faces who are new to 
mainframe from SUSE SE team.  I know you folks will treat them kindly :) 

That said the real reason for S.u.S.E is related to a former law in Germany 
which required a company's name to reflect what they did. Hence, S.u.S.E stood 
for Software- und System-Entwicklung .  Software and Systems Programming.  Now 
ask an American to pronounce that correctly.  :-)  

Cheers,
Peter


 
 
 Rob van der Heij rvdh...@gmail.com 8/2/2013 5:07 AM  
On 2 August 2013 13:45, Billy R. Bingham brbing...@stx.rr.com wrote:

I for one would like to know. :) You don't have
 to post to the list, you can email me private,
 or if you perfer you can post a URL where I can
 read about it.

 Right!  Did someone miss the fact that it's Friday?  First thing today I
asked Peter offline for ugly details. Silly me I thought the lowercase was
just lost in translation through US code pages.

If nothing else, maybe Mark will shed some light on this at SHARE during
one of the social events. That's one of the cool things of attending SHARE.
But if it's obscure German legal stuff, maybe even he did not have a need
to know (LOL)

Rob



 Thanks,

 Billy

  PS  It is SUSE now :-)  SuSE was an artifact of an obscure German law,
  which is now no longer in effect for 10 years now. I won't bore
  the list with the gory details ;-)


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
-
Please see the following link for the BlueCross BlueShield of Tennessee E-mail 
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Dean, David (I/S)]

I am sure that I have NOT ever heard a better word for programming than 
Entwicklung

-Original Message-
From: Dean, David (I/S) 
Sent: Thursday, August 08, 2013 9:11 AM
To: 'Linux on 390 Port'
Subject: RE: TX-Errs on hipersocket interface.

I am sure that I have ever heard a better word for programming than 
Entwicklung

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Peter 
Linnell
Sent: Wednesday, August 07, 2013 5:53 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: TX-Errs on hipersocket interface.

Hi all,

I will not be at SHARE in Boston, there will be some new faces who are new to 
mainframe from SUSE SE team.  I know you folks will treat them kindly :) 

That said the real reason for S.u.S.E is related to a former law in Germany 
which required a company's name to reflect what they did. Hence, S.u.S.E stood 
for Software- und System-Entwicklung .  Software and Systems Programming.  Now 
ask an American to pronounce that correctly.  :-)  

Cheers,
Peter


 
 
 Rob van der Heij rvdh...@gmail.com 8/2/2013 5:07 AM  
On 2 August 2013 13:45, Billy R. Bingham brbing...@stx.rr.com wrote:

I for one would like to know. :) You don't have
 to post to the list, you can email me private,
 or if you perfer you can post a URL where I can
 read about it.

 Right!  Did someone miss the fact that it's Friday?  First thing today I
asked Peter offline for ugly details. Silly me I thought the lowercase was
just lost in translation through US code pages.

If nothing else, maybe Mark will shed some light on this at SHARE during
one of the social events. That's one of the cool things of attending SHARE.
But if it's obscure German legal stuff, maybe even he did not have a need
to know (LOL)

Rob



 Thanks,

 Billy

  PS  It is SUSE now :-)  SuSE was an artifact of an obscure German law,
  which is now no longer in effect for 10 years now. I won't bore
  the list with the gory details ;-)


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
-
Please see the following link for the BlueCross BlueShield of Tennessee E-mail 
disclaimer:  http://www.bcbst.com/email_disclaimer.shtm

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Peter Linnell]

Hi all,

I will not be at SHARE in Boston, there will be some new faces who are new to 
mainframe from SUSE SE team.  I know you folks will treat them kindly :) 

That said the real reason for S.u.S.E is related to a former law in Germany 
which required a company's name to reflect what they did. Hence, S.u.S.E stood 
for Software- und System-Entwicklung .  Software and Systems Programming.  Now 
ask an American to pronounce that correctly.  :-)  

Cheers,
Peter


 
 
 Rob van der Heij rvdh...@gmail.com 8/2/2013 5:07 AM  
On 2 August 2013 13:45, Billy R. Bingham brbing...@stx.rr.com wrote:

I for one would like to know. :) You don't have
 to post to the list, you can email me private,
 or if you perfer you can post a URL where I can
 read about it.

 Right!  Did someone miss the fact that it's Friday?  First thing today I
asked Peter offline for ugly details. Silly me I thought the lowercase was
just lost in translation through US code pages.

If nothing else, maybe Mark will shed some light on this at SHARE during
one of the social events. That's one of the cool things of attending SHARE.
But if it's obscure German legal stuff, maybe even he did not have a need
to know (LOL)

Rob



 Thanks,

 Billy

  PS  It is SUSE now :-)  SuSE was an artifact of an obscure German law,
  which is now no longer in effect for 10 years now. I won't bore
  the list with the gory details ;-)


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Billy R. Bingham]

I for one would like to know. :) You don't have
to post to the list, you can email me private,
or if you perfer you can post a URL where I can
read about it.


Thanks,

Billy

 PS  It is SUSE now :-)  SuSE was an artifact of an obscure German law,
 which is now no longer in effect for 10 years now. I won't bore
 the list with the gory details ;-)



  Ron Foster ron.fos...@baldor.abb.com 7/25/2013 6:18 AM 
 Carsten,

 Do you know where I would start looking for causes of the transmit
 errors on Hipersockets?

 The error is occurring on SLES11 SP2 systems.  We are not having it on
 our SLES10 SP4 systems.

 Do I need to open a problem with the SuSe folks?

 Thanks,

 Ron Foster

 Baldor Electric Company

 5711 R S Boreham Jr Street

 Fort Smith, AR 72901

 Phone:479-648-5865

 Fax:479-646-5440

 Email: ron.fos...@baldor.abb.com

 IM Address:rfos...@baldor.com

 www.baldor.com



 
 From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Carsten
 Otte [co...@de.ibm.com] Sent: Thursday, July 25, 2013 7:53 AM To:
 LINUX-390@VM.MARIST.EDU Subject: Re: TX-Errs on hipersocket interface.

 Alan wrote:
 Carsten, this is information that really needs to be in the Device
 Driver book, as it differs from the traditional interpretation of
 TX/RX counters.
 Ah, you're right - that would be accouned as dropped, not TX error.
 Forget about my reply then, time to look at other causes for that TX
 error. Sorry for the noise.

 with kind regards
 Carsten Otte
 System z firmware development / Boeblingen lab
 ---
 Every revolution was first a thought in one man's mind;
 and when the same thought occurs to another man, it is the key to that
 era.

  - Ralph Waldo Emerson, Essays: First Series, 1841

 --
 For LINUX-390 subscribe / signoff / archive access instructions, send
 email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/
 --
 For LINUX-390 subscribe / signoff / archive access instructions, send
 email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/

 --
 For LINUX-390 subscribe / signoff / archive access instructions, send
 email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/



...For if tyranny should prevail in this great
country, we may expect liberty will expire
throughout the world A Freeman, 1775

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Rob van der Heij]

On 2 August 2013 13:45, Billy R. Bingham brbing...@stx.rr.com wrote:

I for one would like to know. :) You don't have
 to post to the list, you can email me private,
 or if you perfer you can post a URL where I can
 read about it.

 Right!  Did someone miss the fact that it's Friday?  First thing today I
asked Peter offline for ugly details. Silly me I thought the lowercase was
just lost in translation through US code pages.

If nothing else, maybe Mark will shed some light on this at SHARE during
one of the social events. That's one of the cool things of attending SHARE.
But if it's obscure German legal stuff, maybe even he did not have a need
to know (LOL)

Rob



 Thanks,

 Billy

  PS  It is SUSE now :-)  SuSE was an artifact of an obscure German law,
  which is now no longer in effect for 10 years now. I won't bore
  the list with the gory details ;-)


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Peter Linnell]

Hi,
On pg 178 of http://public.dhe.ibm.com/software/dw/linux390/docu/les3dd03.pdf  
there is a section on using tcpdump or wireshark to do traces on the 
hypersocket .  That said, As others have explained it is not likely an issue 
unless you are seeing huge amount of Tx errors as I understand it.  

Hope that helps,

Peter

PS  It is SUSE now :-)  SuSE was an artifact of an obscure German law, which is 
now no longer in effect for 10 years now. I won't bore the list with the 
gory details ;-)


 
 Ron Foster ron.fos...@baldor.abb.com 7/25/2013 6:18 AM  
Carsten, 

Do you know where I would start looking for causes of the transmit errors on 
Hipersockets?

The error is occurring on SLES11 SP2 systems.  We are not having it on our 
SLES10 SP4 systems.

Do I need to open a problem with the SuSe folks?

Thanks,

Ron Foster

Baldor Electric Company

5711 R S Boreham Jr Street

Fort Smith, AR 72901

Phone:479-648-5865

Fax:479-646-5440

Email: ron.fos...@baldor.abb.com

IM Address:rfos...@baldor.com

www.baldor.com




From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Carsten Otte 
[co...@de.ibm.com]
Sent: Thursday, July 25, 2013 7:53 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: TX-Errs on hipersocket interface.

Alan wrote:
Carsten, this is information that really needs to be in the Device Driver
book, as it differs from the traditional interpretation of TX/RX counters.
Ah, you're right - that would be accouned as dropped, not TX error. Forget
about my
reply then, time to look at other causes for that TX error. Sorry for the
noise.

with kind regards
Carsten Otte
System z firmware development / Boeblingen lab
---
Every revolution was first a thought in one man's mind;
and when the same thought occurs to another man, it is the key to that era.

 - Ralph Waldo Emerson, Essays: First Series, 1841

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Ursula Braun]

Ron,

I have not followed all IP-stack related patches for SLES12; thus I can
answer your question just from a qeth driver perspective: Your kernel
level misses some qeth patches, but none of these patches is related to
your TX errors symptom. Thus my answer is no from my qeth driver
perspective.

Kind Regards, Ursula Braun, Linux on System z development, IBM Germany

On Fri, 2013-07-26 at 19:47 +, Ron Foster wrote:
 Ursula,

 We are running kernel  3.0.42-0.7-default.

 Would it help to go to a more recent kernel?

 Thanks,
 Ron Foster

 Baldor Electric Company

 5711 R S Boreham Jr Street

 Fort Smith, AR 72901

 Phone:479-648-5865

 Fax:479-646-5440

 Email: ron.fos...@baldor.abb.com

 IM Address:rfos...@baldor.com

 www.baldor.com



 
 From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Ursula Braun 
 [ubr...@linux.vnet.ibm.com]
 Sent: Friday, July 26, 2013 3:05 AM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: TX-Errs on hipersocket interface.

 Jon,

 without any performance data my answer can be only vague. But let's
 assume a performance increase for data sending when moving from SLES10
 to SLES11. If the receiver has already been close to his buffer usage
 limit with SLES10, he might hit this limit after upgrading the sender to
 SLES11.

 Regards, Ursula Braun, Linux on System z Development, IBM Germany


 On Thu, 2013-07-25 at 18:21 +, Veencamp, Jonathon D. wrote:
  Question:  Why would SLES 11 see hipersocket retransmits and window 
  adjustments and not SLES 10?  Is the device driver either more forgiving or 
  efficient on SLES 10?
 
  I'm just curious.  I may be in the same situation soon.
 
  Regards
  Jon Veencamp
  Federated Insurance
 
  -Original Message-
  From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of 
  Ursula Braun
  Sent: Thursday, July 25, 2013 9:54 AM
  To: LINUX-390@VM.MARIST.EDU
  Subject: Re: TX-Errs on hipersocket interface.
 
  Ron,
 
  Carsten's first explanation is correct. If you see tx_errors on a
  HiperSockets interface, it usually means transmission of a packet fails
  because the receiver has currently no free receive buffer. You should
  verify first if the receiver has configured the maximum of 128 buffers
  (sysfs attribute buffer_count) for his HiperSockets device. 128 is
  nowadays the default, but older qeth driver versions run with a default
  of 16. If you see the tx_errors even though your receiver runs already
  with the maximum of 128 buffers, you either have to live with the
  autotuning mechanisms of tcp or you take actions to slow down the sender
  or to accelerate the receiver.
 
  As Alan suggested we can document this in the Device Driver book. The
  other option would be to change the current behavior of the qeth driver
  and increase probably both the tx_dropped and the tx_error counter.
 
  It is definitely not a problem to report to SuSe folks.
 
  Kind regards, Ursula Braun, Linux on System z development, IBM Germany
 
  On Thu, 2013-07-25 at 13:18 +, Ron Foster wrote:
   Carsten,
   Do you know where I would start looking for causes of the transmit errors 
   on Hipersockets?
   The error is occurring on SLES11 SP2 systems.  We are not having it on 
   our SLES10 SP4 systems.
   Do I need to open a problem with the SuSe folks?
  
   Thanks,
   Ron Foster
   Baldor Electric Company
   5711 R S Boreham Jr Street
   Fort Smith, AR 72901
 
  
 
  The information contained in this e-mail message is intended only for the 
  personal and confidential use of the designated recipient(s) named above. 
  This message may be an attorney-client or work product communication which 
  is privileged and confidential. It may also contain protected health 
  information that is protected by federal law. If you have received this 
  communication in error, please notify us immediately by telephone and 
  destroy (shred) the original message and all attachments. Any review, 
  dissemination, distribution or copying of this message by any person other 
  than the intended recipient(s) or their authorized agents is strictly 
  prohibited. Thank you.

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/
 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http

Re: TX-Errs on hipersocket interface.

[Ursula Braun]

Jon,

without any performance data my answer can be only vague. But let's
assume a performance increase for data sending when moving from SLES10
to SLES11. If the receiver has already been close to his buffer usage
limit with SLES10, he might hit this limit after upgrading the sender to
SLES11.

Regards, Ursula Braun, Linux on System z Development, IBM Germany


On Thu, 2013-07-25 at 18:21 +, Veencamp, Jonathon D. wrote:
 Question:  Why would SLES 11 see hipersocket retransmits and window 
 adjustments and not SLES 10?  Is the device driver either more forgiving or 
 efficient on SLES 10?

 I'm just curious.  I may be in the same situation soon.

 Regards
 Jon Veencamp
 Federated Insurance

 -Original Message-
 From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ursula 
 Braun
 Sent: Thursday, July 25, 2013 9:54 AM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: TX-Errs on hipersocket interface.

 Ron,

 Carsten's first explanation is correct. If you see tx_errors on a
 HiperSockets interface, it usually means transmission of a packet fails
 because the receiver has currently no free receive buffer. You should
 verify first if the receiver has configured the maximum of 128 buffers
 (sysfs attribute buffer_count) for his HiperSockets device. 128 is
 nowadays the default, but older qeth driver versions run with a default
 of 16. If you see the tx_errors even though your receiver runs already
 with the maximum of 128 buffers, you either have to live with the
 autotuning mechanisms of tcp or you take actions to slow down the sender
 or to accelerate the receiver.

 As Alan suggested we can document this in the Device Driver book. The
 other option would be to change the current behavior of the qeth driver
 and increase probably both the tx_dropped and the tx_error counter.

 It is definitely not a problem to report to SuSe folks.

 Kind regards, Ursula Braun, Linux on System z development, IBM Germany

 On Thu, 2013-07-25 at 13:18 +, Ron Foster wrote:
  Carsten,
  Do you know where I would start looking for causes of the transmit errors 
  on Hipersockets?
  The error is occurring on SLES11 SP2 systems.  We are not having it on our 
  SLES10 SP4 systems.
  Do I need to open a problem with the SuSe folks?
 
  Thanks,
  Ron Foster
  Baldor Electric Company
  5711 R S Boreham Jr Street
  Fort Smith, AR 72901

 

 The information contained in this e-mail message is intended only for the 
 personal and confidential use of the designated recipient(s) named above. 
 This message may be an attorney-client or work product communication which is 
 privileged and confidential. It may also contain protected health information 
 that is protected by federal law. If you have received this communication in 
 error, please notify us immediately by telephone and destroy (shred) the 
 original message and all attachments. Any review, dissemination, distribution 
 or copying of this message by any person other than the intended recipient(s) 
 or their authorized agents is strictly prohibited. Thank you.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Ron Foster]

Ursula,

We are running kernel  3.0.42-0.7-default.

Would it help to go to a more recent kernel?

Thanks,
Ron Foster

Baldor Electric Company
 
5711 R S Boreham Jr Street

Fort Smith, AR 72901

Phone:479-648-5865

Fax:479-646-5440

Email: ron.fos...@baldor.abb.com

IM Address:rfos...@baldor.com

www.baldor.com




From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Ursula Braun 
[ubr...@linux.vnet.ibm.com]
Sent: Friday, July 26, 2013 3:05 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: TX-Errs on hipersocket interface.

Jon,

without any performance data my answer can be only vague. But let's
assume a performance increase for data sending when moving from SLES10
to SLES11. If the receiver has already been close to his buffer usage
limit with SLES10, he might hit this limit after upgrading the sender to
SLES11.

Regards, Ursula Braun, Linux on System z Development, IBM Germany


On Thu, 2013-07-25 at 18:21 +, Veencamp, Jonathon D. wrote:
 Question:  Why would SLES 11 see hipersocket retransmits and window 
 adjustments and not SLES 10?  Is the device driver either more forgiving or 
 efficient on SLES 10?

 I'm just curious.  I may be in the same situation soon.

 Regards
 Jon Veencamp
 Federated Insurance

 -Original Message-
 From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ursula 
 Braun
 Sent: Thursday, July 25, 2013 9:54 AM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: TX-Errs on hipersocket interface.

 Ron,

 Carsten's first explanation is correct. If you see tx_errors on a
 HiperSockets interface, it usually means transmission of a packet fails
 because the receiver has currently no free receive buffer. You should
 verify first if the receiver has configured the maximum of 128 buffers
 (sysfs attribute buffer_count) for his HiperSockets device. 128 is
 nowadays the default, but older qeth driver versions run with a default
 of 16. If you see the tx_errors even though your receiver runs already
 with the maximum of 128 buffers, you either have to live with the
 autotuning mechanisms of tcp or you take actions to slow down the sender
 or to accelerate the receiver.

 As Alan suggested we can document this in the Device Driver book. The
 other option would be to change the current behavior of the qeth driver
 and increase probably both the tx_dropped and the tx_error counter.

 It is definitely not a problem to report to SuSe folks.

 Kind regards, Ursula Braun, Linux on System z development, IBM Germany

 On Thu, 2013-07-25 at 13:18 +, Ron Foster wrote:
  Carsten,
  Do you know where I would start looking for causes of the transmit errors 
  on Hipersockets?
  The error is occurring on SLES11 SP2 systems.  We are not having it on our 
  SLES10 SP4 systems.
  Do I need to open a problem with the SuSe folks?
 
  Thanks,
  Ron Foster
  Baldor Electric Company
  5711 R S Boreham Jr Street
  Fort Smith, AR 72901

 

 The information contained in this e-mail message is intended only for the 
 personal and confidential use of the designated recipient(s) named above. 
 This message may be an attorney-client or work product communication which is 
 privileged and confidential. It may also contain protected health information 
 that is protected by federal law. If you have received this communication in 
 error, please notify us immediately by telephone and destroy (shred) the 
 original message and all attachments. Any review, dissemination, distribution 
 or copying of this message by any person other than the intended recipient(s) 
 or their authorized agents is strictly prohibited. Thank you.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Carsten Otte]

Ron,

TX errors on a Hipersocket are business as usual. When the receiver fails
to pick up packets at the same rate that the transmitter transmits, the
queues will run full over time. TCP uses packet loss as a measure to
tune the TCP window size, which effectively will reduce the transmit rate.
Thus, the packet loss you see only indicates that trimming down transmits
to match the receiver's performance is taking place.

with kind regards
Carsten Otte
System z firmware development / Boeblingen lab
---
Every revolution was first a thought in one man's mind;
and when the same thought occurs to another man, it is the key to that era.

 - Ralph Waldo Emerson, Essays: First Series, 1841



 Ron Foster
 Ron.Foster@baldo
 r.abb.com To
 Sent by: Linux on LINUX-390@vm.marist.edu,
 390 Port   cc
 linux-...@vm.mar
 ist.edu  Subject
   TX-Errs on hipersocket interface.

 24.07.2013 22:13


 Please respond to
 Linux on 390 Port
 linux-...@vm.mar
 ist.edu






Hello,



While investigating another problem, I did a netstat -I on our production
SAP Linux App Servers.



To my surprise, I am getting TX-ERRS on a hipersocket interface on two of
our systems.  The two systems have recently been converted to SLES11 SP2.
The hipersocket device is connected to a z/OS system where our DB2 system
lives.



The hipersocket device is also used by other SAP APP servers that are
SLES10 SP4.  Those servers have zeros in the TX-ERRS column.



Any ideas on how to trouble shoot Transmit errors on a hipersocket?



Ron Foster

Baldor Electric Company

5711 R S Boreham Jr Street

Fort Smith, AR 72901

Phone:479-648-5865

Fax:479-646-5440

Email: ron.fos...@baldor.abb.commailto:ron.fos...@baldor.abb.com

IM Address:rfos...@baldor.com

www.baldor.comhttp://www.baldor.com/



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Alan Altmark]

On Thursday, 07/25/2013 at 02:58 EDT, Carsten Otte co...@de.ibm.com
wrote:
 TX errors on a Hipersocket are business as usual. When the receiver
fails
 to pick up packets at the same rate that the transmitter transmits, the
 queues will run full over time. TCP uses packet loss as a measure to
 tune the TCP window size, which effectively will reduce the transmit
rate.
 Thus, the packet loss you see only indicates that trimming down
transmits
 to match the receiver's performance is taking place.

Carsten, this is information that really needs to be in the Device Driver
book, as it differs from the traditional interpretation of TX/RX counters.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Carsten Otte]

Alan wrote:
Carsten, this is information that really needs to be in the Device Driver
book, as it differs from the traditional interpretation of TX/RX counters.
Ah, you're right - that would be accouned as dropped, not TX error. Forget
about my
reply then, time to look at other causes for that TX error. Sorry for the
noise.

with kind regards
Carsten Otte
System z firmware development / Boeblingen lab
---
Every revolution was first a thought in one man's mind;
and when the same thought occurs to another man, it is the key to that era.

 - Ralph Waldo Emerson, Essays: First Series, 1841

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Ron Foster]

Carsten, 

Do you know where I would start looking for causes of the transmit errors on 
Hipersockets?

The error is occurring on SLES11 SP2 systems.  We are not having it on our 
SLES10 SP4 systems.

Do I need to open a problem with the SuSe folks?

Thanks,

Ron Foster

Baldor Electric Company

5711 R S Boreham Jr Street

Fort Smith, AR 72901

Phone:479-648-5865

Fax:479-646-5440

Email: ron.fos...@baldor.abb.com

IM Address:rfos...@baldor.com

www.baldor.com




From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Carsten Otte 
[co...@de.ibm.com]
Sent: Thursday, July 25, 2013 7:53 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: TX-Errs on hipersocket interface.

Alan wrote:
Carsten, this is information that really needs to be in the Device Driver
book, as it differs from the traditional interpretation of TX/RX counters.
Ah, you're right - that would be accouned as dropped, not TX error. Forget
about my
reply then, time to look at other causes for that TX error. Sorry for the
noise.

with kind regards
Carsten Otte
System z firmware development / Boeblingen lab
---
Every revolution was first a thought in one man's mind;
and when the same thought occurs to another man, it is the key to that era.

 - Ralph Waldo Emerson, Essays: First Series, 1841

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Ursula Braun]

Ron,

Carsten's first explanation is correct. If you see tx_errors on a
HiperSockets interface, it usually means transmission of a packet fails
because the receiver has currently no free receive buffer. You should
verify first if the receiver has configured the maximum of 128 buffers
(sysfs attribute buffer_count) for his HiperSockets device. 128 is
nowadays the default, but older qeth driver versions run with a default
of 16. If you see the tx_errors even though your receiver runs already
with the maximum of 128 buffers, you either have to live with the
autotuning mechanisms of tcp or you take actions to slow down the sender
or to accelerate the receiver.

As Alan suggested we can document this in the Device Driver book. The
other option would be to change the current behavior of the qeth driver
and increase probably both the tx_dropped and the tx_error counter.

It is definitely not a problem to report to SuSe folks.

Kind regards, Ursula Braun, Linux on System z development, IBM Germany

On Thu, 2013-07-25 at 13:18 +, Ron Foster wrote:
 Carsten,

 Do you know where I would start looking for causes of the transmit errors on 
 Hipersockets?

 The error is occurring on SLES11 SP2 systems.  We are not having it on our 
 SLES10 SP4 systems.

 Do I need to open a problem with the SuSe folks?

 Thanks,

 Ron Foster

 Baldor Electric Company

 5711 R S Boreham Jr Street

 Fort Smith, AR 72901

 Phone:479-648-5865

 Fax:479-646-5440

 Email: ron.fos...@baldor.abb.com

 IM Address:rfos...@baldor.com

 www.baldor.com



 
 From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Carsten Otte 
 [co...@de.ibm.com]
 Sent: Thursday, July 25, 2013 7:53 AM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: TX-Errs on hipersocket interface.

 Alan wrote:
 Carsten, this is information that really needs to be in the Device Driver
 book, as it differs from the traditional interpretation of TX/RX counters.
 Ah, you're right - that would be accouned as dropped, not TX error. Forget
 about my
 reply then, time to look at other causes for that TX error. Sorry for the
 noise.

 with kind regards
 Carsten Otte
 System z firmware development / Boeblingen lab
 ---
 Every revolution was first a thought in one man's mind;
 and when the same thought occurs to another man, it is the key to that era.

  - Ralph Waldo Emerson, Essays: First Series, 1841

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/
 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Veencamp, Jonathon D.]

Question:  Why would SLES 11 see hipersocket retransmits and window adjustments 
and not SLES 10?  Is the device driver either more forgiving or efficient on 
SLES 10?

I'm just curious.  I may be in the same situation soon.

Regards
Jon Veencamp
Federated Insurance

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Ursula 
Braun
Sent: Thursday, July 25, 2013 9:54 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: TX-Errs on hipersocket interface.

Ron,

Carsten's first explanation is correct. If you see tx_errors on a
HiperSockets interface, it usually means transmission of a packet fails
because the receiver has currently no free receive buffer. You should
verify first if the receiver has configured the maximum of 128 buffers
(sysfs attribute buffer_count) for his HiperSockets device. 128 is
nowadays the default, but older qeth driver versions run with a default
of 16. If you see the tx_errors even though your receiver runs already
with the maximum of 128 buffers, you either have to live with the
autotuning mechanisms of tcp or you take actions to slow down the sender
or to accelerate the receiver.

As Alan suggested we can document this in the Device Driver book. The
other option would be to change the current behavior of the qeth driver
and increase probably both the tx_dropped and the tx_error counter.

It is definitely not a problem to report to SuSe folks.

Kind regards, Ursula Braun, Linux on System z development, IBM Germany

On Thu, 2013-07-25 at 13:18 +, Ron Foster wrote:
 Carsten,
 Do you know where I would start looking for causes of the transmit errors on 
 Hipersockets?
 The error is occurring on SLES11 SP2 systems.  We are not having it on our 
 SLES10 SP4 systems.
 Do I need to open a problem with the SuSe folks?

 Thanks,
 Ron Foster
 Baldor Electric Company
 5711 R S Boreham Jr Street
 Fort Smith, AR 72901



The information contained in this e-mail message is intended only for the 
personal and confidential use of the designated recipient(s) named above. This 
message may be an attorney-client or work product communication which is 
privileged and confidential. It may also contain protected health information 
that is protected by federal law. If you have received this communication in 
error, please notify us immediately by telephone and destroy (shred) the 
original message and all attachments. Any review, dissemination, distribution 
or copying of this message by any person other than the intended recipient(s) 
or their authorized agents is strictly prohibited. Thank you.

Re: TX-Errs on hipersocket interface.

[Ron Foster]

The receiver is zos.  Anybody here know how to increase the buffers in zos. 

Ron

Sent from my iPhone

On Jul 25, 2013, at 1:14 PM, Ursula Braun ubr...@linux.vnet.ibm.com wrote:

 Ron,
 
 Carsten's first explanation is correct. If you see tx_errors on a
 HiperSockets interface, it usually means transmission of a packet fails
 because the receiver has currently no free receive buffer. You should
 verify first if the receiver has configured the maximum of 128 buffers
 (sysfs attribute buffer_count) for his HiperSockets device. 128 is
 nowadays the default, but older qeth driver versions run with a default
 of 16. If you see the tx_errors even though your receiver runs already
 with the maximum of 128 buffers, you either have to live with the
 autotuning mechanisms of tcp or you take actions to slow down the sender
 or to accelerate the receiver.
 
 As Alan suggested we can document this in the Device Driver book. The
 other option would be to change the current behavior of the qeth driver
 and increase probably both the tx_dropped and the tx_error counter.
 
 It is definitely not a problem to report to SuSe folks.
 
 Kind regards, Ursula Braun, Linux on System z development, IBM Germany
 
 On Thu, 2013-07-25 at 13:18 +, Ron Foster wrote:
 Carsten,
 
 Do you know where I would start looking for causes of the transmit errors on 
 Hipersockets?
 
 The error is occurring on SLES11 SP2 systems.  We are not having it on our 
 SLES10 SP4 systems.
 
 Do I need to open a problem with the SuSe folks?
 
 Thanks,
 
 Ron Foster
 
 Baldor Electric Company
 
 5711 R S Boreham Jr Street
 
 Fort Smith, AR 72901
 
 Phone:479-648-5865
 
 Fax:479-646-5440
 
 Email: ron.fos...@baldor.abb.com
 
 IM Address:rfos...@baldor.com
 
 www.baldor.com
 
 
 
 
 From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Carsten Otte 
 [co...@de.ibm.com]
 Sent: Thursday, July 25, 2013 7:53 AM
 To: LINUX-390@VM.MARIST.EDU
 Subject: Re: TX-Errs on hipersocket interface.
 
 Alan wrote:
 Carsten, this is information that really needs to be in the Device Driver
 book, as it differs from the traditional interpretation of TX/RX counters.
 Ah, you're right - that would be accouned as dropped, not TX error. Forget
 about my
 reply then, time to look at other causes for that TX error. Sorry for the
 noise.
 
 with kind regards
 Carsten Otte
 System z firmware development / Boeblingen lab
 ---
 Every revolution was first a thought in one man's mind;
 and when the same thought occurs to another man, it is the key to that era.
 
 - Ralph Waldo Emerson, Essays: First Series, 1841
 
 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/
 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/
 
 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: TX-Errs on hipersocket interface.

[Bruce Hayden]

Ron,
See page 11 of this presentation:
http://www.vm.ibm.com/service/vmreqzeh.html
This presentation is found on
http://www.ibm.com/developerworks/linux/linux390/perf/tuning_networking.htmlwhere
there are other good tuning tips.


On Thu, Jul 25, 2013 at 2:42 PM, Ron Foster ron.fos...@baldor.abb.comwrote:

 The receiver is zos.  Anybody here know how to increase the buffers in zos.

 Ron

 Sent from my iPhone




--
Bruce Hayden
z/VM and Linux on System z ATS
IBM, Endicott, NY

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

TX-Errs on hipersocket interface.

[Ron Foster]

Hello,



While investigating another problem, I did a netstat -I on our production SAP 
Linux App Servers.



To my surprise, I am getting TX-ERRS on a hipersocket interface on two of our 
systems.  The two systems have recently been converted to SLES11 SP2.  The 
hipersocket device is connected to a z/OS system where our DB2 system lives.



The hipersocket device is also used by other SAP APP servers that are SLES10 
SP4.  Those servers have zeros in the TX-ERRS column.



Any ideas on how to trouble shoot Transmit errors on a hipersocket?



Ron Foster

Baldor Electric Company

5711 R S Boreham Jr Street

Fort Smith, AR 72901

Phone:479-648-5865

Fax:479-646-5440

Email: ron.fos...@baldor.abb.commailto:ron.fos...@baldor.abb.com

IM Address:rfos...@baldor.com

www.baldor.comhttp://www.baldor.com/



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Appropriate hipersocket MFS size for use with SAP Apps Servers

[Rob van der Heij]

On 15 June 2013 17:58, Ron Foster ron.fos...@baldor.abb.com wrote:

 Rob,

 The traffic is between our Sap application servers running under zvm.


I'm surprised the traffic would be that impressive. Normally I see
bandwidth requirements with SAP for the transport data via NFS. For the
real application work, wouldn't processing in SAP and database latency on
the z/OS side be the limiting factor?


 During the latest conference call, the TCP ip folks determined that the
 SAP traffic in question generally has packets less than 8k.  So changing
 the frame size would not help.


It would be good to know whether this is by design or by observation. When
the MSS is 16K that gives you the MTU of 8K and that discourages large
packets.

The scenario that I referred to was where the customer just increased the
MSS to 64K and found very slow FTP transfer in one direction. The recent
qeth drivers recognize the MSS and adjust the MTU accordingly. However,
some applications use the tcp_wmem to limit the amount of data in transit.
An unhappy combination of default tcp_wmem and MTU causes less-than-full
packets in the middle of the conversation which kicks in Nagle's Algorithm.
For linux that resides in /proc/sys/net/ipv4 and z/OS has a TCPSENDBFRSIZE
parameter which has a default that is not good for large HiperSockets MSS.

But this is all about throughput and latency. I have a hard time believe
that storage creep in z/OS would be fixed by using a different MSS...

Rob

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Appropriate hipersocket MFS size for use with SAP Apps Servers

[Rob van der Heij]

On 13 June 2013 23:58, Ron Foster ron.fos...@baldor.abb.com wrote:

3. One of the things that the TCP IP folks want us to do on the hardware
 side is to increase the maximum frame size to 64k. for this hipersocket.

 4. This would normally increase the MTU size to 56k for the hipersocket.

 5. If I remember properly the 56k value would exceed the SAP recommended
 MTU size of 8k.

 6. The IBM z/os TCP/IP support says that the MTU size could be forced to
 8k.

 Anyone have any experience in forcing an MTU to 8k like this?  Any
 unwelcome side effects?


The queuing that the MVS folks observe is likely in another place than the
MTU size, at least there are other knobs to work first. If you only
increase the MSS and MTU to the max, you may end up with throughput
seriously lower than what you achieve now. I suppose the massive volumes
you talk about is for the shared NFS space between the two?

I can dig up some more questions for you when I get through the rest of my
pending inbox (I hate when you all start these threads when I'm offline ;-)

Rob

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Appropriate hipersocket MFS size for use with SAP Apps Servers

[Ron Foster]

Rob,

The traffic is between our Sap application servers running under zvm.  

During the latest conference call, the TCP ip folks determined that the SAP 
traffic in question generally has packets less than 8k.  So changing the frame 
size would not help.

Ron Foster

Baldor Electric Company

5711 R S Boreham Jr Street

Fort Smith, AR 72901

Phone:479-648-5865

Fax:479-646-5440

Email: ron.fos...@baldor.abb.com

IM Address:rfos...@baldor.com

www.baldor.com




From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Rob van der Heij 
[rvdh...@gmail.com]
Sent: Saturday, June 15, 2013 2:05 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Appropriate hipersocket MFS size for use with SAP Apps Servers

On 13 June 2013 23:58, Ron Foster ron.fos...@baldor.abb.com wrote:

3. One of the things that the TCP IP folks want us to do on the hardware
 side is to increase the maximum frame size to 64k. for this hipersocket.

 4. This would normally increase the MTU size to 56k for the hipersocket.

 5. If I remember properly the 56k value would exceed the SAP recommended
 MTU size of 8k.

 6. The IBM z/os TCP/IP support says that the MTU size could be forced to
 8k.

 Anyone have any experience in forcing an MTU to 8k like this?  Any
 unwelcome side effects?


The queuing that the MVS folks observe is likely in another place than the
MTU size, at least there are other knobs to work first. If you only
increase the MSS and MTU to the max, you may end up with throughput
seriously lower than what you achieve now. I suppose the massive volumes
you talk about is for the shared NFS space between the two?

I can dig up some more questions for you when I get through the rest of my
pending inbox (I hate when you all start these threads when I'm offline ;-)

Rob

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Appropriate hipersocket MFS size for use with SAP Apps Servers

[David Boyes]

 3. One of the things that the TCP IP folks want us to do on the hardware side
 is to increase the maximum frame size to 64k. for this hipersocket.
 
 4. This would normally increase the MTU size to 56k for the hipersocket.
 
 5. If I remember properly the 56k value would exceed the SAP recommended
 MTU size of 8k.

That recommendation is for garden-variety Ethernet where 8K jumbo frames are 
the max supported. Hipersockets != Ethernet. 56K MTU works nicely.

 6. The IBM z/os TCP/IP support says that the MTU size could be forced to 8k.
 Anyone have any experience in forcing an MTU to 8k like this?  Any
 unwelcome side effects?

It's going to increase the CPU utilization of the TCP stacks substantially 
since the stack has to do more fragmentation/reassembly.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Appropriate hipersocket MFS size for use with SAP Apps Servers

[Leland Lucius]

On 6/13/2013 2:28 PM, Ron Foster wrote:

Anyone have any experience running SAP apps servers under z/vm with a larger 
than 8k MTU size?



We run with a 16K MFS and an 8K MTU.  Like you, we use a single
hipersocket CHPID.

However, we're still on z/OS 1.12 with plans to upgrade to z/OS 1.13
soonish.  So, thanks for the heads up.  :-)

Leland

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Appropriate hipersocket MFS size for use with SAP Apps Servers

[Ron Foster]

Hello listers,



We have a bunch of SAP application servers running under z/vm. They are all 
pointed at the same z/os 1.13 system. There are several DB2s running on this 
z/OS system.  All the Apps servers are using the same hipersocket chpid to 
communicate to the z/os system the same hipersocket chipid. Since going to z/OS 
1.13, we are experiencing storage creep in our TCPIP address space.



This hipersocket is using a 8k MTU size.  I believe this to be the SAP 
recommended size.



Our z/os support folks are being told by their support folks that they would 
like us to increase the MTU size from 8k to something larger.



Anyone have any experience running SAP apps servers under z/vm with a larger 
than 8k MTU size?



Thanks,

Ron



Ron Foster

Baldor Electric Company

5711 R S Boreham Jr Street

Fort Smith, AR 72901

Phone:479-648-5865

Fax:479-646-5440

Email: ron.fos...@baldor.abb.commailto:ron.fos...@baldor.abb.com

IM Address:rfos...@baldor.com

www.baldor.comhttp://www.baldor.com/



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Appropriate hipersocket MFS size for use with SAP Apps Servers

[Alan Altmark]

On Thursday, 06/13/2013 at 03:29 EDT, Ron Foster
ron.fos...@baldor.abb.com wrote:
 We have a bunch of SAP application servers running under z/vm. They are
all
 pointed at the same z/os 1.13 system. There are several DB2s running on
this
 z/OS system.  All the Apps servers are using the same hipersocket chpid
to
 communicate to the z/os system the same hipersocket chipid. Since going
to z/OS
 1.13, we are experiencing storage creep in our TCPIP address space.

 This hipersocket is using a 8k MTU size.  I believe this to be the SAP
 recommended size.

 Our z/os support folks are being told by their support folks that they
would
 like us to increase the MTU size from 8k to something larger.

That sounds strange, to say the least.  What logic do they give to support
the conclusion that a larger MTU will prevent storage creep?  Large MTU or
small, the path through the stack should be the same.  If you didn't have
storage creep on the earlier release with an 8K MTU, you shouldn't have it
now.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: Appropriate hipersocket MFS size for use with SAP Apps Servers

[Ron Foster]

Alan,

I went to talk to the z/os guy to get a better understanding of what the TCP IP 
folks are wanting done.

I now have a better understanding of what is going on.

1. We have so much data flowing through the hipersocket chipid that we are 
experiencing queueing in the hipersocket.  (This is on a z196.)

2. It appears that something, either hipersocket or TCPIP, is not reacting well 
to that queueing.  It appears that is what is causing the storage creep.

3. One of the things that the TCP IP folks want us to do on the hardware side 
is to increase the maximum frame size to 64k. for this hipersocket.

4. This would normally increase the MTU size to 56k for the hipersocket.

5. If I remember properly the 56k value would exceed the SAP recommended MTU 
size of 8k.

6. The IBM z/os TCP/IP support says that the MTU size could be forced to 8k.

Anyone have any experience in forcing an MTU to 8k like this?  Any unwelcome 
side effects?

Thanks,
Ron 


Ron Foster

Baldor Electric Company

5711 R S Boreham Jr Street

Fort Smith, AR 72901

Phone:479-648-5865

Fax:479-646-5440

Email: ron.fos...@baldor.abb.com

IM Address:rfos...@baldor.com

www.baldor.com




From: Linux on 390 Port [LINUX-390@VM.MARIST.EDU] on behalf of Alan Altmark 
[alan_altm...@us.ibm.com]
Sent: Thursday, June 13, 2013 3:29 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Appropriate hipersocket MFS size for use with SAP Apps Servers

On Thursday, 06/13/2013 at 03:29 EDT, Ron Foster
ron.fos...@baldor.abb.com wrote:
 We have a bunch of SAP application servers running under z/vm. They are
all
 pointed at the same z/os 1.13 system. There are several DB2s running on
this
 z/OS system.  All the Apps servers are using the same hipersocket chpid
to
 communicate to the z/os system the same hipersocket chipid. Since going
to z/OS
 1.13, we are experiencing storage creep in our TCPIP address space.

 This hipersocket is using a 8k MTU size.  I believe this to be the SAP
 recommended size.

 Our z/os support folks are being told by their support folks that they
would
 like us to increase the MTU size from 8k to something larger.

That sounds strange, to say the least.  What logic do they give to support
the conclusion that a larger MTU will prevent storage creep?  Large MTU or
small, the path through the stack should be the same.  If you didn't have
storage creep on the earlier release with an 8K MTU, you shouldn't have it
now.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: hipersocket question for dummies (me )

[Ward, Mike S]

If you set up the below you probably have a routing problem. You can't
have the same network appear in several places on the network. The
routers won't know where to route the packets.

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
bruce.light...@its.ms.gov
Sent: Friday, January 20, 2012 3:18 PM
To: LINUX-390@VM.MARIST.EDU
Subject: hipersocket question for dummies (me )

We are having a connection issue with a couple of our linux guests that
simply proves I don't know what I'm doing AND I can't seem to RTFM
correctly

Environment is Suse 11 guests on z/VM 6 trying to connect to z/OS 1.12
on a z196,

The first 8 guests work just fine - z/OS IP address is 192.168.4.2 and
the guests are 192.168.4.xxx and all are using CHPID E8 After the 8
guests are defined, we are out of E8 triplets so we give the next 2 E9xx
triplets.
The z/OS stack has E9 defined and started as 192.168.4.3.
The 2 new guests can ping themselves but not the z/OS, z/OS can ping
itself but not the 2 new guests - the 8 guests on E8 are no problem but
no joy going to E9 .
Changing the dedicate statement for the guest to use EAxx also gets no
joy
- even though the z/OS thinks it has EA at 192.168.4.4 The redbook for
hipersockets isn't helping today - nor is the communications server
manual.

I'm sure that this is something blindingly simple but I just don't see
it - would someone please point this dba who is subbing as a sysprog in
the right direction.


From the tcpip profile for the z/os stack :
.
.
DEVICE  IUTIQDE8 MPCIPA NONR AUTORESTART
LINKHIPERE8 IPAQIDIO IUTIQDE8
DEVICE  IUTIQDE9 MPCIPA NONR AUTORESTART
LINKHIPERE9 IPAQIDIO IUTIQDE9
DEVICE  IUTIQDEA MPCIPA NONR AUTORESTART
LINKHIPEREA IPAQIDIO IUTIQDEA
.
.
HOME
  10.12.9.43 OSALINK1
  192.168.4.2HIPERE8 ;Used for DEV
  192.168.4.3HIPERE9 ;Used for DEV
  192.168.4.4HIPEREA ;Used for DEV
  192.168.5.2HIPEREB ;Used for QA
.
.
 ROUTE 10.12.9.1  255.255.255.0  =OSALINK1  MTU 4500
 ROUTE 192.168.4.1 255.255.255.0 =HIPERE8   MTU 4500
 ROUTE 192.168.4.1 255.255.255.0 =HIPERE9   MTU 4500
 ROUTE 192.168.4.1 255.255.255.0 =HIPEREA   MTU 4500
 ROUTE 192.168.5.1 255.255.255.0 =HIPEREB   MTU 4500
.
.
; Default Route - All packets to an unknown destination are routed
; through this route.
;
 ROUTE DEFAULT 10.12.9.1  OSALINK1 MTU 1500
 ROUTE 192.168.4.1HIPERE8  MTU 4500
 ROUTE 192.168.5.1HIPEREB  MTU 4500
 ROUTE 192.168.6.1HIPEREE  MTU 4500
.
.
;
 START OSALINK
 START IUTIQDE8
 START IUTIQDE9
 START IUTIQDEA
 START IUTIQDEB
.

--
For LINUX-390 subscribe / signoff / archive access instructions, send
email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

==
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity
to which they are addressed. If you have received this email in error please 
notify the system manager. This message
contains confidential information and is intended only for the individual 
named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please notify the 
sender immediately by e-mail if you
have received this e-mail by mistake and delete this e-mail from your system. 
If you are not the intended recipient
you are notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this
information is strictly prohibited.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: hipersocket question for dummies (me )

[Offer Baruch]

Hi,

i didn't understand if E8xx and E9xx are on the same chpid... i think they
are.
it seems you were on the right path but you missed something...
on z/OS you have created 3 devices that are all on the same subnet.
defining 3 routes to each Device will not help. how will z/OS know when to
use which path? in your case it always uses the first. that is why E8 keeps
working.
because you added more IP addresses to z/OS i guess that you don't mind
that E9 guests will reach z/OS using a different IP address.
That said, you can define each device group (E8, E9 etc) in a different
VLAN. Check out the DEVICE/LINK/INTERFACE statements to select the VLAN to
use.
that will allow you to use more than one subnet on that chpid.
if i got it wrong and you want all guests and z/OS to be on the same subnet
than you must add more devices to E8xx as Alan said...

Offer Baruch

On Fri, Jan 20, 2012 at 11:45 PM, Alan Altmark alan_altm...@us.ibm.comwrote:

 On Friday, 01/20/2012 at 04:38 EST, bruce.light...@its.ms.gov wrote:

  The first 8 guests work just fine - z/OS IP address is 192.168.4.2 and
 the
  guests are 192.168.4.xxx and all are using CHPID E8
  After the 8 guests are defined, we are out of E8 triplets so we give the
  next 2 E9xx triplets.
  The z/OS stack has E9 defined and started as 192.168.4.3.
  The 2 new guests can ping themselves but not the z/OS, z/OS can ping
 itself
  but not the 2 new guests - the 8 guests on E8 are no problem but no joy
  going to E9 .
  Changing the dedicate statement for the guest to use EAxx also gets no
 joy
  - even though the z/OS thinks it has EA at 192.168.4.4
  The redbook for hipersockets isn't helping today - nor is the
  communications server manual.
 
  I'm sure that this is something blindingly simple but I just don't see
 it -
  would someone please point this dba who is subbing as a sysprog in the
  right direction.

 You're right, it's simple.  That said, it's not obvious.  But since you're
 just subbing, all is forgiven.  :-)

 Each HiperSocket chpid is its own LAN segment.  They are not bridged
 together.  So the hosts using E8 have to go through a *router* (e.g.
 Linux, z/OS, z/VM) to get a host attached to E9 or EA.

 If you run out of triplets, you need to define more.

 Alan Altmark

 Senior Managing z/VM and Linux Consultant
 IBM System Lab Services and Training
 ibm.com/systems/services/labservices
 office: 607.429.3323
 mobile; 607.321.7556
 alan_altm...@us.ibm.com
 IBM Endicott

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: hipersocket question for dummies (me )

[David Kreuter]

Hi - Alan is right, of course.  Let me add a few things.
1. although I have no idea as to your shop's actual reasoning in my
experience if z/os in charge of the I/O configuration (fairly typical)
they tend to be stingy generating RDEVs (OK, UCBs) on IQD type chpids. 
I have no idea why z/os has this mentality as they often have thousands
of UCBs to handle DASD PAVing.  My practice if I can get get a hold of
the IOCP or at least influence it is to gen 255 addresses (RDEVs) on the
IQD chpids.  
Oh yeah I sort of remember - z/OS doesn't have that many TCPIP stacks to
support so genning only a few triplets almost makes sense (the same
triplets can be shared on different LPARs - again this a style decision
you need to make at your shop).

2. don't be confused by the fact you have the same LAN segment on
different CHPIDs. They're ignorant of each other. Up until the moment
the moment that one stack has two sets of hipersockets defined to it the
networks can't see each other.

3. From z/VM MAINT userid do a: 
Q CHPID E8
Q CHPID E9
this will show you the devices bolted off each chpid - could be
informative!

4. where possible I like to have only a few hipersocket IQD chpids -
hopefully one -, define a VLAN topology on top of the hipersocket
network, and go from there. It's charming.
David Kreuter

 Original Message 
Subject: Re: hipersocket question for dummies (me )
From: Offer Baruch offerbar...@gmail.com
Date: Sat, January 21, 2012 4:29 am
To: LINUX-390@VM.MARIST.EDU

Hi,

i didn't understand if E8xx and E9xx are on the same chpid... i think
they
are.
it seems you were on the right path but you missed something...
on z/OS you have created 3 devices that are all on the same subnet.
defining 3 routes to each Device will not help. how will z/OS know when
to
use which path? in your case it always uses the first. that is why E8
keeps
working.
because you added more IP addresses to z/OS i guess that you don't mind
that E9 guests will reach z/OS using a different IP address.
That said, you can define each device group (E8, E9 etc) in a different
VLAN. Check out the DEVICE/LINK/INTERFACE statements to select the VLAN
to
use.
that will allow you to use more than one subnet on that chpid.
if i got it wrong and you want all guests and z/OS to be on the same
subnet
than you must add more devices to E8xx as Alan said...

Offer Baruch

On Fri, Jan 20, 2012 at 11:45 PM, Alan Altmark
alan_altm...@us.ibm.comwrote:

 On Friday, 01/20/2012 at 04:38 EST, bruce.light...@its.ms.gov wrote:

  The first 8 guests work just fine - z/OS IP address is 192.168.4.2 and
 the
  guests are 192.168.4.xxx and all are using CHPID E8
  After the 8 guests are defined, we are out of E8 triplets so we give the
  next 2 E9xx triplets.
  The z/OS stack has E9 defined and started as 192.168.4.3.
  The 2 new guests can ping themselves but not the z/OS, z/OS can ping
 itself
  but not the 2 new guests - the 8 guests on E8 are no problem but no joy
  going to E9 .
  Changing the dedicate statement for the guest to use EAxx also gets no
 joy
  - even though the z/OS thinks it has EA at 192.168.4.4
  The redbook for hipersockets isn't helping today - nor is the
  communications server manual.
 
  I'm sure that this is something blindingly simple but I just don't see
 it -
  would someone please point this dba who is subbing as a sysprog in the
  right direction.

 You're right, it's simple. That said, it's not obvious. But since you're
 just subbing, all is forgiven. :-)

 Each HiperSocket chpid is its own LAN segment. They are not bridged
 together. So the hosts using E8 have to go through a *router* (e.g.
 Linux, z/OS, z/VM) to get a host attached to E9 or EA.

 If you run out of triplets, you need to define more.

 Alan Altmark

 Senior Managing z/VM and Linux Consultant
 IBM System Lab Services and Training
 ibm.com/systems/services/labservices
 office: 607.429.3323
 mobile; 607.321.7556
 alan_altm...@us.ibm.com
 IBM Endicott

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390
 --
 For more information on Linux on System z, visit
 http://wiki.linuxvm.org/


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX

Re: hipersocket question for dummies (me )

[Alan Altmark]

On Friday, 01/20/2012 at 04:38 EST, bruce.light...@its.ms.gov wrote:

 The first 8 guests work just fine - z/OS IP address is 192.168.4.2 and
the
 guests are 192.168.4.xxx and all are using CHPID E8
 After the 8 guests are defined, we are out of E8 triplets so we give the
 next 2 E9xx triplets.
 The z/OS stack has E9 defined and started as 192.168.4.3.
 The 2 new guests can ping themselves but not the z/OS, z/OS can ping
itself
 but not the 2 new guests - the 8 guests on E8 are no problem but no joy
 going to E9 .
 Changing the dedicate statement for the guest to use EAxx also gets no
joy
 - even though the z/OS thinks it has EA at 192.168.4.4
 The redbook for hipersockets isn't helping today - nor is the
 communications server manual.

 I'm sure that this is something blindingly simple but I just don't see
it -
 would someone please point this dba who is subbing as a sysprog in the
 right direction.

You're right, it's simple.  That said, it's not obvious.  But since you're
just subbing, all is forgiven.  :-)

Each HiperSocket chpid is its own LAN segment.  They are not bridged
together.  So the hosts using E8 have to go through a *router* (e.g.
Linux, z/OS, z/VM) to get a host attached to E9 or EA.

If you run out of triplets, you need to define more.

Alan Altmark

Senior Managing z/VM and Linux Consultant
IBM System Lab Services and Training
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

hipersocket question for dummies (me )

[Bruce . Lightsey]

We are having a connection issue with a couple of our linux guests that
simply proves I don't know what I'm doing AND I can't seem to RTFM
correctly

Environment is Suse 11 guests on z/VM 6 trying to connect to z/OS 1.12  on
a z196,

The first 8 guests work just fine - z/OS IP address is 192.168.4.2 and the
guests are 192.168.4.xxx and all are using CHPID E8
After the 8 guests are defined, we are out of E8 triplets so we give the
next 2 E9xx triplets.
The z/OS stack has E9 defined and started as 192.168.4.3.
The 2 new guests can ping themselves but not the z/OS, z/OS can ping itself
but not the 2 new guests - the 8 guests on E8 are no problem but no joy
going to E9 .
Changing the dedicate statement for the guest to use EAxx also gets no joy
- even though the z/OS thinks it has EA at 192.168.4.4
The redbook for hipersockets isn't helping today - nor is the
communications server manual.

I'm sure that this is something blindingly simple but I just don't see it -
would someone please point this dba who is subbing as a sysprog in the
right direction.


From the tcpip profile for the z/os stack :
.
.
DEVICE  IUTIQDE8 MPCIPA NONR AUTORESTART
LINKHIPERE8 IPAQIDIO IUTIQDE8
DEVICE  IUTIQDE9 MPCIPA NONR AUTORESTART
LINKHIPERE9 IPAQIDIO IUTIQDE9
DEVICE  IUTIQDEA MPCIPA NONR AUTORESTART
LINKHIPEREA IPAQIDIO IUTIQDEA
.
.
HOME
  10.12.9.43 OSALINK1
  192.168.4.2HIPERE8 ;Used for DEV
  192.168.4.3HIPERE9 ;Used for DEV
  192.168.4.4HIPEREA ;Used for DEV
  192.168.5.2HIPEREB ;Used for QA
.
.
 ROUTE 10.12.9.1  255.255.255.0  =OSALINK1  MTU 4500
 ROUTE 192.168.4.1 255.255.255.0 =HIPERE8   MTU 4500
 ROUTE 192.168.4.1 255.255.255.0 =HIPERE9   MTU 4500
 ROUTE 192.168.4.1 255.255.255.0 =HIPEREA   MTU 4500
 ROUTE 192.168.5.1 255.255.255.0 =HIPEREB   MTU 4500
.
.
; Default Route - All packets to an unknown destination are routed
; through this route.
;
 ROUTE DEFAULT 10.12.9.1  OSALINK1 MTU 1500
 ROUTE 192.168.4.1HIPERE8  MTU 4500
 ROUTE 192.168.5.1HIPEREB  MTU 4500
 ROUTE 192.168.6.1HIPEREE  MTU 4500
.
.
;
 START OSALINK
 START IUTIQDE8
 START IUTIQDE9
 START IUTIQDEA
 START IUTIQDEB
.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

z/VM - SLES11 Hipersocket issue

[Jose Raul Baron]

Hi folks, we are facing a problem regarding hipersockets on SLES11
SP1installed under z/VM 5.4

- We have 2 SLES10 + 1 SLES11 running under z/VM 5.4. The Hipersocketnetwork
has address 192.0.1.x
- All SLESes ping each other successfully
- All SLES10s ping z/VM 192.0.1.x address successfully.
- However our SLES11, despite pinging the other SLES10s in net
192.0.1.x fails on pinging z/VM 192.0.1.x address.

That is, it seems like z/VM TCPIP can ping every SLES10 Hipersocket
but can't ping the SLES11 hipersocket.

I tried to attach a jpg picture explaining this but the system didn't allow
me to.

Has anyone had this problem, and if so, has anyone solved it some way?

Thanks in advance,

Raul Baron

--

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: z/VM - SLES11 Hipersocket issue

[Rob van der Heij]

On Wed, Oct 5, 2011 at 9:15 AM, Jose Raul Baron jba...@calculo-sa.es wrote:
 Hi folks, we are facing a problem regarding hipersockets on SLES11
 SP1installed under z/VM 5.4

 - We have 2 SLES10 + 1 SLES11 running under z/VM 5.4. The Hipersocketnetwork
 has address 192.0.1.x
 - All SLESes ping each other successfully
 - All SLES10s ping z/VM 192.0.1.x address successfully.
 - However our SLES11, despite pinging the other SLES10s in net
 192.0.1.x fails on pinging z/VM 192.0.1.x address.

 That is, it seems like z/VM TCPIP can ping every SLES10 Hipersocket
 but can't ping the SLES11 hipersocket.

Did you check the TCPIP console log for errors? It sounds a lot like
APAR PK80882 (and be aware the PTF for that is in error...)

Rob

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

HiperSocket Advice

[Lionel Dyck]

What is the recommendation or general practice regarding hipersocket
addresses and dns?

Do you register the hipersocket address in the dns or stick with
referencing it via the octet?

Thanks


 Lionel B. Dyck 
 z/Linux Specialist
 IBM Corporation
 Global Technology Services - Kaiser Account
 Work: 925-926-5332
 E-Mail: ld...@us.ibm.com
 AIM: lbdyck | Yahoo IM: lbdyck | GTalk:
 lbdyck



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: HiperSocket Advice

[Mauro Souza]

I generally use /etc/hosts to set a name, and refer to the name.
It's easier to change a single entry on /etc/hosts than changing lots of
config files in all applications.
Using DNS increases latency, complication, and as long as you have only a
dozen or more machines, handling the hosts file isn't that hard.

Mauro
http://mauro.limeiratem.com - registered Linux User: 294521
Scripture is both history, and a love letter from God.


On Mon, Dec 21, 2009 at 1:06 PM, Lionel Dyck ld...@us.ibm.com wrote:

 What is the recommendation or general practice regarding hipersocket
 addresses and dns?

 Do you register the hipersocket address in the dns or stick with
 referencing it via the octet?

 Thanks


  Lionel B. Dyck 
  z/Linux Specialist
  IBM Corporation
  Global Technology Services - Kaiser Account
  Work: 925-926-5332
  E-Mail: ld...@us.ibm.com
  AIM: lbdyck | Yahoo IM: lbdyck | GTalk:
  lbdyck



 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
 visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: HiperSocket Advice

[Marcy Cortes]

We're supposed to have every IP address in our DNS.   And to get in to DNS, you 
go through security planning.
Your company may have a different policy.


Marcy 
This message may contain confidential and/or privileged information. If you 
are not the addressee or authorized to receive this for the addressee, you must 
not use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of Lionel 
Dyck
Sent: Monday, December 21, 2009 7:07 AM
To: LINUX-390@VM.MARIST.EDU
Subject: [LINUX-390] HiperSocket Advice

What is the recommendation or general practice regarding hipersocket
addresses and dns?

Do you register the hipersocket address in the dns or stick with
referencing it via the octet?

Thanks


 Lionel B. Dyck 
 z/Linux Specialist
 IBM Corporation
 Global Technology Services - Kaiser Account
 Work: 925-926-5332
 E-Mail: ld...@us.ibm.com
 AIM: lbdyck | Yahoo IM: lbdyck | GTalk:
 lbdyck



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: HiperSocket Advice

[David Boyes]

On 12/21/09 10:06 AM, Lionel Dyck ld...@us.ibm.com wrote:

 What is the recommendation or general practice regarding hipersocket
 addresses and dns?

Same as any other address: put it in the DNS with a unique name, eg
host-hsi1.foo.bar.com

 
 Do you register the hipersocket address in the dns or stick with
 referencing it via the octet?

It's been 30+ years since the DNS was introduced. It's time.

-- db

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

SLeS10 SP1 - hipersocket via YAST

[Ceruti, Gerard G]

HI All

Anyone got a presentation or document that covers the creation of
Hipersockets using YAST ?, 
We have done it via command line but for completeness would like to cove
the YAST option as well.


Gerard Ceruti | Technical Specialist |Mainframe Systems  | Standard Bank
South Africa |Riverclub Computer Centre 44 Borrowdale Ave | RiverClub |
(Work) +27 11 700 1476 (Mobile) +27 83 252 5300 | Email:
mailto:gerard.cer...@standardbank.co.za | Inspired. Motivated. Involved.



_

Standard Bank email Disclaimer and confidentiality note

This e-mail, its attachments and any rights attaching hereto are, unless the 
content clearly indicates otherwise, the property of 
Standard Bank Group Limited and its subsidiaries. It is confidential, private 
and intended for only the addressee. 

Should you not be the addressee and receive this e-mail by mistake, kindly 
notify the sender, and delete this e-mail immediately.
Do not disclose or use it in any way. Views and opinions expressed in this 
e-mail are those of the sender unless clearly stated as 
those of Standard Bank Group. 

Standard Bank Group accepts no liability for any loss or damages howsoever 
incurred, or suffered, resulting, or arising, 
from the use of this email or its attachments. 

Standard Bank Group does not warrant the integrity of this e-mail nor that it 
is free of errors, viruses, interception or interference. 

Licensed divisions of the Standard Bank Group are authorised financial services 
providers in terms of the Financial Advisory and 
Intermediary Services Act, No 37 of 2002 (FAIS).

For information about the Standard Bank Group visit our website 
http://www.standardbank.com


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: SLeS10 SP1 - hipersocket via YAST

[Mark Post]

 On 7/7/2009 at  7:50 AM, Ceruti, Gerard G 
 gerard.cer...@standardbank.co.za
wrote: 
 HI All
 
 Anyone got a presentation or document that covers the creation of
 Hipersockets using YAST ?, 
 We have done it via command line but for completeness would like to cove
 the YAST option as well.

yast - Network Devices - Network Card - Traditional Method - Next
Select the first device number of three that you want to use, then - Edit to 
configure it.
If you're on SLES10 SP2, on the first screen for configuring, you'll need to 
manually add the busids of the three devices so that the configuration file 
gets created correctly.  There is a fix for that coming out that will 
pre-populate that field the way it used to, but I'm not sure when.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: SLeS10 SP1 - hipersocket via YAST

[Ceruti, Gerard G]

Thanks Mark

Regards
Gerard Ceruti
may the 'z' be with you
SharePoint (internal)


-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Mark Post
Sent: 07 July 2009 18:43
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLeS10 SP1 - hipersocket via YAST

 On 7/7/2009 at  7:50 AM, Ceruti, Gerard G
gerard.cer...@standardbank.co.za
wrote: 
 HI All
 
 Anyone got a presentation or document that covers the creation of
 Hipersockets using YAST ?, 
 We have done it via command line but for completeness would like to
cove
 the YAST option as well.

yast - Network Devices - Network Card - Traditional Method - Next
Select the first device number of three that you want to use, then -
Edit to configure it.
If you're on SLES10 SP2, on the first screen for configuring, you'll
need to manually add the busids of the three devices so that the
configuration file gets created correctly.  There is a fix for that
coming out that will pre-populate that field the way it used to, but I'm
not sure when.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
_

Standard Bank email Disclaimer and confidentiality note

This e-mail, its attachments and any rights attaching hereto are, unless the 
content clearly indicates otherwise, the property of 
Standard Bank Group Limited and its subsidiaries. It is confidential, private 
and intended for only the addressee. 

Should you not be the addressee and receive this e-mail by mistake, kindly 
notify the sender, and delete this e-mail immediately.
Do not disclose or use it in any way. Views and opinions expressed in this 
e-mail are those of the sender unless clearly stated as 
those of Standard Bank Group. 

Standard Bank Group accepts no liability for any loss or damages howsoever 
incurred, or suffered, resulting, or arising, 
from the use of this email or its attachments. 

Standard Bank Group does not warrant the integrity of this e-mail nor that it 
is free of errors, viruses, interception or interference. 

Licensed divisions of the Standard Bank Group are authorised financial services 
providers in terms of the Financial Advisory and 
Intermediary Services Act, No 37 of 2002 (FAIS).

For information about the Standard Bank Group visit our website 
http://www.standardbank.com


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket

[John Schnitzler Jr]

Are Hipersocket devices supposed to show up in Yast as 3 different
devices,
where an OSA adapter shows up as 1?SLES10 SP2

IBM OSA Express Network card (0.0.1d00)│
IBM Hipersocket (0.0.0704) │Not configured
  │
IBM Hipersocket (0.0.0705) │Not configured
  │
IBM Hipersocket (0.0.0706) │Not configured


Mark, Yes, until they are configured, the OSA is the same way.

John,

Re: Hipersocket

[Mark Pace]

Not having any luck with Hipersockets in SLES10, working great in SLES9
Does this look correct for a Hipersocket device in SLES10?

sles002:/etc/sysconfig/hardware # cat hwcfg-qeth-bus-ccw-0.0.0704
CCW_CHAN_IDS=''
CCW_CHAN_MODE=''
CCW_CHAN_NUM='3'
LCS_LANCMD_TIMEOUT=''
MODULE=''
MODULE_OPTIONS=''
QETH_IPA_TAKEOVER='0'
QETH_LAYER2_SUPPORT='0'
QETH_OPTIONS=''
SCRIPTDOWN='hwdown-ccw'
SCRIPTUP='hwup-ccw'
SCRIPTUP_ccw='hwup-ccw'
SCRIPTUP_ccwgroup='hwup-qeth'
STARTMODE='auto'

I'm getting these messages at startup.
Waiting for mandatory devices:  qeth-bus-ccw-0.0.0704 qeth-bus-ccw-0.0.0705
qeth-bus-ccw-0.0.0706 __NSC__
18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
qeth-bus-ccw-0.0.0704   No interface found
[1A..failedqeth-bus-ccw-0.0.0705   No interface found
[1A..failedqeth-bus-ccw-0.0.0706   No interface found
[1A..failedSetting up service network  .  .  .  .  .  .  .  .  .  .  .  .  .
 .  .  ...failed

And I've verified that the devices are connected to the guest.
2009/3/31 John Schnitzler Jr jnsch...@us.ibm.com


 Are Hipersocket devices supposed to show up in Yast as 3 different
 devices,
 where an OSA adapter shows up as 1?SLES10 SP2

 IBM OSA Express Network card (0.0.1d00)│
 IBM Hipersocket (0.0.0704) │Not configured
   │
 IBM Hipersocket (0.0.0705) │Not configured
   │
 IBM Hipersocket (0.0.0706) │Not configured


 Mark, Yes, until they are configured, the OSA is the same way.

 John,




-- 
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket

[roger . shipman]

Look at this manual..don't worry about the title..It has a great write up 
and directions on HIPER.
We just went from SLES9 th 10 and I use the instructions:

 http://www.redbooks.ibm.com/redpieces/pdfs/sg246847.pdf


example:
  echo 0.0.b500,0.0.b501,0.0.b502  /sys/bus/ccwgroup/drivers/qeth/group 
  echo 1  /sys/devices/qeth/0.0.b500/online 
 . cat /sys/devices/qeth/0.0.b500/if_name 
 . response should be   hsi0 
 ifconfig hsi0 xx.xxx.xxx.xxx netmask 255.255.255.0 mtu 32768 up 



mpac...@gmail.com 
Sent by: LINUX-390@VM.MARIST.EDU
03/31/2009 12:42 PM
Please respond to
LINUX-390@VM.MARIST.EDU


To
LINUX-390@VM.MARIST.EDU
cc

Subject
Re: Hipersocket






Not having any luck with Hipersockets in SLES10, working great in SLES9
Does this look correct for a Hipersocket device in SLES10?

sles002:/etc/sysconfig/hardware # cat hwcfg-qeth-bus-ccw-0.0.0704
CCW_CHAN_IDS=''
CCW_CHAN_MODE=''
CCW_CHAN_NUM='3'
LCS_LANCMD_TIMEOUT=''
MODULE=''
MODULE_OPTIONS=''
QETH_IPA_TAKEOVER='0'
QETH_LAYER2_SUPPORT='0'
QETH_OPTIONS=''
SCRIPTDOWN='hwdown-ccw'
SCRIPTUP='hwup-ccw'
SCRIPTUP_ccw='hwup-ccw'
SCRIPTUP_ccwgroup='hwup-qeth'
STARTMODE='auto'

I'm getting these messages at startup.
Waiting for mandatory devices:  qeth-bus-ccw-0.0.0704 
qeth-bus-ccw-0.0.0705
qeth-bus-ccw-0.0.0706 __NSC__
18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
qeth-bus-ccw-0.0.0704   No interface found
[1A..failedqeth-bus-ccw-0.0.0705   No interface found
[1A..failedqeth-bus-ccw-0.0.0706   No interface found
[1A..failedSetting up service network  .  .  .  .  .  .  .  .  .  .  .  . 
.
 .  .  ...failed

And I've verified that the devices are connected to the guest.
2009/3/31 John Schnitzler Jr jnsch...@us.ibm.com


 Are Hipersocket devices supposed to show up in Yast as 3 different
 devices,
 where an OSA adapter shows up as 1?SLES10 SP2

 IBM OSA Express Network card (0.0.1d00)│
 IBM Hipersocket (0.0.0704) │Not configured
   │
 IBM Hipersocket (0.0.0705) │Not configured
   │
 IBM Hipersocket (0.0.0706) │Not configured


 Mark, Yes, until they are configured, the OSA is the same way.

 John,




-- 
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390



If you are not the intended addressee, please inform us immediately that you 
have received this e-mail in error, and delete it. We thank you for your 
cooperation.  

Re: Hipersocket

[Mark Post]

 On 3/31/2009 at  3:42 PM, Mark Pace mpac...@gmail.com wrote: 
 Not having any luck with Hipersockets in SLES10, working great in SLES9
 Does this look correct for a Hipersocket device in SLES10?

No.  There was a regression (I can't quite call it a bug) in SP2 where going in 
to YaST to configure an interface, the device numbers were not pre-populated as 
they had been previously.  There's a fix for that coming out, but I'm not sure 
just when.

 sles002:/etc/sysconfig/hardware # cat hwcfg-qeth-bus-ccw-0.0.0704
 CCW_CHAN_IDS=''

You need to have this look like this:
CCW_CHAN_IDS=''0.0.0704 0.0.0705 0.0.0706

And only have the one for 0.0.0704, not the other two.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket

[Ron Foster]

The ccwchanids need to be filled in.  Sles9 would autosense the three devices 
associated with the group device,  sles10 does not.

You actually have to put in the 0.0704,0.0.0705,0.0.0706 between the quotes.

Ron
Sent via BlackBerry by ATT

-Original Message-
From: roger.ship...@daimler.com roger.ship...@daimler.com

Date: Tue, 31 Mar 2009 14:47:49 
To: LINUX-390@VM.MARIST.EDULINUX-390@VM.MARIST.EDU
Subject: Re: Hipersocket


Look at this manual..don't worry about the title..It has a great write up 
and directions on HIPER.
We just went from SLES9 th 10 and I use the instructions:

 http://www.redbooks.ibm.com/redpieces/pdfs/sg246847.pdf


example:
  echo 0.0.b500,0.0.b501,0.0.b502  /sys/bus/ccwgroup/drivers/qeth/group 
  echo 1  /sys/devices/qeth/0.0.b500/online 
 . cat /sys/devices/qeth/0.0.b500/if_name 
 . response should be   hsi0 
 ifconfig hsi0 xx.xxx.xxx.xxx netmask 255.255.255.0 mtu 32768 up 



mpac...@gmail.com 
Sent by: LINUX-390@VM.MARIST.EDU
03/31/2009 12:42 PM
Please respond to
LINUX-390@VM.MARIST.EDU


To
LINUX-390@VM.MARIST.EDU
cc

Subject
Re: Hipersocket






Not having any luck with Hipersockets in SLES10, working great in SLES9
Does this look correct for a Hipersocket device in SLES10?

sles002:/etc/sysconfig/hardware # cat hwcfg-qeth-bus-ccw-0.0.0704
CCW_CHAN_IDS=''
CCW_CHAN_MODE=''
CCW_CHAN_NUM='3'
LCS_LANCMD_TIMEOUT=''
MODULE=''
MODULE_OPTIONS=''
QETH_IPA_TAKEOVER='0'
QETH_LAYER2_SUPPORT='0'
QETH_OPTIONS=''
SCRIPTDOWN='hwdown-ccw'
SCRIPTUP='hwup-ccw'
SCRIPTUP_ccw='hwup-ccw'
SCRIPTUP_ccwgroup='hwup-qeth'
STARTMODE='auto'

I'm getting these messages at startup.
Waiting for mandatory devices:  qeth-bus-ccw-0.0.0704 
qeth-bus-ccw-0.0.0705
qeth-bus-ccw-0.0.0706__NSC__
18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
qeth-bus-ccw-0.0.0704   No interface found
[1A..failedqeth-bus-ccw-0.0.0705   No interface found
[1A..failedqeth-bus-ccw-0.0.0706   No interface found
[1A..failedSetting up service network  .  .  .  .  .  .  .  .  .  .  .  . 
.
 .  .  ...failed

And I've verified that the devices are connected to the guest.
2009/3/31 John Schnitzler Jr jnsch...@us.ibm.com


 Are Hipersocket devices supposed to show up in Yast as 3 different
 devices,
 where an OSA adapter shows up as 1?SLES10 SP2

 IBM OSA Express Network card (0.0.1d00)│
 IBM Hipersocket (0.0.0704) │Not configured
   │
 IBM Hipersocket (0.0.0705) │Not configured
   │
 IBM Hipersocket (0.0.0706) │Not configured


 Mark, Yes, until they are configured, the OSA is the same way.

 John,




-- 
Mark Pace
Mainline Information Systems
1700 Summit Lake Drive
Tallahassee, FL. 32317

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or 
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390



If you are not the intended addressee, please inform us immediately that you 
have received this e-mail in error, and delete it. We thank you for your 
cooperation.  

Re: Hipersocket

[Kyle Black]

Mark,

I haven't specifically worked on a Hipersocket in SLES10 yet, the few
machines I have that utilize them are not yet upgraded from SLES9-10
yet.  BUT I have had the exact same problem as you with regular QETH
devices.  It seems that YaST doesn't always properly configure and then
hwup the device after setup, so I wrote a script to setup my devices for
me.  In my case I blamed this on the fact that I've mainly been working
with shared Read-Only root machines and the one R/W machine I tried
adding a qeth device to with YaST succeeded.

So, for you to get setup with what you have there..

In /etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.0704...

CCW_CHAN_IDS='0.0.0704 0.0.0705 0.0.0706'
CCW_CHAN_MODE='dontcare'

Then just make sure your
/etc/sysconfig/hardware/ifcfg-hsi-bus-ccw-0.0.0704 is properly
configured, for me YaST had this part correct after I had attempted to
set it up if I remember right.

Finally, just give it a:

hwup hsi-bus-ccw-0.0.0704

The script I wrote just does all the above with sed and some
partially-configured template files.  Hopefully that works for you.  I'm
by no means an expert on any of this, I just went back to my SLES9
machines and did some comparison until I got a device up and running
manually.


Kyle Black


Mark Pace wrote:
 Not having any luck with Hipersockets in SLES10, working great in SLES9
 Does this look correct for a Hipersocket device in SLES10?

 sles002:/etc/sysconfig/hardware # cat hwcfg-qeth-bus-ccw-0.0.0704
 CCW_CHAN_IDS=''
 CCW_CHAN_MODE=''
 CCW_CHAN_NUM='3'
 LCS_LANCMD_TIMEOUT=''
 MODULE=''
 MODULE_OPTIONS=''
 QETH_IPA_TAKEOVER='0'
 QETH_LAYER2_SUPPORT='0'
 QETH_OPTIONS=''
 SCRIPTDOWN='hwdown-ccw'
 SCRIPTUP='hwup-ccw'
 SCRIPTUP_ccw='hwup-ccw'
 SCRIPTUP_ccwgroup='hwup-qeth'
 STARTMODE='auto'

 I'm getting these messages at startup.
 Waiting for mandatory devices:  qeth-bus-ccw-0.0.0704 qeth-bus-ccw-0.0.0705
 qeth-bus-ccw-0.0.0706 __NSC__
 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
 qeth-bus-ccw-0.0.0704   No interface found
 [1A..failedqeth-bus-ccw-0.0.0705   No interface found
 [1A..failedqeth-bus-ccw-0.0.0706   No interface found
 [1A..failedSetting up service network  .  .  .  .  .  .  .  .  .  .  .  .  .
  .  .  ...failed

 And I've verified that the devices are connected to the guest.
 2009/3/31 John Schnitzler Jr jnsch...@us.ibm.com

   
 Are Hipersocket devices supposed to show up in Yast as 3 different
   
 devices,
 
 where an OSA adapter shows up as 1?SLES10 SP2
   
 IBM OSA Express Network card (0.0.1d00)│
 IBM Hipersocket (0.0.0704) │Not configured
  │
 IBM Hipersocket (0.0.0705) │Not configured
  │
 IBM Hipersocket (0.0.0706) │Not configured
   
 Mark, Yes, until they are configured, the OSA is the same way.

 John,
 




   

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket MTU size for DB2 Connect ?

[Joerg Maier]

Hi,

For Hipersockets and SAP/db2 connect transactional workloads the default
MTU of 8k is suggested. Keep in mind to change TCPRCVBUFRSIZE and
TCPSENDBFRSIZE in z/OS TCPIP settings as well as net.ipv4.tcp_wmem in
zLinux accordingly. For performance reasons, it is suggested to increase
qeth buffer count for the HiperSockets devices as well.

You can see some of this information in the recent redbook draft (p39 - 47):
http://www.redbooks.ibm.com/redpieces/abstracts/sg246847.html

Regards, Joerg

Joerg Maier
Developer
IBM System z
SAP AG
Raiffeisenring 45
68789 St. Leon-Rot Germany
T: 06227-7-44027
F: 06227-78-46257
mailto:joerg.ma...@sap.com
www.sap.com


Rich Smrcina wrote:

Plan to make the MTU size about the average size of the result set
that application
returns.  That will probably be very difficult to determine, but
probably the easiest
way to find out will be to ask the developers how large the queries
typically are.  Of
course there will be variations and it will be prudent to ask if
applications are
planned that will return larger result sets.

If they are larger than 64K, then your task is certain.

If they return a few small rows (it's more transactional) then a
smaller MTU may be best.

bruce.light...@its.ms.gov wrote:

We are just now setting up our first hipersocket connection(s) from z/VM
and linux to z/OS and will primarily use this first cut for DB2
connect to
talk to DB2 on z/OS. Does anyone have a guide for the MTU size? (
redbook,
whitepaper, etc )

Thanks,

Bruce Lightsey
Mississippi Dept. of Information Technology Services
301 N. Lamar St., Suite 508
Jackson, Ms 39201-1495
(601) 359-2644  voice   (601) 359-1394   fax
www.its.ms.gov   www.ms.gov
mailto:bruce.light...@its.ms.gov


--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
http://www.linkedin.com/in/richsmrcina

Catch the WAVV!  http://www.wavv.org
WAVV 2009 - Orlando, FL - May 15-19, 2009

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390
or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Hipersocket MTU size for DB2 Connect ?

[Bruce . Lightsey]

We are just now setting up our first hipersocket connection(s) from z/VM
and linux to z/OS and will primarily use this first cut for DB2 connect to
talk to DB2 on z/OS. Does anyone have a guide for the MTU size? ( redbook,
whitepaper, etc )

Thanks,

Bruce Lightsey
Mississippi Dept. of Information Technology Services
301 N. Lamar St., Suite 508
Jackson, Ms 39201-1495
(601) 359-2644  voice   (601) 359-1394   fax
www.its.ms.gov   www.ms.gov
mailto:bruce.light...@its.ms.gov

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket MTU size for DB2 Connect ?

[Mark Post]

 On 2/23/2009 at  3:50 PM, bruce.light...@its.ms.gov wrote: 
 We are just now setting up our first hipersocket connection(s) from z/VM
 and linux to z/OS and will primarily use this first cut for DB2 connect to
 talk to DB2 on z/OS. Does anyone have a guide for the MTU size? ( redbook,
 whitepaper, etc )

How about HiperSockets Implementation Guide, SG24-6816-01 ?  The size you 
pick is going to depend on the general size of the frames your application is 
sending/receiving.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket MTU size for DB2 Connect ?

[Rich Smrcina]

Plan to make the MTU size about the average size of the result set that 
application
returns.  That will probably be very difficult to determine, but probably the 
easiest
way to find out will be to ask the developers how large the queries typically 
are.  Of
course there will be variations and it will be prudent to ask if applications 
are
planned that will return larger result sets.

If they are larger than 64K, then your task is certain.

If they return a few small rows (it's more transactional) then a smaller MTU 
may be best.

bruce.light...@its.ms.gov wrote:

We are just now setting up our first hipersocket connection(s) from z/VM
and linux to z/OS and will primarily use this first cut for DB2 connect to
talk to DB2 on z/OS. Does anyone have a guide for the MTU size? ( redbook,
whitepaper, etc )

Thanks,

Bruce Lightsey
Mississippi Dept. of Information Technology Services
301 N. Lamar St., Suite 508
Jackson, Ms 39201-1495
(601) 359-2644  voice   (601) 359-1394   fax
www.its.ms.gov   www.ms.gov
mailto:bruce.light...@its.ms.gov


--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
http://www.linkedin.com/in/richsmrcina

Catch the WAVV!  http://www.wavv.org
WAVV 2009 - Orlando, FL - May 15-19, 2009

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

HiperSocket Performance

[Rakoczy, Dave]

Hello all,
 
We are a longtime zOS shop taking the plunge into the zVM / zLinux
(SUSE 10SP2) world.  We had never implemented HiperSockets in our zOS
environment so our experience with this technology is rather limited.
HiperSockets were implemented specifically to support our desire to take
advantage of  FDR/Upstreams ability to interface with our zOS tape
management tools.
 
During the last week or so we've been testing the different
FDR/Upstreams backup and restore processes (including the RMAN option).
The backup and restore processes work as advertised, but we are looking
for better throughput times for these processes.
 
Currently the HiperSocket channel is defined in the I/O Gen as having a
Maximum Frame Size of 16 KB, the MTU size on both the zOS and z/linux
interfaces is set to 8192 (see Below).   The backups are going to our
VTS which is Ficon attached to the Mainframe.  
 
DevName: IUTIQDF4  DevType: MPCIPA 
  DevStatus: Ready CfgRouter: Non  ActRouter: Non  
  LnkName: HIPR2 LnkType: IPAQIDIOLnkStatus: Ready 
NetNum: n/a  QueSize: n/a  
IpBroadcastCapability: No  
ArpOffload: YesArpOffloadInfo: Yes 
ActMtu: 8192   
ReadStorage: GLOBAL (2048K)
SecClass: 255  MonSysplex: No  
IQDMultiWrite: Disabled
  BSD Routing Parameters:  
MTU Size: 8192  Metric: 00 
DestAddr: 0.0.0.0   SubnetMask: 255.255.255.0  
  Multicast Specific:   
 
   
 
hsi0  Link encap:Ethernet  HWaddr 00:00:00:00:00:00
  inet addr:192.0.1.5  Bcast:192.0.1.255  Mask:255.255.255.0
  inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
  UP BROADCAST RUNNING NOARP MULTICAST  MTU:8192  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 b)  TX bytes:168 (168.0 b)

 
With the above settings I'm seeing throughput in the area of 15-18 Mb
per second.  
 
 
I've spent the past few days scouring these archives looking for what
others have done.  I found a few threads that addressed HiperSocket
throughput speeds between zOS and zLinux, but were using FTP as the
benchmark utility.  I have a window this weekend where I can put in a
I/O Gen change for the Maximum Frame Size on the HiperSocket channel
define (hopefully I'm on the right track here).  
 
So, the question I'm posing is : If you are using HiperSockets to
support FDR/Upstream, in your experience where did you find the
performance throughput sweet spot?
 
Thanks in advance for any input you may relay.
 
 

David Rakoczy 
Operating Systems Programmer
Thermo Fisher Scientific

He who laughs last probably made a backup. 

 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: HiperSocket Performance

[Adam Thornton]

On Jan 15, 2009, at 8:40 AM, Rakoczy, Dave wrote:


I've spent the past few days scouring these archives looking for what
others have done.  I found a few threads that addressed HiperSocket
throughput speeds between zOS and zLinux, but were using FTP as the
benchmark utility.  I have a window this weekend where I can put in a
I/O Gen change for the Maximum Frame Size on the HiperSocket channel
define (hopefully I'm on the right track here).

So, the question I'm posing is : If you are using HiperSockets to
support FDR/Upstream, in your experience where did you find the
performance throughput sweet spot?


What does FDR/Upstream use as a tape block size?  Most of the backup
software I'm familiar with uses 32k or 64k chunks, so if you can set
your frame size to match, that's probably ideal (assuming that much or
most of your Hipersocket traffic *is* backup blocks).

If your traffic is dominated by bulk transfers (like backup blocks)
rather than interactive traffic, then the larger frame and larger MTU
the better (unless you're in a *really* memory starved environment,
but if you are this probably isn't going to be your first
bottleneck).  How long till the next-but-one window?  Try something
different this weekend, and measure it, would be my advice.  Go back
to the other one if it's worse, or try a third one, at your next
opportunity (it is unlikely, I think, to get enormously faster or
slower, presuming you're not doing silly things with MTU or frame
size; 576 byte MTUs, for instance, did make sense for interactive
traffic in the days of 2400 baud modems, but not so much now).

Adam

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: HiperSocket Performance

[David Boyes]

For bulk data transfer, make the MTU size as large as possible, and make
your packet sizes at least 40 bytes smaller than the maximum MTU to avoid
fragmentation of data packets. That allows space for the TCP header on each
packet.

Note that this will affect interactive response, so it's probably not a good
idea to try to share the same connection for interactive access and bulk
transfer like backups.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: HiperSocket Performance

[Rakoczy, Dave]

zLinux assigns the MTU size according to the IQD CHPID definition.  

For sake of discussion lets say I set the CHPID to a Max Frame Size of
64K, that would give me an MTU size of 56K according to the Doc.

Where can I control the size of the packets I'll send across the
interface?  In the Tape Blocksize / Record length as alluded to in the
Adam's previous note?

Sorry for all the questions... But I've got to learn this stuff
somewhere.


David Rakoczy
 


-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
David Boyes
Sent: Thursday, January 15, 2009 10:07 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: HiperSocket Performance

For bulk data transfer, make the MTU size as large as possible, and make
your packet sizes at least 40 bytes smaller than the maximum MTU to
avoid fragmentation of data packets. That allows space for the TCP
header on each packet.

Note that this will affect interactive response, so it's probably not a
good idea to try to share the same connection for interactive access and
bulk transfer like backups.

--
For LINUX-390 subscribe / signoff / archive access instructions, send
email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: HiperSocket Performance

[Mark Post]

 On 1/15/2009 at 10:35 AM, Rakoczy, Dave dave.rako...@thermofisher.com
wrote: 
-snip-
 Sorry for all the questions... But I've got to learn this stuff
 somewhere.

No need to apologize.  The reason this mailing list exists in the first place 
is to share knowledge.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: HiperSocket Performance

[Rakoczy, Dave]

Doing an inquiry on the tape from the tape management system shows me
the following:

General Data 
 Volume Serial. . . : 163738 
 Alternate Volume . :
 Media type   . . . : 3490-36X2  
 Record Format. . . : VB 
 Record Length. . . : 32756  
 Block Size   . . . : 229376

My next window to do a GEN change (management will not allow dynamic I/O
Changes) is the 3rd weekend of Feb.  I wish I had the downtime window to
make the change, run some test, change to a different frame size, run
additional test and so on, I'd do that.  The change I'll implement this
weekend I'll need to live with for the next month, that's why I'm
looking for what others have experienced.

Yes, this HiperSocket interface will be dedicated to Bulk Transfers,
specifically our backups. 


 


 


-Original Message-
From: Linux on 390 Port [mailto:linux-...@vm.marist.edu] On Behalf Of
Adam Thornton
Sent: Thursday, January 15, 2009 9:56 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: HiperSocket Performance

On Jan 15, 2009, at 8:40 AM, Rakoczy, Dave wrote:

 I've spent the past few days scouring these archives looking for what 
 others have done.  I found a few threads that addressed HiperSocket 
 throughput speeds between zOS and zLinux, but were using FTP as the 
 benchmark utility.  I have a window this weekend where I can put in a 
 I/O Gen change for the Maximum Frame Size on the HiperSocket channel 
 define (hopefully I'm on the right track here).

 So, the question I'm posing is : If you are using HiperSockets to 
 support FDR/Upstream, in your experience where did you find the 
 performance throughput sweet spot?

What does FDR/Upstream use as a tape block size?  Most of the backup
software I'm familiar with uses 32k or 64k chunks, so if you can set
your frame size to match, that's probably ideal (assuming that much or
most of your Hipersocket traffic *is* backup blocks).

If your traffic is dominated by bulk transfers (like backup blocks)
rather than interactive traffic, then the larger frame and larger MTU
the better (unless you're in a *really* memory starved environment, but
if you are this probably isn't going to be your first bottleneck).  How
long till the next-but-one window?  Try something different this
weekend, and measure it, would be my advice.  Go back to the other one
if it's worse, or try a third one, at your next opportunity (it is
unlikely, I think, to get enormously faster or slower, presuming you're
not doing silly things with MTU or frame size; 576 byte MTUs, for
instance, did make sense for interactive traffic in the days of 2400
baud modems, but not so much now).

Adam

--
For LINUX-390 subscribe / signoff / archive access instructions, send
email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: HiperSocket Performance

[Mark Perry]

Rakoczy, Dave wrote:
 zLinux assigns the MTU size according to the IQD CHPID definition.

 For sake of discussion lets say I set the CHPID to a Max Frame Size of
 64K, that would give me an MTU size of 56K according to the Doc.

 Where can I control the size of the packets I'll send across the
 interface?  In the Tape Blocksize / Record length as alluded to in the
 Adam's previous note?

 Sorry for all the questions... But I've got to learn this stuff
 somewhere.

Hi Dave,
others had already, carefully, suggested increasing the Frame-Size/MTU
which may buy you some performance depending on the application's TCP/IP
usage (streaming/transactional, etc.)

We have seen in testing that the 8KB MTU is optimal for a wide range of
application types. But you may want to tune for the absolute most
bang-for-the-buck, which usually only works if you dedicate to one
application type.

Once you get past setting your MTU, you should then consider TCP/IP tuning:

On z/OS
TCPCONFIG TCPRCVB xx TCPSENDB xx

On z/Linux
in /etc/sysctl.conf:
net.ipv4.tcp_rmem =   
net.ipv4.tcp_wmem =   
(set via the sysctl command, read man page)

Also in the config files for your interfaces you can increase the number
of QDIO buffers.

/etc/sysconfig/hardware/hwcfg-qeth-bus-ccw-0.0.
add a line like:
QETH_OPTIONS=buffer_count=xxx

The above can be verified using lsqeth.

I have not given any exact values because everyones configurations
(applications, hardware) will vary, suffice to say that the default
values for all of the above are on the low side if you are aiming for
higher performance.

Also take care because these values will effect *ALL* of your TCP/IP
applications not just the new one you are implementing.

mark

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: HiperSocket Performance

[Adam Thornton]

On Jan 15, 2009, at 9:35 AM, Rakoczy, Dave wrote:


zLinux assigns the MTU size according to the IQD CHPID definition.

For sake of discussion lets say I set the CHPID to a Max Frame Size of
64K, that would give me an MTU size of 56K according to the Doc.

Where can I control the size of the packets I'll send across the
interface?  In the Tape Blocksize / Record length as alluded to in the
Adam's previous note?



You can set the MTU manually with, say,

ifconfig hsi0 mtu 56000

If the guest is smart enough to set it to a reasonable default based
on the frame size that's probably what you want to do.

There are sysctl parameters you can tune to choose maximum packet read/
write sizes.  See Mark Perry's note.  If you are not memory
constrained, giving QDIO big buffers will also likely help speed
transfer speeds.

You can use the tracepath command to determine the maximum MTU size
across the whole path (which *should* be a direct-connection to your
zOS side, but probably worth verifying).

For your application, since you're using 256k tape blocks and 32k max
recls as your basic data chunk size, as large as possible is
probably the right answer for frame/MTU size...but by all means,
*measure performance* to see.  We're also making the assumption that
the backup application just constructs network transactions in whole-
block or at least whole-record sizes.  Without knowledge of the wire
protocol (which is likely not published) or tcpdumping what it's
doing, we don't really know that, and it is certainly not unheard of
for applications to try to be clever about network traffic on their
own (especially apps whose primary function is moving data across a
network quickly, like a backup client).  So it may well end up being
the case that the app is performing a misguided optimization (for your
case--that is, FDR/Upstream may use behavior that is in fact the right
behavior for the majority of their customers but is wrong for your
situation) that nullifies the effects of moving the frame size up, and
you won't see a benefit.

We really don't know what relation the tape block and record size has
to the wire protocol.  I, at least, am just guessing based on how I'd
design it: I've never looked that deeply into exactly HOW FDR/Upstream
moves its data around.

I feel like Bill Bitner: I must say, it depends.

Adam

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: HiperSocket Performance

[Ron Foster at Baldor-IS]

Dave,

With the above settings I'm seeing throughput in the area of 15-18 Mb
per second.

We also have FDR/UPSTREAM and use hipersockets to access the zOS tape
library.  Our SAP
systems run continuously except for a very small window early Sunday
morning.  (Too small
to perform all of our backups.)  We have to run our FDR/UPSTREAM backups
with SAP up
and running.

A not so funny thing happened when we tweaked settings to make
FDR/UPSTREAM run
at maximum speed.  FDR/UPSTREAM consumed so much memory that our SAP
application
slowed way down.  We settled for lower FDR/UPSTREAM performance in order
to keep
the SAP application responsive during backups.

That was two or three years ago.  the FDR/Upstream folks may have done
something about
this.  At the time, they just said it was how it works.

Ron




Rakoczy, Dave wrote:

Hello all,

We are a longtime zOS shop taking the plunge into the zVM / zLinux
(SUSE 10SP2) world.  We had never implemented HiperSockets in our zOS
environment so our experience with this technology is rather limited.
HiperSockets were implemented specifically to support our desire to take
advantage of  FDR/Upstreams ability to interface with our zOS tape
management tools.

During the last week or so we've been testing the different
FDR/Upstreams backup and restore processes (including the RMAN option).
The backup and restore processes work as advertised, but we are looking
for better throughput times for these processes.

Currently the HiperSocket channel is defined in the I/O Gen as having a
Maximum Frame Size of 16 KB, the MTU size on both the zOS and z/linux
interfaces is set to 8192 (see Below).   The backups are going to our
VTS which is Ficon attached to the Mainframe.

DevName: IUTIQDF4  DevType: MPCIPA
  DevStatus: Ready CfgRouter: Non  ActRouter: Non
  LnkName: HIPR2 LnkType: IPAQIDIOLnkStatus: Ready
NetNum: n/a  QueSize: n/a
IpBroadcastCapability: No
ArpOffload: YesArpOffloadInfo: Yes
ActMtu: 8192
ReadStorage: GLOBAL (2048K)
SecClass: 255  MonSysplex: No
IQDMultiWrite: Disabled
  BSD Routing Parameters:
MTU Size: 8192  Metric: 00
DestAddr: 0.0.0.0   SubnetMask: 255.255.255.0
  Multicast Specific:



hsi0  Link encap:Ethernet  HWaddr 00:00:00:00:00:00
  inet addr:192.0.1.5  Bcast:192.0.1.255  Mask:255.255.255.0
  inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
  UP BROADCAST RUNNING NOARP MULTICAST  MTU:8192  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:0 (0.0 b)  TX bytes:168 (168.0 b)


With the above settings I'm seeing throughput in the area of 15-18 Mb
per second.


I've spent the past few days scouring these archives looking for what
others have done.  I found a few threads that addressed HiperSocket
throughput speeds between zOS and zLinux, but were using FTP as the
benchmark utility.  I have a window this weekend where I can put in a
I/O Gen change for the Maximum Frame Size on the HiperSocket channel
define (hopefully I'm on the right track here).

So, the question I'm posing is : If you are using HiperSockets to
support FDR/Upstream, in your experience where did you find the
performance throughput sweet spot?

Thanks in advance for any input you may relay.



David Rakoczy
Operating Systems Programmer
Thermo Fisher Scientific

He who laughs last probably made a backup.



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
.




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

hipersocket

[Ceruti, Gerard G]

Hi All

When defining the QDIO CHPID in HCD is there any issue with defining a
Frame Size of 64K ?, if we leave our MTU at 8K other than the some
storage wastage are there any other issues we need to be aware of 

Regards
Gerard Ceruti
may the 'z' be with you

_

Standard Bank email Disclaimer and confidentiality note

This e-mail, its attachments and any rights attaching hereto are, unless the 
content clearly indicates otherwise, the property of 
Standard Bank Group Limited and its subsidiaries. It is confidential, private 
and intended for only the addressee. 

Should you not be the addressee and receive this e-mail by mistake, kindly 
notify the sender, and delete this e-mail immediately.
Do not disclose or use it in any way. Views and opinions expressed in this 
e-mail are those of the sender unless clearly stated as 
those of Standard Bank Group. 

Standard Bank Group accepts no liability for any loss or damages howsoever 
incurred, or suffered, resulting, or arising, 
from the use of this email or its attachments. 

Standard Bank Group does not warrant the integrity of this e-mail nor that it 
is free of errors, viruses, interception or interference. 

Licensed divisions of the Standard Bank Group are authorised financial services 
providers in terms of the Financial Advisory and 
Intermediary Services Act, No 37 of 2002 (FAIS).

For information about the Standard Bank Group visit our website 
http://www.standardbank.com


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket

[Mark Perry]

Ceruti, Gerard G wrote:
 Hi All

 When defining the QDIO CHPID in HCD is there any issue with defining a
 Frame Size of 64K ?, if we leave our MTU at 8K other than the some
 storage wastage are there any other issues we need to be aware of

 Regards
 Gerard Ceruti
 may the 'z' be with you

Hi Gerard,
it works without other issues. But I'm curious as to why you would
want to set the MTU=8K?

Jumbo frames are typically set on OSA's at 8992, so unless this is
strictly LPAR to LPAR on the same CEC, then PATH MTU DISCOVERY may be
in order (or setting all IFs to the same MTU) to prevent segmentation if
packets arrive from a OSA and are bound for the HiperSockets. It all
depends on what packet routing you will be doing.

Without knowing your OS's, applications or network topology its hard to
advise.

mark

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket

[Ceruti, Gerard G]

Hi Mark

This is pure HiperSocket setup, all internal on the same CEC, RHEL and SUSE 
guests talking to DB2 on zOS.

Regards
Gerard Ceruti
may the 'z' be with you


-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Perry
Sent: 16 October 2008 06:03 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: hipersocket

Ceruti, Gerard G wrote:
 Hi All

 When defining the QDIO CHPID in HCD is there any issue with defining a
 Frame Size of 64K ?, if we leave our MTU at 8K other than the some
 storage wastage are there any other issues we need to be aware of

 Regards
 Gerard Ceruti
 may the 'z' be with you

Hi Gerard,
it works without other issues. But I'm curious as to why you would
want to set the MTU=8K?

Jumbo frames are typically set on OSA's at 8992, so unless this is
strictly LPAR to LPAR on the same CEC, then PATH MTU DISCOVERY may be
in order (or setting all IFs to the same MTU) to prevent segmentation if
packets arrive from a OSA and are bound for the HiperSockets. It all
depends on what packet routing you will be doing.

Without knowing your OS's, applications or network topology its hard to
advise.

mark

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

_

Standard Bank email Disclaimer and confidentiality note

This e-mail, its attachments and any rights attaching hereto are, unless the 
content clearly indicates otherwise, the property of 
Standard Bank Group Limited and its subsidiaries. It is confidential, private 
and intended for only the addressee. 

Should you not be the addressee and receive this e-mail by mistake, kindly 
notify the sender, and delete this e-mail immediately.
Do not disclose or use it in any way. Views and opinions expressed in this 
e-mail are those of the sender unless clearly stated as 
those of Standard Bank Group. 

Standard Bank Group accepts no liability for any loss or damages howsoever 
incurred, or suffered, resulting, or arising, 
from the use of this email or its attachments. 

Standard Bank Group does not warrant the integrity of this e-mail nor that it 
is free of errors, viruses, interception or interference. 

Licensed divisions of the Standard Bank Group are authorised financial services 
providers in terms of the Financial Advisory and 
Intermediary Services Act, No 37 of 2002 (FAIS).

For information about the Standard Bank Group visit our website 
http://www.standardbank.com

Re: hipersocket

[Ron Foster at Baldor-IS]

Gerard,

In a qdio environment, you have a queue of buffers (default 16
inbound).  Depending on you situation, the storage wastage can add up.
I am not sure, but I think that these buffers have to be locked in
storage.  If you have a large number of hipersocket connections and a
large number of machines, and you are not in a storage rich environment,
this could affect paging rates.

Last year when we did our unicode conversion we maxed out frame size,
the mtu size, and the DB2 connect buffer size.  After the conversion, we
cut everything back because we were not in a storage  rich environment.
(We had made the
hipersocket connection with the large frame size part of our clone
master.  We ended up with around 30 or so Linux
guests with large frame sizes they did not need.)

Ron Foster

Ceruti, Gerard G wrote:

Hi Mark

This is pure HiperSocket setup, all internal on the same CEC, RHEL and SUSE 
guests talking to DB2 on zOS.

Regards
Gerard Ceruti
may the 'z' be with you


-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Mark Perry
Sent: 16 October 2008 06:03 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: hipersocket

Ceruti, Gerard G wrote:


Hi All

When defining the QDIO CHPID in HCD is there any issue with defining a
Frame Size of 64K ?, if we leave our MTU at 8K other than the some
storage wastage are there any other issues we need to be aware of

Regards
Gerard Ceruti
may the 'z' be with you



Hi Gerard,
it works without other issues. But I'm curious as to why you would
want to set the MTU=8K?

Jumbo frames are typically set on OSA's at 8992, so unless this is
strictly LPAR to LPAR on the same CEC, then PATH MTU DISCOVERY may be
in order (or setting all IFs to the same MTU) to prevent segmentation if
packets arrive from a OSA and are bound for the HiperSockets. It all
depends on what packet routing you will be doing.

Without knowing your OS's, applications or network topology its hard to
advise.

mark

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

_

Standard Bank email Disclaimer and confidentiality note

This e-mail, its attachments and any rights attaching hereto are, unless the 
content clearly indicates otherwise, the property of
Standard Bank Group Limited and its subsidiaries. It is confidential, private 
and intended for only the addressee.

Should you not be the addressee and receive this e-mail by mistake, kindly 
notify the sender, and delete this e-mail immediately.
Do not disclose or use it in any way. Views and opinions expressed in this 
e-mail are those of the sender unless clearly stated as
those of Standard Bank Group.

Standard Bank Group accepts no liability for any loss or damages howsoever 
incurred, or suffered, resulting, or arising,
from the use of this email or its attachments.

Standard Bank Group does not warrant the integrity of this e-mail nor that it 
is free of errors, viruses, interception or interference.

Licensed divisions of the Standard Bank Group are authorised financial services 
providers in terms of the Financial Advisory and
Intermediary Services Act, No 37 of 2002 (FAIS).

For information about the Standard Bank Group visit our website 
http://www.standardbank.com




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket

[Mark Perry]

Ceruti, Gerard G wrote:
 Hi Mark

 This is pure HiperSocket setup, all internal on the same CEC, RHEL and SUSE 
 guests talking to DB2 on zOS.

 Regards
 Gerard Ceruti
 may the 'z' be with you


Hi Gerard,
I believe you are working with Jochen Roehig?
If so he is in discussions with Volker Schoelles and I, and we can
discuss in depth off list.

mark

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket address versus regular address

[Harold Grovesteen]

If you consider a best practice must be such in all cases to be best (an
absolute), then yes I would agree with you.  I just would not put it on
my resume that I never use best practices, ;-), because such absolutes
do not exist.  I sense that you have discomfort over the use of the word
best and see it as an absolute quality (black vs white) rather than as
a relative quality (more white than black in a gray world).

However, common practices rarely become such without good reasons.  The
primary reason being around the service you are delivering.  Uncommon
practices tend to have higher failure rates and longer recovery times
for the very reasons you have identified.  And even when for good
technical reasons supported by business justification they are used,
will still have these effects.  That moves the discussion to one of risk
and risk is about financial loss, more specifically, the probability of
financial loss.  For an enterprise, that is the real driver of what
makes a practice best for that organization or not in the long term.

I certainly have used just about every trick in the book in the more
than three decades I have been involved in networking, so by advocating
best practices I am not advocating that uncommon practice should never
be used, an absolute position that I was not taking.   That doesn't mean
the organizations with which I was associated did not experience the
effects of doing so.  Not everyone in an organization will understand
the impact of change when uncommon practices are used and I have had to
live with the effects on occasion, too.  Our technical decisions have
business impact - both positive and negative.

And that gets back to my original reason for objecting to uncommon
practice.  Uncommon practices tend to be similar to giving a loaded
weapon to a child to play with.  I hope the list will forgive the
hyperbole, but it makes the point.  Tragedy doesn't always happen, but
certainly can.  That doesn't mean that there aren't professionals who
are perfectly qualified to use loaded weapons and know when to use
them.  For those seeking answers to questions here, being networking or
any other category of information, they are many times not in the latter
category.  That's why they are asking.  Those who seek answers here are
seeking the answers that have positive business impact for their
organizations (and their careers).  Advocacy of common practice or
best practice, whichever you prefer to call it, is the responsible
position for those who do know to take.

We are on same page even if the words on it are slightly different.

Harold Grovesteen

Rob van der Heij wrote:


From the knitpicking gallery: rather than best practice I would call

it common practice

I see some similarity with a recent discussion about allocation of
cylinder 0 as page. We know that CP does not mind and there should be
no issue. Still, for several good reasons people tend to avoid doing
this. And one of the reasons is that it makes people frown and ask
questions each time when there's a problem. You lose valuable time
explaining it (or even change it) each time before you can focus on
the real cause of the problem.

But there may be very good reasons to deviate from common practice.
Some of my systems at home have a different subnet mask for the same
LAN segment; it's not common practice, but in my case best practice
;-)

-Rob (an now back to my cage again)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390





--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket address versus regular address

[Harold Grovesteen]

Because my organization has yet to implement Linux virtualization on the
mainframe, I tend to use this list as a way to stay abreast of
developments with little to contribute. However, as a networking
professional designing global networks I must state that your advise,
Mr. Boyes, to the list is absolutely BEST PRACTICE. While Mr. Cox's
comments are techincally accurate, for a list composed of primarily
operating system professionals whose focus is never exclusively
networking his suggestions are close to being malicious. Such
techniques, while possible, are application availability denial of
service attacks waiting to happen, even for networking professionals
such as Mr. Cox who might know how or when to use them. Obviously, a
lesson you and I have both learned.

Harold Grovesteen

David Boyes wrote:


O I'd argue that you will have more problems trying to make this work



reliably than just doing it the way I described. If you've got time



to



debug this and all the paths have equivalent permissions and



usability



characteristics, then yes, it's technically possible. You just have



to



have a lot of free time to figure out what happened when it doesn't
work, and personally, I've got better things to do.



The paths can be completely different, IP does not care.




Certainly. But you're going to spend a lot more time figuring out why it
doesn't work when it doesn't.

I can make it work -- been there, done that. I just have learned from
bitter experience with similar setups that it's a rotten idea if you can
avoid it, and it's usually not a good idea to design based on it. It's
more trouble than it's worth for 99% of cases.

If what you're after is that it can be made to work, then you are
correct, it can work. Is it a good idea? I'd say no, and it definitely
isn't a best practice. Too many opportunities for things and people to
be confused, especially when there are ways easier to implement and
maintain.




Sounds like a new added bug as you describe it.



Not from a diagnostic standpoint.



Well if a stack prohibits valid configurations I'd call it words like
buggy or flawed, or if I'm trying to set up such a configuration



unfit



for purpose.




We'll have to agree to disagree, then. While there are reasons for
wanting to do this, there are alternative methods to accomplish the same
effect that don't require this feature and that (at least IMHO) are
simpler to understand and maintain. If I need to do this with one of the
IBM stacks, I can always front-end the IBM stack with a Linux guest and
not have to have further discussion about it.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390





--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket address versus regular address

[Rob van der Heij]

From the knitpicking gallery: rather than best practice I would call
it common practice

I see some similarity with a recent discussion about allocation of
cylinder 0 as page. We know that CP does not mind and there should be
no issue. Still, for several good reasons people tend to avoid doing
this. And one of the reasons is that it makes people frown and ask
questions each time when there's a problem. You lose valuable time
explaining it (or even change it) each time before you can focus on
the real cause of the problem.

But there may be very good reasons to deviate from common practice.
Some of my systems at home have a different subnet mask for the same
LAN segment; it's not common practice, but in my case best practice
;-)

-Rob (an now back to my cage again)

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket address versus regular address

[David Boyes]

 When setting up the IP address for a hipersocket I am curious as to if
 people are giving it the same IP address as with the regular outside
of
 the mainframe (OSA or whatever) IP address. 

Absolutely DO NOT do this. Each interface needs a unique address (and
IMHO, a unique DNS name). The whole premise of IP routing and network
function is based on this concept. 

 We have TCP/IP stacks with
 hipersockets running on VSE, Linux and z/OS.  On some of the VSE
stacks we
 use the same IP address for the hipersocket as we do for the OSA.  On
a
 few other VSE stacks we give them separate IP addresses, and we do the
 same (different addresses) for all of the Linux and z/OS stacks. 

The only reason you get away with this on hipersockets is that they
never see the outside world (they act like a isolated hub). You are also
not likely to actually get any benefit -- in fact, I would suspect that
you're not using those interfaces because the OSA initialization is
silently overriding it due to IP address conflict. 

 How do
 other places do it?  

Every interface has a unique address and DNS name. If I want
interface-independent stuff, that's what VIPA is for -- and the VIPAs
all have unique IP addresses and unique names. 

Example: 

Linux guest with OSA and hipersocket interfaces, plus VIPA to identify
access to specific service, runs in VM userid VA1TRS89:

(addresses replaced with letters)

OSA interface:

va1trs01-osa0.srv.va1.sinenomine.net: x.y.z.a

Hipersocket interface:

va1trs01-hs0.srv.va1.sinenomine.net: p.q.r.s

VIPA: 

prod-smtp.app.va1.sinenomine.net: e.f.g.h


Note ALL are unique addresses, and the OSA and hipersockets are in
DIFFERENT subnets. The VIPA is also in a different subnet, advertised by
specific host routes. 

Users are only given the VIPA name (note, NAME, not address), and that
can be moved around by simply manipulating the DNS. 


 And is there any particular reason?

Any other solution is a network routing loop looking for a place to
happen. IP routing is based on knowing a destination that you CAN reach
to send packets to destinations that you don't know how to reach.
Without unique addresses, the whole thing falls apart. 

(the only reason that your setup hasn't already fallen is that some of
the older IBM stacks permitted this configuration error. The new ones
don't.) 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket address versus regular address

[Alan Cox]

 Absolutely DO NOT do this. Each interface needs a unique address (and
 IMHO, a unique DNS name). The whole premise of IP routing and network
 function is based on this concept.

You don't have to have a per interface IP address or DNS (or indeed MAC
address), but they must be at least per host (and virtual machines with
their own IP stack are a host). IP is quite happy with that situation.

 happen. IP routing is based on knowing a destination that you CAN reach
 to send packets to destinations that you don't know how to reach.
 Without unique addresses, the whole thing falls apart.

If every instance of the address is owned by the same machine this is
untrue - it doesn't matter which interface it arrives upon. IP is like
postal mail, you can have ten mail boxes all with the same number
providing they are for the same house and nobody gets confused.

The only notionally not allowed case is two machines with the same IP
address that one is not usually permissible although there are situations
you can and people do it to make get multiple sites around the world to
appear on the same address and have packets routed to the nearest
instance. That requires a knowledge of BGP4, backbone route visibility
and an expert so don't try it at home.

 (the only reason that your setup hasn't already fallen is that some of
 the older IBM stacks permitted this configuration error. The new ones
 don't.)

Sounds like a new added bug as you describe it.

Alan

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket address versus regular address

[Frank Swarbrick]

 On 2/28/2008 at 8:57 AM, in message
[EMAIL PROTECTED], David
Boyes [EMAIL PROTECTED] wrote:
  When setting up the IP address for a hipersocket I am curious as to if
 people are giving it the same IP address as with the regular outside
 of
 the mainframe (OSA or whatever) IP address. 
 
 Absolutely DO NOT do this. Each interface needs a unique address (and
 IMHO, a unique DNS name). The whole premise of IP routing and network
 function is based on this concept. 
 
 We have TCP/IP stacks with
 hipersockets running on VSE, Linux and z/OS.  On some of the VSE
 stacks we
 use the same IP address for the hipersocket as we do for the OSA.  On
 a
 few other VSE stacks we give them separate IP addresses, and we do the
 same (different addresses) for all of the Linux and z/OS stacks. 
 
 The only reason you get away with this on hipersockets is that they
 never see the outside world (they act like a isolated hub). You are also
 not likely to actually get any benefit -- in fact, I would suspect that
 you're not using those interfaces because the OSA initialization is
 silently overriding it due to IP address conflict. 
 
 How do
 other places do it?  
 
 Every interface has a unique address and DNS name. If I want
 interface-independent stuff, that's what VIPA is for -- and the VIPAs
 all have unique IP addresses and unique names. 
 
 Example: 
 
 Linux guest with OSA and hipersocket interfaces, plus VIPA to identify
 access to specific service, runs in VM userid VA1TRS89:
 
 (addresses replaced with letters)
 
 OSA interface:
 
 va1trs01-osa0.srv.va1.sinenomine.net: x.y.z.a
 
 Hipersocket interface:
 
 va1trs01-hs0.srv.va1.sinenomine.net: p.q.r.s
 
 VIPA: 
 
 prod-smtp.app.va1.sinenomine.net: e.f.g.h
 
 
 Note ALL are unique addresses, and the OSA and hipersockets are in
 DIFFERENT subnets. The VIPA is also in a different subnet, advertised by
 specific host routes. 
 
 Users are only given the VIPA name (note, NAME, not address), and that
 can be moved around by simply manipulating the DNS. 
 
 
 And is there any particular reason?
 
 Any other solution is a network routing loop looking for a place to
 happen. IP routing is based on knowing a destination that you CAN reach
 to send packets to destinations that you don't know how to reach.
 Without unique addresses, the whole thing falls apart. 
 
 (the only reason that your setup hasn't already fallen is that some of
 the older IBM stacks permitted this configuration error. The new ones
 don't.) 

Sounds good, David.  Thanks for all of the information.

Frank

-- 

Frank Swarbrick
Senior Systems Analyst - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO
(303) 235-1403
 




The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket address versus regular address

[David Boyes]

 You don't have to have a per interface IP address or DNS (or indeed
MAC
 address), but they must be at least per host (and virtual machines
with
 their own IP stack are a host). IP is quite happy with that situation.

I'd argue that you will have more problems trying to make this work
reliably than just doing it the way I described. If you've got time to
debug this and all the paths have equivalent permissions and usability
characteristics, then yes, it's technically possible. You just have to
have a lot of free time to figure out what happened when it doesn't
work, and personally, I've got better things to do. 

 If every instance of the address is owned by the same machine this is
 untrue - it doesn't matter which interface it arrives upon. IP is like
 postal mail, you can have ten mail boxes all with the same number
 providing they are for the same house and nobody gets confused.

Key phrase: and nobody gets confused. Big if. Also, you're dealing
with the Royal Mail. 8-)

  (the only reason that your setup hasn't already fallen is that some
of
  the older IBM stacks permitted this configuration error. The new
ones
  don't.)
 Sounds like a new added bug as you describe it.

Not from a diagnostic standpoint. 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket address versus regular address

[Alan Cox]

O I'd argue that you will have more problems trying to make this work
 reliably than just doing it the way I described. If you've got time to
 debug this and all the paths have equivalent permissions and usability
 characteristics, then yes, it's technically possible. You just have to
 have a lot of free time to figure out what happened when it doesn't
 work, and personally, I've got better things to do.

The paths can be completely different, IP does not care.

  Sounds like a new added bug as you describe it.

 Not from a diagnostic standpoint.

Well if a stack prohibits valid configurations I'd call it words like
buggy or flawed, or if I'm trying to set up such a configuration unfit
for purpose.

Alan

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket address versus regular address

[David Boyes]

 O I'd argue that you will have more problems trying to make this work
  reliably than just doing it the way I described. If you've got time
to
  debug this and all the paths have equivalent permissions and
usability
  characteristics, then yes, it's technically possible. You just have
to
  have a lot of free time to figure out what happened when it doesn't
  work, and personally, I've got better things to do.
 
 The paths can be completely different, IP does not care.

Certainly. But you're going to spend a lot more time figuring out why it
doesn't work when it doesn't. 

I can make it work -- been there, done that. I just have learned from
bitter experience with similar setups that it's a rotten idea if you can
avoid it, and it's usually not a good idea to design based on it. It's
more trouble than it's worth for 99% of cases.

If what you're after is that it can be made to work, then you are
correct, it can work. Is it a good idea? I'd say no, and it definitely
isn't a best practice. Too many opportunities for things and people to
be confused, especially when there are ways easier to implement and
maintain.
 
   Sounds like a new added bug as you describe it.
  Not from a diagnostic standpoint.
 Well if a stack prohibits valid configurations I'd call it words like
 buggy or flawed, or if I'm trying to set up such a configuration
unfit
 for purpose.

We'll have to agree to disagree, then. While there are reasons for
wanting to do this, there are alternative methods to accomplish the same
effect that don't require this feature and that (at least IMHO) are
simpler to understand and maintain. If I need to do this with one of the
IBM stacks, I can always front-end the IBM stack with a Linux guest and
not have to have further discussion about it. 

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

hipersocket address versus regular address

[Frank Swarbrick]

When setting up the IP address for a hipersocket I am curious as to if people 
are giving it the same IP address as with the regular outside of the mainframe 
(OSA or whatever) IP address.  We have TCP/IP stacks with hipersockets running 
on VSE, Linux and z/OS.  On some of the VSE stacks we use the same IP address 
for the hipersocket as we do for the OSA.  On a few other VSE stacks we give 
them separate IP addresses, and we do the same (different addresses) for all of 
the Linux and z/OS stacks.  How do other places do it?  And is there any 
particular reason?

I'm only an applications developer, so I don't really know what all of the 
'systems' type issues there might be to prefer one over the other.  Seems to me 
it would be nice not to have two different addresses so that you don't have to 
remember to use one when coming from the outside world and another when coming 
from another system residing on the same mainframe.  But there also may be some 
very good reasons for this type of separation.

Thanks,
Frank

-- 

Frank Swarbrick
Senior Systems Analyst - Mainframe Applications Development
FirstBank Data Corporation - Lakewood, CO
(303) 235-1403
 


 

The information contained in this electronic communication and any document 
attached hereto or transmitted herewith is confidential and intended for the 
exclusive use of the individual or entity named above.  If the reader of this 
message is not the intended recipient or the employee or agent responsible for 
delivering it to the intended recipient, you are hereby notified that any 
examination, use, dissemination, distribution or copying of this communication 
or any part thereof is strictly prohibited.  If you have received this 
communication in error, please immediately notify the sender by reply e-mail 
and destroy this communication.  Thank you.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket address versus regular address

[Thomas Kern]

When I set up my hipersocket network between two z/VM LPARs, I went to
the networking people and got a 10.x.y.0-255 segment for my own use.
They promised not to let anyone else use it in the rest of the network.

/Tom Kern

Frank Swarbrick wrote:

When setting up the IP address for a hipersocket I am curious as to if people 
are giving it the same IP address as with the regular outside of the mainframe 
(OSA or whatever) IP address.  We have TCP/IP stacks with hipersockets running 
on VSE, Linux and z/OS.  On some of the VSE stacks we use the same IP address 
for the hipersocket as we do for the OSA.  On a few other VSE stacks we give 
them separate IP addresses, and we do the same (different addresses) for all of 
the Linux and z/OS stacks.  How do other places do it?  And is there any 
particular reason?

I'm only an applications developer, so I don't really know what all of the 
'systems' type issues there might be to prefer one over the other.  Seems to me 
it would be nice not to have two different addresses so that you don't have to 
remember to use one when coming from the outside world and another when coming 
from another system residing on the same mainframe.  But there also may be some 
very good reasons for this type of separation.

Thanks,
Frank



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: hipersocket address versus regular address

[Rich Smrcina]

The hipersocket network devices should be on a separate subnet from the
rest of your network devices.  The hipersocket network is a private
network and it needs to be treated as such.

Also, different hipersocket CHPIDs require different subnets since they
represent different network segments.


Frank Swarbrick wrote:

When setting up the IP address for a hipersocket I am curious as to if people 
are giving it the same IP address as with the regular outside of the mainframe 
(OSA or whatever) IP address.  We have TCP/IP stacks with hipersockets running 
on VSE, Linux and z/OS.  On some of the VSE stacks we use the same IP address 
for the hipersocket as we do for the OSA.  On a few other VSE stacks we give 
them separate IP addresses, and we do the same (different addresses) for all of 
the Linux and z/OS stacks.  How do other places do it?  And is there any 
particular reason?

I'm only an applications developer, so I don't really know what all of the 
'systems' type issues there might be to prefer one over the other.  Seems to me 
it would be nice not to have two different addresses so that you don't have to 
remember to use one when coming from the outside world and another when coming 
from another system residing on the same mainframe.  But there also may be some 
very good reasons for this type of separation.

Thanks,
Frank



--
Rich Smrcina
VM Assist, Inc.
Phone: 414-491-6001
Ans Service:  360-715-2467
rich.smrcina at vmassist.com
http://www.linkedin.com/in/richsmrcina

Catch the WAVV!  http://www.wavv.org
WAVV 2008 - Chattanooga - April 18-22, 2008

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket Guest Lan Question

[Alan Altmark]

On Thursday, 11/15/2007 at 05:28 EST, Spracklen, Ken [EMAIL PROTECTED]
wrote:

 I think part of my confusion came from reading section 4.3 of the Linux
 for IBM System z9 and IBM zSeries redbook and mis-interpreting the
 paragraph regarding the hipersockets not using LAN frame, instead they
 are addressed by data queue addresses. I guess I read too much into it
 and that I took that to say that the mac address and ip address are no
 longer part of that data stream and that the ip stack knew that
 destination by an internal device address instead of ip address and did
 not use normal ip routing. Did I read it incorrectly and is the network
 layer info (dest ip address etc) still in the frame of data? So that a
 network concentrator like Linux on z/OS just needs to change the frame
 protocol to go out the appropriate interface much a like a router
 supporting token ring and Ethernet.

This is a case of the authors knowing just enough to be dangerous.  :-)
People like to talk about How It Works when it comes to HiperSockets and
OSAs.  (Who can blame them?)  Unfortunately you get incomplete and
sometimes (often?) inaccurate information about the mechanism, but no
information on what happens between source and destination (because the
person doesn't know).  I don't mean for this to sound Zen, but I would say
that HiperSockets works exactly as it must in order to accomplish the
goals set before it:
- Create an in-box isolated LAN segment sharable among and within LPARs
- Enable z/OS OSA-HiperSockets concentrator
- Enable Linux flavor of the same thing (HiperSockets accelerator)

Because the interface to HiperSockets is not published, I am unable to go
into any details about the interface.  In my previous post I tried to
describe the *bevhavior* as best I could.

 It looks like I need to give it more thought to determine just how many
 Linux guest will want hipersocket access to z/os data. It may not be
 worth the effort to configure a hipersocket guest lan for the  the Linux
 guests to connect into, just save on real hipersocket addresses.

You know those recent posts about QIOASSIST?  You will want to pay
attention to them as they apply to dedicated HiperSockets connections,
too.

Alan Altmark
z/VM Development
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket Guest Lan Question

[Alan Altmark]

On Wednesday, 11/14/2007 at 06:00 EST, Spracklen, Ken
[EMAIL PROTECTED] wrote:

 Recently we started planning for Linux guests to access data on the z/os
 lpars via hipersockets. As part of that process, we defined a new
 hipersocket, IUTIQDEF, to the z/VM TCPIP guest profile and added the
 IUTIQDEF device to the OSPF config for MPROUTE (same subnet as the
 IUTIQDFF interface). We then created a new guest lan (glan01 with type
 hipersocket and used nicdef/couple commands for a Linux guest and the
 TCPIP guest to use that hipersocket guest lan.

 The problem is that I could not ping the ip address of z/VM IUTIQDEF
 interface from the zOS systems nor ping the hsi1 ip address on the Linux
 guest. A q lan glan01 det indicated both guests connected but the TX/RX
 counts were 0 and the discards were high.

If you draw the picture Rob requested, you will see that a Guest LAN is a
separate subnet and needs to be attached to your existing network using
the same techniques as you would for a real LAN segment.

 1) Is the above scenario possible or recommended? We are hoping to use
 the guest lan concept to conserve on real hipersocket devices needed for
 Linux guests. Does routing work the same way (via the a lookup table)
 for a hipersocket guest lan as it does on a real hipersocket network?

It is fine, though you may wish to give Linux OSA Guest LAN (QDIO or
Hipersocket) is not a bridge or switch.  It is a LAN segment that requires
routing.

 2) Would the above scenario work if the new guest lan was configured as
 QDIO? Is there much savings in cp cycles and memory by using a
 hipersocket guest lan vice a qdio guest lan?

That depends on the workload.  The z/VM Performance Reports, going back to
z/VM 4.3, provide a comparison of QDIO vs. HiperSockets.

 3) In the documentation we have encountered, we have seen examples of a
 z/OS hipersocket concentrator and a Linux network concentrator. Does
 someone have an example of a z/VM TCPIP/MPROUTE concentrator? Can z/VM
 TCPIP/MPROUTE support routing between hipersockets, osa's, and guest lan
 (hipersockets and/or qdio)? Which type of concentrator is recommended?

z/VM does not provide a HiperSocket concentrator (i.e. a HiperSocket
Virtual Switch).

 4) In the scenario of the z/os hipersocket concentrator, the z/os is the
 router and there are a few Linux guests attached to the hipersockets. I
 was wondering if someone could clear up my understanding how that Linux
 guests can route data to an ip address out on the network beyond z/os
 tcpip. In my foggy mind, I can see the Linux guest indicating the
 default route is out the hipersocket interface, but if the hipersocket
 frame doesn't have the LLC info like the ip address of the destination,
 how does z/os know what ip address to put into the destination ip
 address so that goes out into the normal lan network? Or is my
 understanding of hipersockets incorrect about the LLC headers

It's not a routing thing.  Linux thinks the same-subnet IP addresses on
the OSA network are local and does what Linux normally does: sends the
packet directly to the intended IP address, not via a default route.  A
miracle occurs in Step 2 and z/OS gets the packet, unchanged, and places
it on the LAN.  In return, z/OS has responsibility to handle ARP issues on
the OSA on Linux's behalf.  To the rest of the network, z/OS and all of
the Linuxen have the same MAC address.

Alan Altmark
z/VM Development
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket Guest Lan Question

[Spracklen, Ken]

 
Alan and Mark,

Thanks for the help. I haven't tried it yet, but I suspect that if I
change the ip addresses on the new hipersocket interfaces, it will help.


I think part of my confusion came from reading section 4.3 of the Linux
for IBM System z9 and IBM zSeries redbook and mis-interpreting the
paragraph regarding the hipersockets not using LAN frame, instead they
are addressed by data queue addresses. I guess I read too much into it
and that I took that to say that the mac address and ip address are no
longer part of that data stream and that the ip stack knew that
destination by an internal device address instead of ip address and did
not use normal ip routing. Did I read it incorrectly and is the network
layer info (dest ip address etc) still in the frame of data? So that a
network concentrator like Linux on z/OS just needs to change the frame
protocol to go out the appropriate interface much a like a router
supporting token ring and Ethernet. 

It looks like I need to give it more thought to determine just how many
Linux guest will want hipersocket access to z/os data. It may not be
worth the effort to configure a hipersocket guest lan for the  the Linux
guests to connect into, just save on real hipersocket addresses.

If you are curious to see a simple network map of what we were
considering, I can send it offline.

Thanks,

Ken Spracklen


-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Alan Altmark
Sent: Thursday, November 15, 2007 09:12
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Hipersocket Guest Lan Question

On Wednesday, 11/14/2007 at 06:00 EST, Spracklen, Ken
[EMAIL PROTECTED] wrote:

 Recently we started planning for Linux guests to access data on the 
 z/os lpars via hipersockets. As part of that process, we defined a new

 hipersocket, IUTIQDEF, to the z/VM TCPIP guest profile and added the 
 IUTIQDEF device to the OSPF config for MPROUTE (same subnet as the 
 IUTIQDFF interface). We then created a new guest lan (glan01 with type

 hipersocket and used nicdef/couple commands for a Linux guest and the 
 TCPIP guest to use that hipersocket guest lan.

 The problem is that I could not ping the ip address of z/VM IUTIQDEF 
 interface from the zOS systems nor ping the hsi1 ip address on the 
 Linux guest. A q lan glan01 det indicated both guests connected but 
 the TX/RX counts were 0 and the discards were high.

If you draw the picture Rob requested, you will see that a Guest LAN is
a separate subnet and needs to be attached to your existing network
using the same techniques as you would for a real LAN segment.

 1) Is the above scenario possible or recommended? We are hoping to use

 the guest lan concept to conserve on real hipersocket devices needed 
 for Linux guests. Does routing work the same way (via the a lookup
 table) for a hipersocket guest lan as it does on a real hipersocket
network?

It is fine, though you may wish to give Linux OSA Guest LAN (QDIO or
Hipersocket) is not a bridge or switch.  It is a LAN segment that
requires routing.

 2) Would the above scenario work if the new guest lan was configured 
 as QDIO? Is there much savings in cp cycles and memory by using a 
 hipersocket guest lan vice a qdio guest lan?

That depends on the workload.  The z/VM Performance Reports, going back
to z/VM 4.3, provide a comparison of QDIO vs. HiperSockets.

 3) In the documentation we have encountered, we have seen examples of 
 a z/OS hipersocket concentrator and a Linux network concentrator. Does

 someone have an example of a z/VM TCPIP/MPROUTE concentrator? Can z/VM

 TCPIP/MPROUTE support routing between hipersockets, osa's, and guest 
 lan (hipersockets and/or qdio)? Which type of concentrator is
recommended?

z/VM does not provide a HiperSocket concentrator (i.e. a HiperSocket
Virtual Switch).

 4) In the scenario of the z/os hipersocket concentrator, the z/os is 
 the router and there are a few Linux guests attached to the 
 hipersockets. I was wondering if someone could clear up my 
 understanding how that Linux guests can route data to an ip address 
 out on the network beyond z/os tcpip. In my foggy mind, I can see the 
 Linux guest indicating the default route is out the hipersocket 
 interface, but if the hipersocket frame doesn't have the LLC info like

 the ip address of the destination, how does z/os know what ip address 
 to put into the destination ip address so that goes out into the 
 normal lan network? Or is my understanding of hipersockets incorrect

 about the LLC headers

It's not a routing thing.  Linux thinks the same-subnet IP addresses
on the OSA network are local and does what Linux normally does: sends
the packet directly to the intended IP address, not via a default route.
A miracle occurs in Step 2 and z/OS gets the packet, unchanged, and
places it on the LAN.  In return, z/OS has responsibility to handle ARP
issues on the OSA on Linux's behalf.  To the rest of the network, z/OS
and all of the Linuxen have

Hipersocket Guest Lan Question

[Spracklen, Ken]

Hi,

Considering the following scenario possible. 

One our CEC we have 3 z/os lpars and an IFL running z/VM 5.3. On the
z/VM we have a few SUSE Linux quests as well as TCPIP and MPROUTE
guests. On all three z/OS lpars and the TCPIP guest I have a hipersocket
device, IUTIQDFF, defined in the profile and OSPF config. I can ping and
ftp to the various hipersocket ip addresses from all three z/os lpars
and z/VM TCPIP guest. 

Recently we started planning for Linux guests to access data on the z/os
lpars via hipersockets. As part of that process, we defined a new
hipersocket, IUTIQDEF, to the z/VM TCPIP guest profile and added the
IUTIQDEF device to the OSPF config for MPROUTE (same subnet as the
IUTIQDFF interface). We then created a new guest lan (glan01 with type
hipersocket and used nicdef/couple commands for a Linux guest and the
TCPIP guest to use that hipersocket guest lan. 

The problem is that I could not ping the ip address of z/VM IUTIQDEF
interface from the zOS systems nor ping the hsi1 ip address on the Linux
guest. A q lan glan01 det indicated both guests connected but the TX/RX
counts were 0 and the discards were high.

In looking at the matter, we came up with several questions that we are
hoping someone can help us with.

1) Is the above scenario possible or recommended? We are hoping to use
the guest lan concept to conserve on real hipersocket devices needed for
Linux guests. Does routing work the same way (via the a lookup table)
for a hipersocket guest lan as it does on a real hipersocket network? 

2) Would the above scenario work if the new guest lan was configured as
QDIO? Is there much savings in cp cycles and memory by using a
hipersocket guest lan vice a qdio guest lan?

3) In the documentation we have encountered, we have seen examples of a
z/OS hipersocket concentrator and a Linux network concentrator. Does
someone have an example of a z/VM TCPIP/MPROUTE concentrator? Can z/VM
TCPIP/MPROUTE support routing between hipersockets, osa's, and guest lan
(hipersockets and/or qdio)? Which type of concentrator is recommended?

4) In the scenario of the z/os hipersocket concentrator, the z/os is the
router and there are a few Linux guests attached to the hipersockets. I
was wondering if someone could clear up my understanding how that Linux
guests can route data to an ip address out on the network beyond z/os
tcpip. In my foggy mind, I can see the Linux guest indicating the
default route is out the hipersocket interface, but if the hipersocket
frame doesn't have the LLC info like the ip address of the destination,
how does z/os know what ip address to put into the destination ip
address so that goes out into the normal lan network? Or is my
understanding of hipersockets incorrect about the LLC headers

Thanks for letting a long time lurker, but a first time questioner to
participate.

 
 
Ken Spracklen

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket Guest Lan Question

[Mark Post]

 On Wed, Nov 14, 2007 at  4:21 PM, in message
[EMAIL PROTECTED],
Spracklen, Ken [EMAIL PROTECTED] wrote: 
-snip-
 Recently we started planning for Linux guests to access data on the z/os
 lpars via hipersockets. As part of that process, we defined a new
 hipersocket, IUTIQDEF, to the z/VM TCPIP guest profile and added the
 IUTIQDEF device to the OSPF config for MPROUTE (same subnet as the
 IUTIQDFF interface).

So, since both interfaces are in the same subnet, how is z/OS supposed to know 
which interface to send packets over, and vice versa?  Particuarly before the 
dynamic routing protocols attempt to figure things out.  (And I doubt they'll 
be very successful.)

 We then created a new guest lan (glan01 with type
 hipersocket and used nicdef/couple commands for a Linux guest and the
 TCPIP guest to use that hipersocket guest lan. 

What are the IP addresses, subnet masks and default gateways on the z/OS and 
z/VM side?  What are the IP addresses, subnet masks, and default gateways on 
the guest LAN?  As Alan Altmark always says, drawing a picture would be a good 
idea to illustrate what you're trying to do.

 The problem is that I could not ping the ip address of z/VM IUTIQDEF
 interface from the zOS systems nor ping the hsi1 ip address on the Linux
 guest.

That's a really bad sign, since they're only one hop away from each other.

 A q lan glan01 det indicated both guests connected but the TX/RX
 counts were 0 and the discards were high.

I don't know that this is relevant yet, since you say you can't even ping z/VM 
from z/OS.  There wouldn't be any traffic getting to the guest LAN.

 In looking at the matter, we came up with several questions that we are
 hoping someone can help us with.
 
 1) Is the above scenario possible or recommended? We are hoping to use
 the guest lan concept to conserve on real hipersocket devices needed for
 Linux guests. Does routing work the same way (via the a lookup table)
 for a hipersocket guest lan as it does on a real hipersocket network? 

Yes, since nothing except CP knows that there is any difference between a real 
HiperSocket and a virtualized one.

 2) Would the above scenario work if the new guest lan was configured as
 QDIO? Is there much savings in cp cycles and memory by using a
 hipersocket guest lan vice a qdio guest lan?

The answer to the first question is no, it will work (or fail) exactly the 
same.  I would have to let someone who knows something about guest LANS answer 
the performance question.

 3) In the documentation we have encountered, we have seen examples of a
 z/OS hipersocket concentrator and a Linux network concentrator. Does
 someone have an example of a z/VM TCPIP/MPROUTE concentrator? Can z/VM
 TCPIP/MPROUTE support routing between hipersockets, osa's, and guest lan
 (hipersockets and/or qdio)? Which type of concentrator is recommended?

I'm 99% sure z/VM can do it.  The question I have is why would you want to?  
Use VSWITCH for the Linux guests for any traffic going through the OSA 
interfaces, and some sort of HiperSockets concentrator for anything going to 
z/OS.

 4) In the scenario of the z/os hipersocket concentrator, the z/os is the
 router and there are a few Linux guests attached to the hipersockets. I
 was wondering if someone could clear up my understanding how that Linux
 guests can route data to an ip address out on the network beyond z/os
 tcpip.

Again, I wouldn't even try to do that.  Use the HiperSockets to talk to z/OS 
and z/OS only.  Everything else should go out the VSWITCH.

Along with using VSWITCH, I would then start to question the use of any dynamic 
routing protocols within z/VM or Linux.  Let the routers do that, since that's 
where that work really belongs.  VSWITCH was designed with one of the goals 
being the elimination of dynamic routing stuff chewing up valuable mainframe 
CPU cycles.


Mark Post

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket Performance Problem on SLES 9

[Harold Grovesteen]

From James Melin's 12/14/2006 post:

Mark, I saw something similar when we first went to SLES-9 (64 bit).  We had 
MTU sizes being negotiated down to an idiotic packet size of 1492.
Whether or not this has to do with how our OSA is configured I never did learn. 
Search for stuff with hipersockets and MTU in the archives for the
particulars.

We reported it to Novell. They eventually managed to test on SLES 9 under 
z/Series and  eventually issued a patch. They sent us this file:

iputils-ss021109-147.2.PTF.184411.0.s390.rpm

I don't know whether or not this file is GA but it touched MANY IP related 
items, indicating that the problem was pervasive.  Once we applied it our
MTU negotiation problem went away. It may or may not have bearing on your 
situation, but I offer the information to any and all that might find it
relevant.

-J



barton wrote:


I've seen this a lot. You need to find the real bottleneck. Are
you equiped?



Mark Wheeler wrote:


More info:

FTP GET's of this cached 256MB file to /dev/null have run as fast as 205
MB/sec w/ MTU=32760 over hipersocket interfaces, and 168 MB over virtual
CTCs. FTP PUT's are a different matter: hipersocket or CTC doesn't
make a
difference. The higher MTU size, the slower the transfer rate (from
90-100
MB/sec w/ MTU=16376 down to 10-15 MB/sec for MTU=32084. At MTU=32085,
performance drops off a cliff, down to 400 KB/sec.

So, one problem appears to be related to FTP PUT performance with
large MTU
sizes.

In the process of investigating this alleged hipersocket performance
problem (as reported by our Linux support person up four chains of
management), I discovered an interesting issue with scp. It shows very
limitted sensitivity for interface type, MTU size, or direction of
movement), however I can't get it to run faster than 8 MB/sec (25 times
slower than FTP GET). I'm using scp between two virtual Linux machines
running on a 1-IFL system, so thought initially it may have been CPU
contention (no hardware crypto on this box), yet CPU util was less
than 5%
on each machine. What I did see was the sending side doing a lot of disk
I/O, something I don't see with FTP. Is it possible that scp reads from
disk, bypassing the cache?

Linux version 2.6.5-7.276-s390x

Best regards,
   Mark



Greetings all,

I've been using real hipersockets for a couple years now. Recently a
significant performance problem with SLES 9 and large MTU sizes was



brought


to my attention. I've been using MTU=32760. I set up a test to
illustrate
the problem. I built a 256 MB file on one zLinux guest (running under



z/VM


5.2 on a z9-109), with enough storage defined so the file could be
completely cached. I then FTP'd it to /dev/null on another server
over a
hipersocket connection. Here's what I observed:
SLES8-to-SLES8, MTU=8184,   ~75 MB/sec
SLES8-to-SLES8, MTU=32760, ~100 MB/sec (as high as 132 MB/sec)
SLES8-to-SLES9, MTU=32760, ~100 MB/sec
z/VM-to-SLES9,  MTU=32760, ~100 MB/sec (from file on VDISK to
/dev/null)
z/OS-to-SLES9,  MTU=32760,  ~25 MB/sec (from disk cache on z/OS)
SLES9-to-SLES9, MTU=8184,   ~75 MB/sec
SLES9-to-SLES9, MTU=32760, ~400 KB/sec (not MegaBytes, KiloBytes!)

Has anyone else seen this?

I use 32760 on my hipersocket links so as to be consistent with the
32760
MTU size used on CTC links to other processors owned by my z/VM TCPIP
machine, which is used as the gateway between Linux guests on one
machine
and z/OS on the other machines.

Best regards,
 Mark Wheeler, 3M Company

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO
LINUX-390 or



visit


http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO
LINUX-390 or



visit


http://www.marist.edu/htbin/wlvindex?LINUX-390




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390
or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390






--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390
or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket Performance Problem on SLES 9

[Mark Wheeler]

Thanks Harold. Will check out the patch.

The scp problem w/ transfer rates that don't go above 8 MB/sec turns out
to be a CPU bottleneck. Our z9-109 doesn't have any crypto hardware so all
the encryption/decryption is being done in software. My speculation about
there being an I/O bottleneck due to scp not using cached files is
incorrect - caching is used, but the CPU approaches 50% for each of the two
virtual servers involved (sender and receiver), which kinda swamps my
single IFL engine. %-)

Best regards,
  Mark




 Harold Grovesteen
 [EMAIL PROTECTED]
 r.com To
 Sent by: Linux on LINUX-390@VM.MARIST.EDU
 390 Port   cc
 [EMAIL PROTECTED]
 IST.EDU  Subject
   Re: Hipersocket Performance Problem
   on SLES 9
 01/19/2007 04:55
 AM


 Please respond to
 Linux on 390 Port
 [EMAIL PROTECTED]
 IST.EDU






 From James Melin's 12/14/2006 post:

Mark, I saw something similar when we first went to SLES-9 (64 bit).  We
had MTU sizes being negotiated down to an idiotic packet size of 1492.
Whether or not this has to do with how our OSA is configured I never did
learn. Search for stuff with hipersockets and MTU in the archives for the
particulars.

We reported it to Novell. They eventually managed to test on SLES 9 under
z/Series and  eventually issued a patch. They sent us this file:

iputils-ss021109-147.2.PTF.184411.0.s390.rpm

I don't know whether or not this file is GA but it touched MANY IP related
items, indicating that the problem was pervasive.  Once we applied it our
MTU negotiation problem went away. It may or may not have bearing on your
situation, but I offer the information to any and all that might find it
relevant.

-J



barton wrote:

 I've seen this a lot. You need to find the real bottleneck. Are
 you equiped?



 Mark Wheeler wrote:

 More info:

 FTP GET's of this cached 256MB file to /dev/null have run as fast as 205
 MB/sec w/ MTU=32760 over hipersocket interfaces, and 168 MB over virtual
 CTCs. FTP PUT's are a different matter: hipersocket or CTC doesn't
 make a
 difference. The higher MTU size, the slower the transfer rate (from
 90-100
 MB/sec w/ MTU=16376 down to 10-15 MB/sec for MTU=32084. At MTU=32085,
 performance drops off a cliff, down to 400 KB/sec.

 So, one problem appears to be related to FTP PUT performance with
 large MTU
 sizes.

 In the process of investigating this alleged hipersocket performance
 problem (as reported by our Linux support person up four chains of
 management), I discovered an interesting issue with scp. It shows very
 limitted sensitivity for interface type, MTU size, or direction of
 movement), however I can't get it to run faster than 8 MB/sec (25 times
 slower than FTP GET). I'm using scp between two virtual Linux machines
 running on a 1-IFL system, so thought initially it may have been CPU
 contention (no hardware crypto on this box), yet CPU util was less
 than 5%
 on each machine. What I did see was the sending side doing a lot of disk
 I/O, something I don't see with FTP. Is it possible that scp reads from
 disk, bypassing the cache?

 Linux version 2.6.5-7.276-s390x

 Best regards,
Mark


 Greetings all,

 I've been using real hipersockets for a couple years now. Recently a
 significant performance problem with SLES 9 and large MTU sizes was


 brought

 to my attention. I've been using MTU=32760. I set up a test to
 illustrate
 the problem. I built a 256 MB file on one zLinux guest (running under


 z/VM

 5.2 on a z9-109), with enough storage defined so the file could be
 completely cached. I then FTP'd it to /dev/null on another server
 over a
 hipersocket connection. Here's what I observed:
 SLES8-to-SLES8, MTU=8184,   ~75 MB/sec
 SLES8-to-SLES8, MTU=32760, ~100 MB/sec (as high as 132 MB/sec)
 SLES8-to-SLES9, MTU=32760, ~100 MB/sec
 z/VM-to-SLES9,  MTU=32760, ~100 MB/sec (from file on VDISK to
 /dev/null)
 z/OS-to-SLES9,  MTU=32760,  ~25 MB/sec (from disk cache on z/OS)
 SLES9-to-SLES9, MTU=8184,   ~75 MB/sec
 SLES9-to-SLES9, MTU=32760, ~400 KB/sec (not MegaBytes, KiloBytes!)

 Has anyone else seen this?

 I use 32760 on my hipersocket links so as to be consistent with the
 32760
 MTU size used on CTC links to other processors owned by my z/VM TCPIP
 machine, which is used as the gateway between Linux guests on one
 machine
 and z/OS on the other machines.

 Best regards,
  Mark Wheeler, 3M Company

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO
 LINUX-390 or


 visit

 http://www.marist.edu/htbin/wlvindex

Re: Hipersocket Performance Problem on SLES 9

[Mark Wheeler]

More info:

FTP GET's of this cached 256MB file to /dev/null have run as fast as 205
MB/sec w/ MTU=32760 over hipersocket interfaces, and 168 MB over virtual
CTCs. FTP PUT's are a different matter: hipersocket or CTC doesn't make a
difference. The higher MTU size, the slower the transfer rate (from 90-100
MB/sec w/ MTU=16376 down to 10-15 MB/sec for MTU=32084. At MTU=32085,
performance drops off a cliff, down to 400 KB/sec.

So, one problem appears to be related to FTP PUT performance with large MTU
sizes.

In the process of investigating this alleged hipersocket performance
problem (as reported by our Linux support person up four chains of
management), I discovered an interesting issue with scp. It shows very
limitted sensitivity for interface type, MTU size, or direction of
movement), however I can't get it to run faster than 8 MB/sec (25 times
slower than FTP GET). I'm using scp between two virtual Linux machines
running on a 1-IFL system, so thought initially it may have been CPU
contention (no hardware crypto on this box), yet CPU util was less than 5%
on each machine. What I did see was the sending side doing a lot of disk
I/O, something I don't see with FTP. Is it possible that scp reads from
disk, bypassing the cache?

Linux version 2.6.5-7.276-s390x

Best regards,
   Mark


 Greetings all,

 I've been using real hipersockets for a couple years now. Recently a
 significant performance problem with SLES 9 and large MTU sizes was
brought
 to my attention. I've been using MTU=32760. I set up a test to illustrate
 the problem. I built a 256 MB file on one zLinux guest (running under
z/VM
 5.2 on a z9-109), with enough storage defined so the file could be
 completely cached. I then FTP'd it to /dev/null on another server over a
 hipersocket connection. Here's what I observed:
 SLES8-to-SLES8, MTU=8184,   ~75 MB/sec
 SLES8-to-SLES8, MTU=32760, ~100 MB/sec (as high as 132 MB/sec)
 SLES8-to-SLES9, MTU=32760, ~100 MB/sec
 z/VM-to-SLES9,  MTU=32760, ~100 MB/sec (from file on VDISK to /dev/null)
 z/OS-to-SLES9,  MTU=32760,  ~25 MB/sec (from disk cache on z/OS)
 SLES9-to-SLES9, MTU=8184,   ~75 MB/sec
 SLES9-to-SLES9, MTU=32760, ~400 KB/sec (not MegaBytes, KiloBytes!)

 Has anyone else seen this?

 I use 32760 on my hipersocket links so as to be consistent with the 32760
 MTU size used on CTC links to other processors owned by my z/VM TCPIP
 machine, which is used as the gateway between Linux guests on one machine
 and z/OS on the other machines.

 Best regards,
   Mark Wheeler, 3M Company

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket Performance Problem on SLES 9

[barton]

I've seen this a lot. You need to find the real bottleneck. Are
you equiped?



Mark Wheeler wrote:


More info:

FTP GET's of this cached 256MB file to /dev/null have run as fast as 205
MB/sec w/ MTU=32760 over hipersocket interfaces, and 168 MB over virtual
CTCs. FTP PUT's are a different matter: hipersocket or CTC doesn't make a
difference. The higher MTU size, the slower the transfer rate (from 90-100
MB/sec w/ MTU=16376 down to 10-15 MB/sec for MTU=32084. At MTU=32085,
performance drops off a cliff, down to 400 KB/sec.

So, one problem appears to be related to FTP PUT performance with large MTU
sizes.

In the process of investigating this alleged hipersocket performance
problem (as reported by our Linux support person up four chains of
management), I discovered an interesting issue with scp. It shows very
limitted sensitivity for interface type, MTU size, or direction of
movement), however I can't get it to run faster than 8 MB/sec (25 times
slower than FTP GET). I'm using scp between two virtual Linux machines
running on a 1-IFL system, so thought initially it may have been CPU
contention (no hardware crypto on this box), yet CPU util was less than 5%
on each machine. What I did see was the sending side doing a lot of disk
I/O, something I don't see with FTP. Is it possible that scp reads from
disk, bypassing the cache?

Linux version 2.6.5-7.276-s390x

Best regards,
   Mark



Greetings all,

I've been using real hipersockets for a couple years now. Recently a
significant performance problem with SLES 9 and large MTU sizes was


brought


to my attention. I've been using MTU=32760. I set up a test to illustrate
the problem. I built a 256 MB file on one zLinux guest (running under


z/VM


5.2 on a z9-109), with enough storage defined so the file could be
completely cached. I then FTP'd it to /dev/null on another server over a
hipersocket connection. Here's what I observed:
SLES8-to-SLES8, MTU=8184,   ~75 MB/sec
SLES8-to-SLES8, MTU=32760, ~100 MB/sec (as high as 132 MB/sec)
SLES8-to-SLES9, MTU=32760, ~100 MB/sec
z/VM-to-SLES9,  MTU=32760, ~100 MB/sec (from file on VDISK to /dev/null)
z/OS-to-SLES9,  MTU=32760,  ~25 MB/sec (from disk cache on z/OS)
SLES9-to-SLES9, MTU=8184,   ~75 MB/sec
SLES9-to-SLES9, MTU=32760, ~400 KB/sec (not MegaBytes, KiloBytes!)

Has anyone else seen this?

I use 32760 on my hipersocket links so as to be consistent with the 32760
MTU size used on CTC links to other processors owned by my z/VM TCPIP
machine, which is used as the gateway between Linux guests on one machine
and z/OS on the other machines.

Best regards,
 Mark Wheeler, 3M Company

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or


visit


http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or


visit


http://www.marist.edu/htbin/wlvindex?LINUX-390




--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390






--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
begin:vcard
note:If you can't measure it, I'm just not interested
version:2.1
end:vcard

Re: Hipersocket Performance Problem on SLES 9

[Mark Wheeler]

Just to bring everyone up to speed (it's been a while): I've done more
testing and so far have seen this only between two SLES9 systems. Things
run fine up to MTU=32084; at MTU=32085 and above throughput drops to
~400KB/sec. Problem has been reported to SuSE but haven't heard back from
them.

What do others use for hipersocket MTU size?

Mark


 Greetings all,

 I've been using real hipersockets for a couple years now. Recently a
 significant performance problem with SLES 9 and large MTU sizes was
brought
 to my attention. I've been using MTU=32760. I set up a test to illustrate
 the problem. I built a 256 MB file on one zLinux guest (running under
z/VM
 5.2 on a z9-109), with enough storage defined so the file could be
 completely cached. I then FTP'd it to /dev/null on another server over a
 hipersocket connection. Here's what I observed:
 SLES8-to-SLES8, MTU=8184,   ~75 MB/sec
 SLES8-to-SLES8, MTU=32760, ~100 MB/sec (as high as 132 MB/sec)
 SLES8-to-SLES9, MTU=32760, ~100 MB/sec
 z/VM-to-SLES9,  MTU=32760, ~100 MB/sec (from file on VDISK to /dev/null)
 z/OS-to-SLES9,  MTU=32760,  ~25 MB/sec (from disk cache on z/OS)
 SLES9-to-SLES9, MTU=8184,   ~75 MB/sec
 SLES9-to-SLES9, MTU=32760, ~400 KB/sec (not MegaBytes, KiloBytes!)

 Has anyone else seen this?

 I use 32760 on my hipersocket links so as to be consistent with the 32760
 MTU size used on CTC links to other processors owned by my z/VM TCPIP
 machine, which is used as the gateway between Linux guests on one machine
 and z/OS on the other machines.

 Best regards,
   Mark Wheeler, 3M Company

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390

 --
 For LINUX-390 subscribe / signoff / archive access instructions,
 send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
 http://www.marist.edu/htbin/wlvindex?LINUX-390


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Re: Hipersocket Performance Problem on SLES 9

[Tom Shilson]

We can't find this patch, or any mention of it, anywhere.  I have opened
an incident with SuSE and will post the results here.

tom
- - - - - - - - - - - -
Toto, I have a feeling we're not in the mainframe world any more.
   _/)  Tom Shilson
~Unix Team / IT Server Services
Aloha   Tel:  651-733-7591   tshilson at mmm dot com
   Fax:  651-736-7689



James Melin [EMAIL PROTECTED]
Sent by: Linux on 390 Port LINUX-390@VM.MARIST.EDU
12/14/2006 08:53 AM
Please respond to
Linux on 390 Port LINUX-390@VM.MARIST.EDU


To
LINUX-390@VM.MARIST.EDU
cc

Subject
Re: Hipersocket Performance Problem on SLES 9






Mark, I saw something similar when we first went to SLES-9 (64 bit).  We
had MTU sizes being negotiated down to an idiotic packet size of 1492.
Whether or not this has to do with how our OSA is configured I never did
learn. Search for stuff with hipersockets and MTU in the archives for the
particulars.

We reported it to Novell. They eventually managed to test on SLES 9 under
z/Series and  eventually issued a patch. They sent us this file:

iputils-ss021109-147.2.PTF.184411.0.s390.rpm

I don't know whether or not this file is GA but it touched MANY IP related
items, indicating that the problem was pervasive.  Once we applied it our
MTU negotiation problem went away. It may or may not have bearing on your
situation, but I offer the information to any and all that might find it
relevant.

-J




 Mark Wheeler [EMAIL PROTECTED]
 Sent by: Linux on 390 Port
 LINUX-390@VM.MARIST.EDUTo
 LINUX-390@VM.MARIST.EDU
  cc
 12/14/2006 08:33 AM
  Subject
 Hipersocket Performance Problem on SLES 9
Please respond to
   Linux on 390 Port LINUX-390@VM.MARIST.EDU








Greetings all,

I've been using real hipersockets for a couple years now. Recently a
significant performance problem with SLES 9 and large MTU sizes was
brought
to my attention. I've been using MTU=32760. I set up a test to illustrate
the problem. I built a 256 MB file on one zLinux guest (running under z/VM
5.2 on a z9-109), with enough storage defined so the file could be
completely cached. I then FTP'd it to /dev/null on another server over a
hipersocket connection. Here's what I observed:
SLES8-to-SLES8, MTU=8184,   ~75 MB/sec
SLES8-to-SLES8, MTU=32760, ~100 MB/sec (as high as 132 MB/sec)
SLES8-to-SLES9, MTU=32760, ~100 MB/sec
z/VM-to-SLES9,  MTU=32760, ~100 MB/sec (from file on VDISK to /dev/null)
z/OS-to-SLES9,  MTU=32760,  ~25 MB/sec (from disk cache on z/OS)
SLES9-to-SLES9, MTU=8184,   ~75 MB/sec
SLES9-to-SLES9, MTU=32760, ~400 KB/sec (not MegaBytes, KiloBytes!)

Has anyone else seen this?

I use 32760 on my hipersocket links so as to be consistent with the 32760
MTU size used on CTC links to other processors owned by my z/VM TCPIP
machine, which is used as the gateway between Linux guests on one machine
and z/OS on the other machines.

Best regards,
  Mark Wheeler, 3M Company

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390



--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390