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

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

2497.0. "Poor performace using DS900EFs for Netware?" by SNOFS1::63496::SYSTEM () Tue Jul 11 1995 03:22

    Hi,
    
    Is there any Performance paper available on DECswitch 900EF?
    
    My customer had done some tests on DS900EFs using Netware server/client
    (both V3.1 and V4.0) had been tested.
    
    They found that PC client access to server via direct Ethernet (server
    and client on the same Ethernet LAN) is 40% faster than if the
    client on one Ethernet LAN (connected a DS900EF) then FDDI to the
    server via another DS900EF. Both DS900EFs are dedicated for the tests
    no other users at all. DS900EFs are connected via Gigaswitches and
    everything works fine, except the poor performance between
    client/server via two DS900EFs.
    
    
    Netware server/client setup to use Ethernet II framing.
    
    Any idea on why the performance over two DS900EFs is so poor for
    Netware server/client file access?
    
    PS: They use the same PCs and same files for these tests.
    
    
    Thanks
    Andrew Chiu - Network Services Sydney
T.RTitleUserPersonal
Name
DateLines
2497.110 segment on the HUB.TKTVFS::KIMIZUKAE-Japan SI Unit-1/SI Div./MCSTue Jul 11 1995 05:4941

                                              +---------------------------+
                                          +---|-----------------------+   |
                                      +---|---|-------------------+   |   |
                        +-------------|---|---|-------------+     |   |   |
                    +---|-------------|---|---|---------+   |     |   |   |
                +---|---|-------------|---|---|-----+   |   |     |   |   |
Front           |   |   |             |   |   |     |   |   |     |   |   |
      +-------+-3-+-4-+-5-+ +-------+-3-+-4-+-5-+ +-5-+-6-+-7-+ +-5-+-6-+-7-+
      |  PORTswitch900TP  | |  PORTSwitch900TP  | |PEswitch   | |PEswitch   |
      |   |   |   |   |   | |   |   |   |   |   | |     900TX | |     900TX |
      |Gr1|Gr2|Gr3|Gr4|Gr5| |Gr6|Gr7|Gr8|Gr9|GrA| |           | |           |
      |   |   |   |   |   | |   |   |   |   |   | |           | |           |
      +-1-+-2-+-----------+ +-1-+-2-+-----------+ +-1-+-3-+-4-+ +-1-+-3-+-4-+
Back    |   |                 |   |                 |   |   |     |   |   |
[FDDI]==|===|=================|===|=================+===|===|=====+===|===|===
        |   |                 |   |                     |   |         |   |
[LAN1]--+---|-----------------|---|---------------------+---|---------|---|---
            |                 |   |                         |         |   |
[LAN2]------+-----------------|---|-------------------------+---------|---|---
                              |   |                                   |   |
[LAN3]------------------------+---|-----------------------------------+---|---
                                  |                                       |
[LAN4]----------------------------+---------------------------------------+---


  1.Each PEswitch900TX connect 900MS Multi Channel(FDDI).

  2.Each PORTswitch900TP separate 5 group.
    (Gr1,Gr2,Gr3,Gr4,Gr5,Gr6,Gr7,Gr8,Gr9,GrA=Gr10)

  3.Each PORTswitch900TP Gr1,Gr2,Gr6,Gr7 connect 900MS Multi Channel. 
    LAN1,LAN2,LAN3,LAN4

  4.Each PORTswitch900TP Gr3,Gr4,Gr5,Gr8,Gr9,GrA connect PEswitch900TP Front 
    10Base-T port.
    Not connect Multi Channel.

  My Customer want 10 Group LAN in the DEChub900MS.
  *** This Configration is OK ?
2497.2Performance Degradation expectedNETCAD::KRISHNATue Jul 11 1995 20:1831
    
    A point to note about Novell IPX is that it is a Request-Response
    protocol where each request is explicitly acknowledged by a response.
    It does not use any sliding window mechanism to better utilize the
    network bandwidth. When a client boots and establishes contact with the
    server, in the order of 10000 or more frames are exchanged and
    these packets are large 1000+ bytes. In your configuration these frames
    have to traverse 2 ethernets and an FDDi ring. In the case of ethernets
    a 1000+ byte frame would have ~1 msec of transmission delay. The FDDI
    transmission delay would be 1/10th of that, but you have to consider
    how busy the ring is because that relates to the time it takes to grab
    the token and transmit. The switches themeselves have some latency to
    translate and forward these frames, but that is negligible compared to
    these other time factors. Another factor that could play into this, is
    that Novell's retry timer is dynamically adjusted based on the
    roundtrip transfer times of packets. It may start out very small, thus
    causing more retries before it converges to a retry interval that is
    suitable for the topology. If you add the numbers up for the case of
    10000 frames you would see an additional time of 10+ seconds to the
    case where the client and server are on the same ethernet.
    
    If the purpose of separating the servers to another ethernet is to
    provide them with dedicated bandwidth, then putting them on the same
    switch in different ports would be better in terms of performance. You
    would not have to contend with the packet translation and FDDI
    transmission delays. The other alternative is to have the servers on
    FDDI, this would increase the packet delays a little bit, but would
    provide 10 times the bandwidth.
    
    Hope this helps,
    Krishna
2497.3try packet burstDPDMAI::daveslap.sca.dec.com::KORNSLike you get on your feet, except with a "K"Thu Jul 13 1995 01:0510
Ask the customer to try enabling the new Novell 'packet burst'
software feature. This provides a sliding window type scheme
to the upper level Netware protocol allowing multiple transmits
prior to receiving an acknowledgement. This should improve things
if the slow down is a result of added latency.

This software was initially an optional product/kit but I think
it is part of some recent version of the Netware product.

Dave,
2497.4I believe this belongs to this thread of notes....NETCAD::BATTERSBYMon Jul 17 1995 10:0826
            <<< NETCAD::KALI$USER3:[NOTES$LIBRARY]HUB_MGNT.NOTE;1 >>>
                   -< DEChub/HUBwatch/PROBEwatch CONFERENCE >-
================================================================================
Note 2526.0                  IP is better than IPX!                   No replies
SNOFS1::63496::SYSTEM                                20 lines  16-JUL-1995 20:48
--------------------------------------------------------------------------------
    re .2/.3
    
    Thanks for your help!
    
    Customer also tested with IP (using ftp) the same PC but to AXP running
    OSF/1 V3.2, the performance using Ethernet-Ethernet is still better
    than Ethernet-FDDI-Ethernet (via two DS900EFs) and is about 10-15%.
    This gives me an idea that IPX is not so good even in LAN when compared
    to IP. We will try to look into their Netware configuration to see
    whether we can do some tuning. Some questions need clarification:
    
    1) What is the difference between using Ethernet Frame and 802.3 frames
    in Netware? 
    
    2) When DS900EF translate ethernet frames to FDDI, is there any
    difference between Ethernet II and 802.2/3 frame?
    
    
    thanks again for help/idea.
    Andrew Chiu - Network services sydney