[comp.protocols.tcp-ip] Revision of PC/IP scorecard

HANK@TAUNIVM.BITNET (Hank Nussbacher) (07/17/89)

People have asked and I have postponed it, but I now have a couple of hours
on the horizon so here goes:

I have decided to invest 3 weeks to update the scorecard that I last
circulated a year ago.  Please do not send updates yet.  Just send me your
ideas for what needs to be added (or deleted) to the scorecard - new functions,
new Ethernet cards, etc.  I will accept comments for revision until
July 23.  On the 23rd or 24th I will come out with a new table and
will request people to then send me their updates for the scrorecard.
The new scorecard will be posted on August 3rd as revision #7.

Please send me now your comments for additions.  Please reply directly to
me since I am not subscribed to your list.

Thanks,
Hank
                         The Pc/Ip Scorecard
                        revision 6:  07/28/88
                        ---------------------

    This scorecard will  be like a  PC Magazine analysis  of of hard
disks or printers.  But  I need help in  filling in the boxes.   So,
here is what the scorecard looks like.  Please send me your  replies
and  I  will  integrate  all  answers  and  comments and publish the
finalized scorecard in the weeks to come.

    This first table is called "Must Have".

Vendor        TFTP SMTP VT-  3270 FTP  max  cost
                         100      Clnt FTP  ($)
-------------+----+----+----+----+----+----+----+----
Beame        | Yes| No | Yes| No | Yes| 75k|    |
Cornell      |  No| No | No | Yes| No |    |  25|site
CMU          | Yes| No | No | No | No |    |   0|
Excelan 3.3  | No | No | Yes| No | Yes| 88k| 250|cpu
FTP  2.02    | Yes| Yes| Yes| Yes| Yes|114k| 400|cpu
FUSION 3.2   | Yes| Yes| Yes| No | Yes| 85k| 300|
IBM  V1.1    | Yes| Yes| No | Yes| Yes| 90k| 200|cpu
KA9Q         | No | Yes| No | No | Yes| 74k|   0|
MIT          | Yes| No | No | No | No |    |  50|site
NCSA  V2.2   | No | No | Yes| No | Yes|    |   0|
Stanford 3.0 | No | Yes| Yes| No | Yes|    | 100|site
SUN PC-NFS   | No |Xtra| Yes| No | Yes|167k| 395|cpu
UB           |    | No | No | No | Yes|    | 495|cpu
WIN/TCP 3.2  | Yes| Yes| Yes| No | Yes|200k| 395|cpu

Notes: 1) All versions must support ARP, ICMP and UDP
       2) max FTP is for the fastest FTP to a PC (*not* from) in
          Kbytes/sec.  The sending machine can be any machine.
          The origin and destination of the FTP must be disk or
          ramdisk.  NUL is not a valid destination.

    The  following  table  lists  the  most  popular  Ethernet cards
available and whether the Pc/Ip implementation works with the stated
card.

Vendor      3com  Excelan  Inter   UB    WD   3Com  UB NIC  3com  MICOM
            3C501 EXOS205  NI5010 2273A 8003  3C523  PS/2   3C503 NI5210
-----------+-----+--------+------+-----+-----+-----+------+------+------+
Beame      | Yes |  No    |  No  | No  | No  | No  | No   | No   | No
Cornell    | Yes |  No    |  No  | No  | No  | No  | No   | No   | No
CMU        | Yes |  No    |  Yes | No  | Yes | No  | No   | No   | No
Excelan    | No  |  Yes   |  No  | No  | No  | No  | No   | No   | No
FTP        | Yes |  Yes   |  Yes | Yes | Yes | Yes | No   | Yes  | Yes
FUSION     | Yes |  No    |  Yes | No  | Yes | No  | No   |      | Yes
IBM        | Yes |  No    |  No  | Yes | No  | No  | Yes  | No   | No
KA9Q       | Yes |  No    |  No  | No  | No  | No  | No   |      | Yes
MIT        | Yes |  No    |  Yes | No  | No  | No  | No   |      |
NCSA       | Yes |  No    |  No  | Yes | Yes | No  | No   | No   | Yes
Stanford   | Yes |  No    |  No  | No  | Yes | Yes |      | Yes  |
Sun        | Yes |  No    |  Yes | Yes | Yes | Yes | No   | Yes  | Yes
UB         | No  |  Yes   |  No  | Yes | No  | No  | Yes  |      |
Wollongong | Yes |  No    |  Yes | No  | No  | Yes | No   | Yes  | No

    This table is  called the "Nice  to Have" table.   The functions
listed  here  are  not  mandatory   but  are  useful  in  a   Tcp/Ip
environment:

            domn time fing whoi NFS  gate srce Net- ping SLIP POP
Vendor      name srvr                way  code BIOS
            srvr                               1001
