Conference 7.286::fddi

1164.0. "Thrupt Problem OSF/1->aVMS via FDDI" by 17311::KENOYER (Greg Kenoyer { SecureAMC/CSC }) Wed Dec 01 1993 10:36

  (cross-posted in AOSG::ALPHA_OSF_IFT and UPSAR::FDDI)

  I've a customer who seems to be having a problem with FDDI thruput.  He
  reports ethernet speeds (2 Mb/sec) instead of FDDI speeds (60+ Mb/sec).

  He is doing a memory-to-memory transfer via TCP.  The machines are on the
  same subnet (hosts 131.1.225.1 and 131.1.225.2 with netmask 255.255.255.0)

  One oddity is that ftp over this link reports 6 Mb/s; this seems to imply 
  an application problem?   

  Questions:

  1) Searching the FDDI, OSF, and VMS conferences I find most folks getting
  well over the (expected) 60 Mb/s on both OSF and VMS.  There is no mention
  of special tuning or other non-obvious steps taken.  Is special tuning
  required?

  2) There are multiple devices on the Turbochannel, could there be some sort
  of bandwith/timing problem?

  3) Can anyone point me to a simple (and releasable) piece of benchmarking
  code? (OSF -> VMS)
  
  5) Is the 6 Mb/s ftp thruput reasonable?

  4) What else should we examine? Note that while I'm quite happy to use the
  U-word, I've limited experience on OSF/1 and none on FDDI; the actual
  command needed to obtain the info would be appreciated.

  *********************************************************************
  *********************************************************************

  These two systems are (usually) connected via a DECconcentrator 500,
  however the same thruput is seen when directly connected.

  *********************************************************************
  *********************************************************************

  Transmitting system:

    DEC 3000/500 with 256 MB memory
    OSF/1 v1.2 (with RT kernal)
    DEFZA controller
    Genroco (sp?) drives (on IPI?), with patched drivers
    VME i/f, with patched drivers
  --> note that they're afraid to move to v1.3 due to the drivers for the
      above two special devices.  The patches/drivers were obtained both from
      DEC and the folks who supplied the orig. hw.

  uerf on the startup record (rec 300)
   __________________________________________
  CPU SUBTYPE:	KN15AA
  Alpha Boot: available memory from 
    _0x8f0000 to 0xe000000
  DEC OSF/1 [RT] V1.2 (Rev. 10); Sat Nov
    _20 20:12_02 MST 1993
  physical memory = 222.00 megabytes
  available memory = 206.00 megabytes
  using 852 buffers containing 6.65
    _megabytes of memory
  tc0 at nexus
  scco at tc0 slot 7
  asco at tc0 slot 6
  rz3 at asc0 bus 0 target 3 lun 0 (DEC
    _  RZ26  (C) DEC T386)
  rz4 at asc0 bus 0 target 4 lun 0 (DEC
    _  RRD42  (C) DEC 4.5d)        
  asc1 at tc0 slot 6
  tz8 at asc1 bus 1 target 0 lun 0 (DEC
    _  TKZ09  90097000 045H)
  rb0 at tc0 slot 8
    1280X1024
  ln0: DEC LANCE Module Name: PMAD-BA
  lm0 at tc0 slot 7
  ln0: DEC LANCE Ethernet Interface,
    _hardware address:  08:00:2b:37:8a:17        
  fza0 at tc0 slot 0
  fza0: DEC DEFZA FDDI Interface,
    _hardware address:  08:00:2b:35:9c:41
    _ROM rev 1.0 Firmware rev 1.2
  ipi0 cache size = 0 Mbytes
  ipi0 at tc0 slot 1
  ipi0 at tco slot 2 (3VIA/MVIB)
   * VME probe routine - SVA addr1
    fffffc0140080000
  dmaex0 at vba0 csr 0x4000 vmea16d32
   _supervisory data mode vec 0x40
   _priority 3
  DEC3000 - M500 system
  Firmware re4vision: 2.1
  PALcode: OSF version 1.28
  lvm0: configured.
  lvm1: configured.
  ra1 at ipi0 slave 1 (IPI91)
  ra0 at ipi0 slave 0 (IPI91)
    _
    output of netstat -m
   __________________________________________
  25/128 mbufs in use:
  	18 mbufs allocated to data
  	7 mbufs allocated to socket names and addresses
  20/50 mapped pages in use
  400 Kbytes allocated to network (40% in use)
  1 requests for memory denied
  0 requests for memory delayed
  0 calls to protocol drain routines
   __________________________________________

    output of netstat -i
   __________________________________________
  Name	Mtu	Network	  Address   Ipkts Ierrs  Opkts  Oerrs  Coll
  ln0	1500	LAT	  none	     1008     0   1010      0     6
  ln0	1500	<Link>	     	     1008     0   1010      0     6
  ln0	1500	131.1.224 IDS 	     1008     0   1010      0     6
  fza0	4352    LAT	  none	       98     0   2003      0     0
  fza0	4352    <Link>	       	       98     0   2003      0     0
  fza0	4352    131.2	  ids_fddi     98     0   2003      0     0
  s10	296     <Link>	                0     0      0      0     0
  s11	296     <Link>	                0     0      0      0     0
  lo0   1536    <Link>              89266     0  89266      0     0
  lo0   1536    loop      localhost 89266     0  89266      0     0
   __________________________________________
  
    output of fddi_config -I fza0 -s
   __________________________________________
  Firmware Revision:		1.2
  ROM Revision:			1.0
  SMT Version ID:		1
  Requested TRT:		8.000 ms
  Maximum TRT:			173.015 ms
  Valid Transmission Time:	2.621
  LEM Threshold:		8
  Restricted Token Timeout:	1000.000 ms
  PMD Type 			ANSI Multimode
  

  fza0 ANSI FDDI settable parameters

  Token Request Time::		8.0000 ms
  Valid Transmission Time:	2.6214
  LEM Threshold:		8
  Restricted Token Timeout:	1000.000 ms
  Ring Purger State:		Purger off

  >> the fza0 FDDI counters show no errors, unrecognized frames, dups, rejects,
  etc.

  *********************************************************************
  *********************************************************************

  Receiving system:

    DEC 3000/400 with 64 MB
    OpenVMS v1.5
    UCX 3.0
    DEFTA controller

    mtu is 4348

  No more info on this one: tell me what you need!

DEFZAs suck.  Upgrade it to a DEFTA.