Romney, again thanks for discussing this.  I did not know that more than one
packet (small as my datagrams may be) might be "pushed" in big chunks over
the CTC from TCP/IP on Linux to TCP/IP on VM.

In doing some more research on this, I see in the IBM Linux for S/390 Device
Drivers and Installation Commands doc for kernal 2.2.16 there is a note in
the CTC/ESCON device driver chapter which says:

  It is important that you have IOBUFFERSIZE 32678 defined because the
  LINUX for S/390 CTC driver works with 32k internally. This is configurable
  for each device by writing the value to the buffersize file for that
device
  (proc/net/ctc/<devicename>/buffersize ), for example

    echo 32768 >/proc/net/ctc/ctc0/buffersize

I don't see folder "ctc" under /proc/net.  I do understand that the echo
command shown above will create it.  And I will try that next.

Restating what I think you mentioned earlier, it seems that TCP/IP on VM is
limited to a 32K buffer.  I've looked in the TCP/IP for VM doc and I don't
see any records which control the size of that buffer.  Have I misunderstood
you or misread the doc?

Thanks for your assistance!

William P. Scully
Systems Programmer
Computer Associates International, Inc
[EMAIL PROTECTED]

-----Original Message-----
From: Romney White [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 13, 2002 12:17 PM
To: [EMAIL PROTECTED]
Subject: Re: FW: TCP/IP and Linux


Bill:

This has nothing to do with MTU size. MTU size determines the maximum
size of a datagram. The datagrams are packed into a 32K buffer for
transport across the CTCA. That's where the problem is occurring.

Romney

On Wed, 13 Feb 2002 11:49:03 -0500 Scully, William said:
>Thanks for the info Romney!  On one of the Linux servers where I get the
>error, I did an IFCONFIG and I find:
>
>
>linux017:~ # ifconfig
>ctc0      Link encap:Serial Line IP
>          inet addr:141.202.232.131  P-t-P:141.202.198.101
>Mask:255.255.255.255
>          UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
>          RX packets:7407345 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:13113625 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:100
>
>lo        Link encap:Local Loopback
>          inet addr:127.0.0.1  Mask:255.0.0.0
>          UP LOOPBACK RUNNING  MTU:3924  Metric:1
>          RX packets:2629004 errors:0 dropped:0 overruns:0 frame:0
>          TX packets:2629004 errors:0 dropped:0 overruns:0 carrier:0
>          collisions:0 txqueuelen:0
>
>
>I see an MTU of 1500 on ctc0.  So how did such a large packet end up on the
>CTC between Linux and VM?
>
>-----Original Message-----
>From: Romney White [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, February 13, 2002 11:02 AM
>To: [EMAIL PROTECTED]
>Subject: Re: TCP/IP and Linux
>
>
>Bill:
>
>The message is documenting the fact that Linux sent a malformed block
>of packets across the CTCA. The blocks may be up to 32K (32768 bytes)
>long, so a packet starting at 33134 is clearly an error. The offending
>packet is at offset 31628 in the buffer.
>
>I presume that there is a mismatch in the buffer size between Linux
>and VM TCP/IP and hope there is a control you can set on the Linux
>side to use a buffer size of 32K.
>
>Romney
>
>On Wed, 13 Feb 2002 10:55:27 -0500 Scully, William said:
>>(Cross-posted to the VM and Linux on 390 lists)
>>
>>We find a lot of the following messages on TCP/IP's console (FL 3A0)
>>regarding the CTCs for Linux servers:
>>
>>22:50:10 DTCCTC008E CTCA device LINUX016: UnpackReads: Inv blk hdr 33134
>>from input position 31628. Last blk hdr 0.  Discarding remainder of block.
>>
>>
>>Are others of you out there seeing this?  The message doesn't seem to be
>>documented.  What does it mean?  It appears that some (but not all)
servers
>>loose connectivity when this happens.
>>
>>William P. Scully
>>Systems Programmer
>>Computer Associates International, Inc
>>[EMAIL PROTECTED]

Reply via email to