Conference 7.286::fddi

1366.0. "DTSEND & FDDI throughput" by ZPOVC::THIAMPENG () Thu Jun 09 1994 13:54

Hi,

I recently performed some throughput testing to compare the performance of a
FDDI network card and a normal ethernet card. The tool used was VMS DTSEND 
utility. I am not sure if this is the right tool, though.

The same test was carried out at 2 customer sites. Both seem to suggest that a 
normal ethernet circuit has higher throughput than a FDDI one. Even a NCP LOOP
from a "FDDI node" to a "normal ethernet node" took shorter time to complete
than one from a "FDDI node" to another "FDDI node".

Assuming there is no possibility of the test packets straying elsewhere before
finally arriving at its destination, is what I saw "normal". Or was there 
something wrong with my interpretation ?

Following are the details :

For customer A, 3 nodes were used for testing :

V7000 - a VAX 7000 with a MNA circuit (Ethernet)
V9000 - a VAX 9000 with a MFA circuit (FDDI)
V9001 - a VAX 9000 with a MFA circuit (FDDI)

Test used : $ MCR DTSEND
	    _Test: DATA/SEC=20/NODE=XXXXX/SIZE=XXXX

Results :

When the tested is issued from V9000, the line thruput (baud) is as follows:

				Target node	Target node
				   V7000	   V9001
				---------------------------

Message size=128 bytes		   778440	   304944

Message size=1024 bytes		  2877848	  1241496

Message size=4096 bytes		  6221000	  3175216


When the tested is issued from V9001, the line thruput (baud) is as follows:

				Target node	Target node
				   V7000	   V9000
				---------------------------

Message size=128 bytes		   977304	   199264

Message size=1024 bytes		  5074120	  1225928


For customer B, the nodes used were :

SRCV02 - a VAX 4000 with a ISA circuit (Ethernet)
SRCV03 - a VAX 4000 with a ISA circuit (Ethernet)
SRCV01 - a VAX 6000 with a MFA circuit (FDDI)
SRCV08 - a VAX 6000 with a MFA circuit (FDDI)

When the tested is issued from SRCV01, the line thruput (baud) is as follows:

                                Target node     Target node
                                  SRCV03           SRCV08
                                ---------------------------

Message size=128 bytes             754784          395104

Message size=1024 bytes           5622576         3258776

Message size=4096 bytes           6927152	  3240752
                                                                                

When the tested is issued from SRCV08, the line thruput (baud) is as follows:

                                Target node     Target node
                                  SRCV03           SRCV01
                                ---------------------------

Message size=128 bytes            1807456          395776


When the tested is issued from SRCV02, the line thruput (baud) is as follows:

                                Target node     Target node
                                  SRCV03           SRCV01
                                ---------------------------

Message size=128 bytes             655456          205256

"NCP LOOP NODE XXXXXX COUNT 10000" were also performed. When the command was
issued from SRCV08 to SRCV01, the time taken is often longer than when the same
command was issued from SRCV08 to SRCV03.



Thanks in advance,
Thiam Peng.

DTSEND is absolutely the wrong tool for this.  Neither DTSEND nor NCP LOOP
are performance test tools.  DTSEND is a protocol tester, and NCP LOOP is
a connectivity test.

One of the specific issues with both is that they send one packet at a time.
Therefore the result tells you essentially nothing about throughput.  It tells
you a little bit about latency, which may explain why the numbers are lower
for FDDI than for Ethernet (the FDDI adapter and channel probably has a bit
more latency).

A more meaningful test would be a file copy of a large file, either via
DECnet or via vms cluster services.  In the case of FDDI, you may end up
measuring the disk speed rather than the FDDI speed, though.  There may also
be test programs around that do measure throughput ("Bricks" does, but I'm not
sure if that exists for VMS).  But the two you used are absolutely no good
for this.

	paul

    Bricks does run on VMS, but it needs UCX to be able to compile and it
    needs X windows to be able to run.  It can "test" DECnet, TCP, and UDP.  
    I put "test" in quotes because bricks is really a performance demo 
    rather than a performance tester, but it will do.
    
    See NPSS::BRICKS for more info.
    
    But, a file transfer might be an easier test.  But, as Paul said, you
    might end up measuring disk thruput rather than network.  But you 
    could create a memory disk and do the copies from/to there.

    Paul & Kelly,
    
    Thanks for your input.