On Monday, 12/10/2001 at 11:02 EST, Nick Gimbrone <[EMAIL PROTECTED]> wrote: > > The MTU sizes on both sides of the CTC connection must match. Make both > > sides 32768 or something. (VTAM CTC connections have the same issues! If > > the buffer sizes don't match you get truncated PIUs...) This is the nature > > of the CTC hardware (virtual or real). > No, it is in the nature of the drivers that they are not constructed such that > they automatically "discover" the other side's MTU. Such software could be > written, and it should be written... and then this configuration pitfall would > be long gone (as it should be).
MTU discovery is not the issue. At this point we're talking about physically moving data in/out of the device. There is no information in the I/O interrupt about how many bytes need to be read, and it is often the case that there is simply a read outstanding of 'n' bytes. The LCS and QDIO network-oriented protocols don't have a problem -- they're smart devices. But the CTC is just a data "repeater". Both sides must administratively agree on the maximum data length. If they don't, a short read results in data loss (the CTC doesn't hang onto data that wasn't read the first time 'round.) It would have been better if the TCP/IP CTC protocol included an exchange of buffer sizes using a pre-defined small I/O buffer. But it didn't and that's the way the ball bounces. (The restriction being that the MTU would be forced to be less than the I/O buffer size.) Regards, Alan Senior Software Engineer z/VM, TCP/IP, VIF, and Linux for zSeries Development, Endicott, NY Phone 607.752.6027 fax 607.752.1497 t/l 852
