info-vax@ucbvax.ARPA (10/05/84)
From: engvax!KVC@cit-vax Richard, you were close... It's Carosso... In any case, I better explain those speeds before people jump onto them and take them as gospel. First of all, the measurements quoted (280 Kb DECnet and 140 Kb TCP) are for the DEC DEUNA on 10 Mbit/s Ethernet between a 780 and a 750. There were several other 750's on the net as well, but I do not think they were doing anything. The numbers are for a file transfer of a fairly large file (SYS$LIBRARY:STARLET.PAS for you Pascal buffs...). In both cases, I tried to eliminate start-up times for creating network processes. In the DECnet case I did a DIRECTORY of the remote system first to create a NETSERVER. In the TCP case, I was running TCP and used it's STAT function to return the speed. It didn't start the clock till the transfer was ready to begin (thus the time does not include whatever it took to start up a TCP server on the other side). I have seen the TCP speed for a file transfer wander over all sorts of values. On to unloaded 780's, I recall seeing something over 200Kb once or twice. From a VMS system to a UNIX system, I think it usually stays above 200 Kb (if the systems aren't loaded). Now, you can do a lot better if you measure task-to-task. For TCP/IP, you can run the SINK program (sends data to the other side, where the data is thrown away) at up to 400 Kb. FTP seems to be awfully slow compared to the speed of the SINK server. I have not been able to measure two UNIX systems, so I do not know how they rate. They certainly keep up with the Tektronix stuff though (not surprising, they do a lot of work in the kernel to optimize the net stuff I have heard) but I do not know for certain what the limiting factor was in my VMS-UNIX tests. I'd like to make one disclaimer on the above information. None of these numbers are from any sort of formal benchmark. All were generated by me to satisfy a little curiosity. Since I have the resources available, I will run a more stringent benchmark of anyone would be interested in the results. By the way, the VMS-UNIX runs were over an Interlan controller. Here's a little information on DECnet performance that you might find interesting. This comes from Appendix A of the "Networks and Communications Catalog" for Summer 1984 from DEC. This is a great book, get one from your sales rep if you do not have one... Anyway, they talk about DECnet performance over the Ether and publish some figures. Task-to-task DECnet-VAX V3.1 with link-optimization* ------------ --------------- ---------------------- 780 800 Kb 1300 Kb 750 600 Kb 1200 Kb File Transfer ------------- 780 420 Kb 500 Kb 750 350 Kb 390 Kb 730 225 Kb * Logical link optimization is a new feature of DECnet that allows two adjacent VMS nodes to negotiate a buffer size larger than the DECnet standard 576 bytes. As you can see, it makes a hell of a difference on task-to-task. I think the reason it makes only a little difference on File Transfer is because the system has so much other work to do. Task-to-task here was for two tasks doing no work to generate or process the information to be sent or received. If these figures are reasonable (they are from DEC after all...) then it seems that TCP/IP is a LOT slower than DECnet. I would be very interested seeing UNIX TCP/IP benchmarks to get an idea of how well TCP can run when it's built in to the kernel (presumably giving it the same advantages DECnet enjoys being an integral part of VMS).\ In any case, we are happy for the moment with our TCP/IP. It certainly runs fast enough to get the job done in a reasonable manner. It works well within VMS (is a nice clean VMS-type ACP) and I have all the source code... I also have some ideas that may speed it up significantly. For example, it does $QIOW calls to pass packets on to the device driver for the DEUNA or the Interlan controller. I am going to change these to $QIO calls and doa $WAIT just before doing the next call. That should allow the ACP to overlap some processing with the device driver's processing. Only problem we have with the Tek TCP is that it needs a guru to support it. If such a person is available, then the price is certainly right... /Kevin Carosso engvax!kvc @ CIT-VAX.ARPA Hughes Aircraft Co.
boylan@dicomed.UUCP (Chris Boylan) (10/07/84)
Unless my calculator (dc) is broken, at least one of the numbers
quoted for DECNET throughput on ethernet (task to task) is greater
than the theoretical maximum throughput of ethernet.
This is interesting to say the least.
It's important to remember that node-node measurements of ethernet
throughput are almost always half-duplex and do not take into
consideration collisions which is critical to determining "real"
throughput.
This is obviously true for all CSMA/CD networks.
--
Chris Boylan
{mgnetp | ihnp4 | uwvax}!dicomed!boylaninfo-vax@ucbvax.ARPA (10/15/84)
From: Lee Moore <lee@rochester.arpa>
I don't have any figures on the speeds on the TWG or Berkeley TCP/IP
but I do have the following quote from the last Usenix conference.
The paper is called "4bsd Unix TCP/IP and VMS DECNET: Experience in
Negotiating a Peaceful Coexistance" (p323-5) by Van Jacobson et al
of Lawrence Berkeley Labs. They are working with an early version
of SRI TCP/IP (now a product of TWG).
"We are still in the process of system performance investigation
but have some preliminary results. It probably comes as no
surprise (at least, to a Unix audience) that we find 4bsd TCP/IP
has substantially better performance than VMS DECNET. In our
tests to date, the Unix throughput has been higher and CPU
utilization lower than VMS. The Eunice TCP/IP performance is
not as good as the Unix performance, probably owing to the
high `cost' of a VMS QIO. (...) We were suprised to find that,
in most cases, the Eunice TCP/IP outperforms VMS DECNET in
both throughput and CPU utilization."
Please, no flames to me!
=lee
Internet: lee@rochester.arpa
UUCP: {decvax, allegra, seismo}!rochester!lee
'phone: [USA] (716) 275-7747, -5671
Physical: 43 01' 40'' N, 77 37' 49'' W