Xref: utzoo unix-pc.general:2687 comp.sys.att:6123 Path: utzoo!attcan!uunet!cos!hqda-ai!icus!limbic!gil From: gil@limbic.UUCP (Gil Kloepfer Jr.) Newsgroups: unix-pc.general,comp.sys.att Subject: Re: TCP for the unix-pc Summary: Some more ideas... Keywords: 3b1 7300 TCP SLIP Appletalk network Message-ID: <479@limbic.UUCP> Date: 15 Apr 89 07:31:40 GMT References: <1892@umbc3.UMBC.EDU> <1909@umbc3.UMBC.EDU> Reply-To: gil@limbic.UUCP (Gil Kloepfer Jr.) Organization: ICUS Software Systems, Islip, NY Lines: 52 In article <1909@umbc3.UMBC.EDU> mark@umbc3.umbc.edu.UMBC.EDU (Mark Sienkiewicz) writes: >4. My favorite idea would be to have a bi-directional parallel interface >that talks the the machine on the next table. Then one of them would >gateway things onto a serial bus network. I think with the right >hardware, you could push it to around 100k bps without too many problems. I'm currently working on this idea. Mike Thompson is working on a SCSI port, which essentially is the same thing (but better). Some observations on the overall tone of the quoted article: First, it is unwise to make a bidirectional parallel interface that is entirely interrupt-driven. I already tried this and it *does* swamp the CPU with interrupts. You'll end up with spirious interrupts because there will be an interrupt coming-in as you're in the process of returning from the interrupt service routine. This isn't good. Second, using a buffered UART to perform I/O is not worth the effort if all you're doing is adding a 16 byte buffer. To gain more throughput and keep the CPU from being overwhelmed, a packet-based protocol should be used with the packets transferred to/from off-board RAM (say, 2K or so) using the 256K address space allocated to an expansion slot (see next paragraph). Off-board, some kind of intelligent controller should be used to transfer the data packet in this RAM off through the UART (or parallel interface chip, such as the 8251). This takes the load off the 3B1's CPU and provides greater (and more reliable) throughput. You could use DMA to the 3B1, but this could hold the bus for an unreasonable period of time. Third, it is not my recommendation to wire anything to the bus through chips on the motherboard -- stick to expansion slots. Like you, I didn't have the right connector so I wired straight to the slot connector. There are signals coming out of the expansion slot, as well as the proper addressing schemes, which should be adhered to so that all peripherals may peacefully coexist. If this doesn't sound good enough for you, let it be known that I/O timing and other CPU timing is different on the 3B1. Unless you have circuitry that can operate at the full processor speed even with the kludgy wiring off a chip, you will experience definite problems with prop. delay. My true feeling is to wait a few months for Mike and the crew to come up with a public-domain SCSI port. Since schematics and software will be all available, you can make with this what you want. If all you want is a serial network, then you'll probably get the best throughput with the on-board serial port and a special driver. I have a feeling though that this SCSI idea will be real good for something, even if the software isn't quite right. ----- | Gil Kloepfer, Jr. | ICUS Software Systems/Bowne Management Systems (depending on where I am) | {decuac,boulder,talcott,sbcs}!icus!limbic!gil or gil@icus.islp.ny.us