Conference 7.286::fddi

    There is a method to set the maximum sized receive buffer the DEMFA
    will accept. Right now, the VMS driver specifies the FDDI maximum
    frame length (plus three extra bytes of DEMFA specific stuff), and
    there is no user interface selection/setting of that parameter. SO
    to answer your question, yes the device allows a max receive spec, but
    No the driver won't let you touch it.
    
    For transmit, we will transmit whatever size is asked for by an
    application, within FDDI max frame size limits. There is no across
    the board parameter that limits the size of transmits.
    
    It sounds like the customer is sacrificing a lot to save a few bucks.
    That kind of bridge won't be very useful in the long run. Why spend
    all that money for the other FDDI hardware to turn around and limit
    the size of the packet? Did he pay all that extra money for the higher
    bandwidth just to disable it? Doesn't make sense.
    
    FWIW, we can not and should not put any limitations in our products
    that prevent us from taking advantage of the full FDDI frame sizes
    available. We would be sacrificing performance for *everyone* in order
    to make this one third party (hack) bridge work. Not likely to fly.
    
    If the ***ONLY*** issue is that the bridge can't do IP fragmentation,
    then if they are using UCX, you might be able to get them a version
    of UCX that limits itself to certain sized transmits. I suggest
    contacting the UCX folks directly to pursue. However, I must caution
    you that while that might take care of IP,.. it could really screw up
    other things (like Clusters, LAT, DECnet,...).
    
    Bottom line,.. the bridge they want to buy is bogus. I'd try to convince
    them of that. If money is the issue and they don't want to pay for
    our cadillac bridge, there are other third party bridges available
    at better prices that don't have that problem.
    
    Just out of curiosity,.. who makes this bogus bridge?
    
    							/Bill
    

If all customers made rational decisions the "field"
would be a "kinder-gentler" place. 

FYI - the bridge is made by Synernetics and their
major selling feature is the ability to mux 8 ethernet segments. Given other
weeknesses in their product I think we can win this sale.

Thanks again.

Rob
 

    Previous comments will win the sale, but they don't serve the customers.
    FDDI should play together with Ethernet in reasonable ways.

    I don't recall how IP (in UCX) chooses its transmit frame sizes, except
    that all frames sent over a given LANcontroller will be limited by that.
    If IP cannot select different frame sizes according to the destination
    address of each packet, then how about this:

    Install both FDDI and Ethernet controllers in the VAX.  Set up the
    network topology so that IP packets destined for the Synernetics bridge
    leave the VAX via Ethernet.  That way, all-FDDI IP packets continue to
    use a large frame size, and the rest use the Ethernet size.

    I have no idea if UCX supports multiple LAN controllers.  Just wanted
    to offer a technical (vs. marketing) solution to the problem.

I think that if you set LRPSIZE to something like 1500 on the VAX, the FDDI
packet sizes will be limited to that value.

    No, setting LRP size does not affect the size of the buffers used by
    the device.
    
    It just means that the buffers allocated by the driver will not
    come from the LRP list,.. since the LRPs won't be big enough. They
    will then come out of variable non-paged pool, carrying a nasty
    performance hit with each allocation. This idea won't work, won't help,
    and may (probably will) hurt.
    
    								/Bill
    
    
    

    Clarification:
    
    	While what I said in the previous reply is indeed true for the
    driver, it does not tell the whole story. The driver allocates
    its own receive buffers to be of sufficient sizxe to hold a max sized
    FDDI frame. This is done regardless of LRP size, and if need be, the
    buffers will be alloctaed from variable sized non paged pool. When
    the receive buffer is being processed for a user, the driver will
    drop any message that was bigger than the user's receive buffer size.
    
    	On transmit, we simply send what is asked of us within the limits
    of FDDI frame sizes. We do not allocate any buffers for transmit. We
    DMA directkly form the user buffers. So the size we end up transmitting
    is entirely dependent on what the application asks for. Some
    applications like Clusters (if you can all that an "application")
    allocate their transmit buffers explicitly from the LRP list. They
    will not take buffers from variable non paged pool. For these
    applications, setting LRP size will affect the size of the buffers
    transmitted (and thus, the size received at the remote station).
    I'm not sure what our UCX product does/will do for FDDI. I suggest
    contacting Alex (LADDIE::) Conta with that question. Probably a good
    idea to post any info here after you get it.
    
    							/Bill
    

    Here is some info from Alex.
From:	LADDIE::CONTA        "Alex Conta - DEC TCP/IP for VMS"  3-SEP-1991 19:13:58.25
To:	ROUTES::NICHOLS
CC:	CONTA
Subj:	RE: Setting TCP/IP packet size for FDDI Controller 400

UCX will have support for FDDI in V2.0. The MTU size is not changable
I am not sure if I will be able (timewise) to put in a setable MTU for 2.0


Alex

---------
From:	ROUTES::NICHOLS "NEGD - Network Consultant  03-Sep-1991 0851"  3-SEP-1991 08:53:12.86
To:	laddie::conta
CC:	NICHOLS
Subj:	Setting TCP/IP packet size for FDDI Controller 400

Alex -

I have been working with Bolt, Beranek, and Newman on their FDDI configuration
and they have asked me about specifying the size of TCP/IP packets via UCX
for the FDDI Controller 400. In this instance they may purchase a 3rd Party
FDDI smart hub/bridge which does not do IP packet fragmentation. Therefore,
they are interested in the ability to limit the transmit packet size to <1500
rather than using the default/maximum packet size of 4500 bytes. With the 
FDDI functionality in DEC TCP/IP Services provide this sort of capability ?

Any feedback you might provide would be appreciated.

Hope to see you soon.

Rob