Unixware 2.0.3 Ethernet 100 mbit transfer rates...

hi joe.
i am sorry you found my message very vague and "mumbly".
here are the hard facts. There are only two machines on the network. They
both have Intel PCI cards and I have done this test with SMC cards as well.
To correct the unfortunately wrong message I conveyed to you, I am running
266 MHz Intel boxes (Incidentally SCO in their site say that you can run it
on 386 16 mhz ). The ethernet cards themselves are 100 Mbits/s cards. When I
do an ftp and rcp to the local host (i did mention rcp in my original
message, again unfortunately, i forgot to highlight it) it behaves quite ok
which means there is no problem with the tcp stack itself. When we run it
through ethernet (both ftp, rcp and our "sitting on top" application)
connection, it screws up with 800kbytes/s. by simple mathematics 100mbits
may mean roughly about 8 mega bytes per second (unless i am confused again)
and my question was "why ?".
you may reiterate again - "in this technical world, what business people
consider quite ok is not quite alright". here are the statistics:
machine1 - machine 1 using ip address to address itself
8 mb file takes 3 secs to transfer using ftp(1)
machine1 - machine 2 using ip address to address the other machine
8 mb file takes 12 secs to transfer using ftp(1).
rcp and s.o.t.application also corroborate these figures.
i would appreciate it if you can really help. if you are still following
this thread, doug apel's message is quite enlightening and intriguing.
thanks much in advance.
sundar

Okay, I got interested in this thread, so I ran the following numbers. All
tests were conducted over known good 100MB/sec theoretical links (100Base-T,
certified on cat 5 using Fluke equipment). Switches are all 3Com LinkSwitch
3000TX. All links are also configured at Half-Duplex currently. FTP was used
in each test, as supplied by the respective operating system vendor.

These are the pieces of equipment involved in the testing:
Dell XPS D300, 3Com 905, NT 4.0/SP3 WS (machine #1), no load
HP C200 workstation, built-in 10/100, HPUX 10.20 (#2), heavy load
HP C200 workstation, built-in 10/100, HPUX 10.20 (#3), light load
Compaq Proliant 2500R server, built-in 10/100, Unixware 2.1 (#4), heavy load

The Unixware server is also my companies primary NFS server, handling
transactions from about 100 clients. The tests were run at 2:30 in the
afternoon, so some results may be skewed by interference from "real" activity.
The UW box has no patches installed on it, just the basic 2.1 installation.

For the testing I made an 83MB tar file of the NT40 i386 tree. All functions
were done as "binary" mode FTP transfers.

Test #1: NT 4.0 ftps to Unixware 2.1
put 83MB in 16.68 seconds, 5097K/sec
get 83MB in 25.26 seconds, 3300K/sec

Test #2: HPUX 10.20 (#2) ftps to Unixware 2.1
put 83MB in 14.39 seconds, 5697K/sec
get 83MB in 162.41 seconds, 504K/sec

Test #3: Unixware 2.1 ftps to HPUX 10.20 (#3)
put 83MB in 14 seconds, 5900K/sec
get 83MB in 16 seconds, 5100K/sec

Test #4: HPUX 10.20 (#3) ftps to Unixware 2.1
put 83MB in 16.18 seconds, 5069K/sec
get 83MB in 15.68 seconds, 5229K/sec

Test #5: HPUX 10.20 (#2) ftps to Unixware 2.1 (trying this again!)
put 83MB in 14.25 seconds, 5755K/sec
get 83MB in 149.30 seconds, 549K/sec

Test #6: HPUX 10.20 (#3) ftps to HPUX 10.20 (#2)
put 83MB in 22.13 seconds, 3704K/sec
get 83MB in 13.21 seconds, 6208K/sec

Test #7: HPUX 10.20 (#2) ftps to HPUX 10.20 (#3)
put 83MB in 21.23 seconds, 3862K/sec
get 83MB in 30.37 seconds, 2700K/sec

Test #8: NT 4.0 ftps to HPUX 10.20 (#3)
put 83MB in 20.80 seconds, 4036K/sec
get 83MB in 27.20 seconds, 3087K/sec

Test #9: NT 4.0 ftps to HPUX 10.20 (#2)
put 83MB in 29.26 seconds, 2870K/sec
get 83MB in 23.93 seconds, 3509K/sec

Based on these admittedly not-very-scientific results, I'd have to say that
Unixware does not have any sort of horrible throughput. Since all the servers
in my tests were production boxes doing a variety of things, I don't think 3-6K
per second is that bad. Throughput to a variety of operating systems, with
different network controllers and disk subsystems, yielded fairly similiar
results for almost all the gets and puts.

What does surprise me is that one strange result -- ftp-ing from an HP box to
the Unixware box, executing a get command for the 83MB file, and having it take
more than 2 minutes (Tests #2 and #5)! I ran sar -d and netstat -i during Test
#5, and the disks on both sides were relatively idle, and I was seeing only
about 200 packets per second. During the fast transfers, the disks were doing
some real work and packets/second were in the 1000+ range. I cannot account
for this disparity.

Overall, though, I'd say that Unixware 2.1 has pretty decent throughput on my
hardware, at least as good as either of my HP big-dollar machines. Part of the
speed differences in reads/writes may be in part due to differences between
hardware RAID 5 controllers between the three servers, and also to the
real-world users trying to actually get work done!

Can anyone submit comparable results, or give evidence that Unixware has some
sort of network transfer slowness problem?


Doug Apel
Network Administrator
Omnipoint Technologies, Inc.

*** The opinions expressed in this
*** document do not (necessarily)
*** reflect the view of my employer

In this highly technical business people read the technical items
carefully and become very confused with the terms are used improperly,
which is the near equivalent to verbally mumbling. Quantities have dimensions,
Bytes (B), or MB (megabytes), bits (b), and so on. Rates have dimensions too,
quantity per unit something such as time. Intel makes lots of money by quoting
cpu clock MHz rates.
First, what make you believe the connection is really at 100Mbps
(that terminology again, mega bits per second here), rather than 10Mbps?
Second, the wire isn't the only part of the system, so boards and drivers
count for a great deal, not to mention the motherboard and the overall
software being used to deal with network traffic.
One rather doubts you are running UnixWare on a cpu whose clock rate
is only a few MHz, less than say 5, but one never knows in this business.
Rather than vaguely pointing a finger at "the network" how about
carefully testing the protocol stack (presumably TCP/IP, but you didn't
say) with known good programs such as ftp for openers. Once those figures
are known you can then look at your app sitting on the top of the stack.
In the process using a wire monitor can be very informative.
Joe D.

Is it possible UW is trying to do Full Duplex and the switch
you're using doesn't support it right? This happened
to us (different OS) on our first try with 100Mbit ethernet.
Try forcing (if there is a way to) half duplex.

-- Doug

I have the same throughput problems with UnixWare. And I've tried all
versions between 2.0.1 and 2.1.3 (inclusive). Also, I've tried different
network cards (3COM 905, Intel EE100B, and Compaq NetFlex/3 100BaseTX),
different machines, etc. Always the same crappy throughput. FreeBSD on
the same hardware and card cruises at several megabytes a second.
Consider yourself lucky to get 800K/sec, I always get 100K/sec max on FTP
(outbound from the UW machine). What a great use of a 100 MBit
connection. If you ever do find a solution, I'd love to hear it.

--
Bob Farmer ucs_@unx1.shsu.edu
University Computer Services, Sam Houston State Univ. (409)294-3547