-----------+----+----+----+----+----+----+----+----+----+----+----+----+
Beame      | Yes| Yes| Yes| No | No | No | No | No | No | No | No |    |
Cornell    |  No|  No|  No| No | No | No | No | No | Yes| No | No |    |
CMU        | Yes| Yes| Yes| No | No | No | Yes| No | Yes| Yes| No |    |
Excelan    | No | No | No | No | No | No | No | Yes| No | No | No |    |
FTP        | Yes| Yes| Yes| Yes| No | No |Xtra|Xtra| Yes| Yes| No |    |
FUSION     | No | Yes| Yes| Yes| No | No | Yes| No | Yes| No | No |    |
IBM        | Yes| Yes| Yes| Yes| No | Yes| Yes| No | Yes| No | Yes|    |
KA9Q       | No | No | No | No | No | Yes| Yes| No | Yes| Yes| No |    |
MIT        | Yes| Yes| Yes| Yes| No | No | Yes| No | Yes| No | No |    |
NCSA       | Yes| No | No | No | No | Yes| Yes|    | Yes| No | No |    |
Stanford   | No | Yes| Yes| Yes| No | No | No |    | Yes| No | Yes|    |
Sun        | Yes| No | No | No | Yes| No |Xtra| No | Yes| Yes|Xtra|    |
UB         | Yes| No |    |    | No | Yes| No | Yes| Yes| No |    |    |
Wollongong | No | No | No | No | No | Yes| No | No | Yes| No | No |    |

Notes: 1) POP refers to RFC937
       2) gateway refers to IP forwarding capability

FTP Software is OEMed to BICC Data Networks, Fibronics, Proteon, cisco,
Spider Systems, MICOM-Interlan, Scope, Univation and Western Digital.

karn@jupiter.bellcore.com (07/18/89)

Some corrections to the KA9Q entries:

I have supported the FTP Software Packet Driver spec for quite some
time. This means I can handle any interface for which a packet driver
exists. In particular, drivers for the Interlan NI5010, WD8003, 3Com
3C523 and 3Com 3C503 are all available in the copylefted driver archive
coordinated by Russ Nelson (nelson@sun.soe.clarkson.edu). I'm using
the WD8003 and 3Com 3C503 myself.

Also, my NOS version (available for about the past 6 months, although it
is still being enhanced) supports domain name lookups and the finger
protocol (both client and server).

Phil

broehl@watdcsu.waterloo.edu (Bernie Roehl) (07/19/89)

In article <17218@bellcore.bellcore.com> karn@jupiter.bellcore.com () writes:
>Some corrections to the KA9Q entries:
>
>Also, my NOS version (available for about the past 6 months, although it
>is still being enhanced) supports domain name lookups and the finger
>protocol (both client and server).

We've been using Phil's package for some time now, and are very pleased with
it; it does everything we need and then some.

Unfortunately, the manual on flash.bellcore.com seems to be out of date;
in particular, the hosts file has been replaced by something called
"domain.txt", whose format doesn't seem to be defined in the manual.

Short of reading the source, is there some way to find out how to set up
this file?

-- 
	Bernie Roehl, University of Waterloo Electrical Engineering Dept
	Mail: broehl@watdcsu.UWaterloo{.edu,.csnet,.cdn}
	BangPath: {allegra,decvax,utzoo,clyde}!watmath!watdcsu!broehl
	Voice:  (519) 745-4419 [home]  (519) 885-1211 x 2607 [work]

BEAME@McMaster.CA (07/19/89)

Suggestion for more table entries:

  1)    Memory resident size

  2)    What is memory resident ? (example PCNFS from SUN has only UDP and IP,
                                   not resident TCP)


        - Carl Beame
        Beame@McMaster.CA

karn@jupiter (Phil R. Karn) (07/20/89)

>Unfortunately, the manual on flash.bellcore.com seems to be out of date;
>in particular, the hosts file has been replaced by something called
>"domain.txt", whose format doesn't seem to be defined in the manual.

As is usual with volunteer projects, the boring part of the job (the
documentation) trails the interesting part (the code) by quite a bit.
The domain.txt file is the cache of domain records maintained by
the resolver. They are in the standard domain database format, eg.,

sun.ka9q.ampr.org.	IN	A	128.96.160.1

(Note the trailing dot on the domain name.)

You need to seed domain.txt with all domain names referenced in your
autoexec.net file. However, if you have domain server(s) nearby, you can
specify it/them in one or more "domain addserver" commands. When this is
done, the responses from the server will be appended to domain.txt,
avoiding future queries to the name server for the same host.

The domain code uses linear search on this file, so it can be slow, and
I don't yet age out old entries. But the existing code has proven quite
adequate for most kinds of use. Occasionally I just edit out all but the
"bootstrap" entries in domain.txt and let them build up again. One of
these days I'll redo the domain resolver with a real database manager
(e.g., the recently released GNU dbm library).

Phil

msd@trwind.UUCP (Marc S. Dye ) (08/03/89)

Might I add the suggestion that the data regarding performance list a
Norton number for the PC processor (host-side for 'smart' implementations).
Also, a footnote indicating the configuration of the PC/IP host used and
that of the peer it was talking to.

ASCII vs. BINARY mode FTP transfer data might also be nice.  There are
some drastic performance differences between these in many implementations.

Bi-directionality is also a possible performance issue.  If you expect
anything but the best value for either direction, that should noted.

Finally, I should like to point out that there are some implementations
around which take much license with the performance statistics their FTP
client interfaces report.  The numbers should really report the total
time it takes the data to actually sink to the destination medium (usu.
RAMdisk for these sorts of tests);  data thrown over the wall to TCP
shouldn't count.  A good way to ameliorate this effect is to require a
LARGE file transfer (> a few Megs).

++msd -- msd@TRW.Com -- Marc S. Dye (ayuda Company)
1393 Stonemeadow Ct.;  Camarillo, CA;  93010;  USA;  (805)987-0433