[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference lassie::ucx

Title:DEC TCP/IP Services for OpenVMS
Notice:Note 2-SSB Kits, 3-FT Kits, 4-Patch Info, 7-QAR System
Moderator:ucxaxp.ucx.lkg.dec.com::TIBBERT
Created:Thu Nov 17 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5568
Total number of notes:21492

5321.0. "efault error when send size >64k" by CSC32::J_HENSON (Don't get even, get ahead!) Fri Mar 07 1997 16:02

ucx v4.0 eco 5, tcp protocol, ovms v5.5-2, vax c

A customer is attempting to send large messages using the socket i/f.
Their tcp protocol send and receive quotas (via ucx show protocol tcp/par) 
are both 4k, they call setsockopt with the ucx$c_sndbuf option to set the 
send buffer to 50k.  They then attempt to send messages larger than 50k.

When they attempt to do this on a vax, as described above, any sends
of more than 64k bytes fails with an errno value of 14 (efault).
They only get this error when sending messages larger than 64k.  Message
sizes between 50 and 64k are ok.

They claim that they can do the same thing with a dec c program
on an alpha (ucx v3.3, ovms v6.1), with the same tcp quota
settings, and they can send 200 and 300k byte messages in a
single send.

Any ideas as to what to do with this?  Should I insist they use
dec c, or at least link against the dec c rtl?

Thanks,

Jerry
T.RTitleUserPersonal
Name		DateLines
5321.1Use Smaller Sends; Bigger QuotasUCXAXP::MYTHM. T. HollingerFri Mar 07 1997 19:0737
    Sending a message larger than then send buffer quota generally leads
    to poor performance.  What happens is that the send operation blocks
    partway through, until the initial data is sent and acknowledged.
    
    For example, suppose your send quota is 16k, but you send a 20k
    message.  If the send buffer is initially empty, then your send
    operation will be able to send the first 16k.  After that, the I/O
    operation will block until the remote end acknowledges some or all of
    the first 16K, at which point the final 4k can be copied into the send
    buffer.
    
    If your send quota had been, say, 32k in the above example, then the
    operation would have completed immediately, without even waiting for
    the data to go out on the wire, much less acknowledged.
    
> They claim that they can do the same thing with a dec c program
> on an alpha (ucx v3.3, ovms v6.1), with the same tcp quota
> settings, and they can send 200 and 300k byte messages in a
> single send.
    
    Sending more than 64k bytes in a single I/O operation is not supported. 
    We've done some work toward making that possible, and in some versions
    of UCX, the send operation will succeed, but it has never been fully
    supported.
    
    The reason is the structure of the IOSB: it presently includes only 2
    bytes for the return length.  Thus, if you try to send 200k of data,
    and only part of it is accepted (due to an error, or a full buffer on a
    non-blocking socket), you can't tell how much data went out.  If you
    get back a length of 50k in the IOSB, is that really 50k, or 114k (50
    plus 64), or 178k (50 plus 128)?  You only have 16 bits of length info.
    
    For performance-critical applications, I recommend running over FDDI,
    with send and receive buffer settings of 200000 bytes, and sending 32k
    bytes in each application transmit operation.
    
              - MyTH
5321.2thanksCSC32::J_HENSONDon't get even, get ahead!Mon Mar 10 1997 11:4116
>>              <<< Note 5321.1 by UCXAXP::MYTH "M. T. Hollinger" >>>
>>                     -< Use Smaller Sends; Bigger Quotas >-

>>    Sending more than 64k bytes in a single I/O operation is not supported. 
>>    We've done some work toward making that possible, and in some versions
>>    of UCX, the send operation will succeed, but it has never been fully
>>    supported.
    
Thanks.  Great answer.

In anticipation of customer feedback, though, is this limitation documented
anywhere?  I've been looking, but unable to find it.

Thanks,

Jerry