wcs@ho95e.ATT.COM (Bill.Stewart) (03/03/88)
I want to display graphics rapidly on a 386-based PC, with data originating on a "lab computer". Ideally, I'd like to transfer around 1 megabyte/second; I realize this is unreasonable. But how fast can I get? Some options available include Ethernets and IEEE-488. (I plan to have adequate amounts of memory, since disk is slow.) How fast can TCP/IP go? Would UDP help any? When does a PC/AT bus run out of gas? Would the evil Microchannel Backplane help? How fast can IEEE-488 go? -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
jbvb@VAX.FTP.COM (James Van Bokkelen) (03/04/88)
On an 8Mhz AT, with Ethernet, we can get 1.5 megabits/sec out of our TCP quite predictably (of course, this requires a fast interface and adaptive retransmits on the sending end). Faster processors increase our TCP speed, because most of the computes are used up copying packets and checksumming them. UDP would go faster (provided you disable the data checksum, which is not normally an option with our UDP), but you'd have to write your own protocol to guarantee reliable delivery & retransmission, which might burn up all the speed you gain. I have heard it said that the Microchannel is somewhat faster with at least two interfaces I've heard about, but on the order of 10%, nothing spectacular. I don't know if the cards in question had byte-wide memory on the bus, or word-wide. James VanBokkelen FTP Software Inc.
ROMKEY@XX.LCS.MIT.EDU (John Romkey) (03/04/88)
For fast transfers, the most important factors on PC's are the ethernet interface, the processor speed and the disk speed, in order of importance. Actually, the last two can be juggled around a lot; there's a wide variety of processors (from 4.77MHz 8088's to 20MHz 386's) and disks (XT 8 bit hard disk controller with 80ms disk to 1:1 interleave 16bit AT or 386 controller) out there. So maybe the last two are of equal importance. Anyway, if you don't want to write the data out to disk, then whatever you're doing to dispose of it had better be able to fit into the amount of CPU time and I/O bandwidth needed to achieve 1MB/sec if that's what you want. You said lots of memory, so let's suppose the data just gets stuck in memory and you'll do something with it when the transfer is over. You probably want to use TCP instead of UDP. TCP has a reputation for being slow with lots of overhead. I used to believe this myself, a long time ago, and it is true in a poorly constructed TCP. But it's not necessarily true of all TCP's. In order to get good performance, you need to have several packets in transit at once and acknowledge them several at a time. You can use an existing (hopefully well-written) TCP which will do all this stuff for you, or you can build something on top of UDP which will duplicate a lot of what a real TCP does. I'll go for using a good TCP instead. I've seen a real TCP transfer data at 1.6Mbits/sec between two 8MHz AT's, memory to memory. No filesystem involved. This was with the best ethernet interfaces on the market right now. I believe that if you increased the speed of the AT's (putting a 386 in them would be nice) that the throughput would still go up some - we haven't totally used up the AT bus yet. I think. Yes, the dreaded Microchannel should improve things too, but this is in theory and I've never seen any timings done on a PS/2 with a Microchannel ethernet card. The Microchannel seems to be a faster bus, and network interfaces on it should do 16 bit transfers instead of 8 bit, so things should run faster. - john -------
backman@interlan.UUCP (Larry Backman) (03/07/88)
In article <12379455706.53.ROMKEY@XX.LCS.MIT.EDU> ROMKEY@XX.LCS.MIT.EDU (John Romkey) writes: >and I've never seen any timings done on a PS/2 with a Microchannel ethernet >card. The Microchannel seems to be a faster bus, and network interfaces on it >should do 16 bit transfers instead of 8 bit, so things should run faster. [] Same board, different bus.. NI5210 running a Novell performance test -- 170K bytes NI9210 running same test on MChannel -- 240K bytes draw your own conclusions.... larry backman