Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!apple!sun-barr!sun!pepper!cmcmanis From: cmcmanis%pepper@Sun.COM (Chuck McManis) Newsgroups: comp.sys.amiga Subject: Re: Software-only network protocol standards Message-ID: <117428@sun.Eng.Sun.COM> Date: 24 Jul 89 21:44:06 GMT References: <1089@sas.UUCP> <1719.AA1719@geo-works> <18559@usc.edu> <1789.AA1789@geo-works> Sender: news@sun.Eng.Sun.COM Reply-To: cmcmanis@sun.UUCP (Chuck McManis) Organization: Sun Microsystems, Mountain View Lines: 96 [I've rearranged this a bit, for clarity, apologies if I changed the meaning] In article <1789.AA1789@geo-works> bryan@geo-works.UUCP (Bryan Ford) writes: > I'm >assuming that most Unix boxes run at much higher speeds, and since they >inherently *require* at least a 68020 (if memory protection is supported), >many of the instructions will also execute in less clock cycles (the 68020 >often uses less clock cycles per instruction). This is a bogus assumption. The Sun-1 was a 68000 and the Sun-2 was a 68010. The latter was running at 12Mhz I believe. But it did have memory management. >This network has to run on a "lowest-level" 8 MHz Amiga (or is that 7.xx?). >This means I must program for 125 nanoseconds per clock cycle, and no 68000 >instruction takes less than two cycles (maybe more, I can't remember). >At 200,000 baud, you have 5 milliseconds per bit and 50 milliseconds per >byte (at 8N1). That means there are approximately 400 clock cycles per >byte. This says that for any stream of bytes at 200,000 baud, we should be able stuff them from the serial port into a buffer. With some time to spare something like (my assembler for the 68K sucks, please forgive): Serial_interrupt: move.l #SERDATA,a0 move.l #bufaddr,a1 move #PACKETSIZE, d0 $10 tst.b SERFLAGS,#DATA_AVAILABLE ; guarunteed to be ~400 clocks bz.s $10 ; so busy waiting is ok. movem (a0), (a1)+ dbf $10 movem #1,packet_available rts This simple routine, is supposed to just activate when it gets the first byte, suck the packet out of the serial device into some memory somewhere, and then return. At which point some other routine will process the packet. >This may seem like a lot, but remember that, in any single host, there >at least *four* processes going at this speed: one sending and one >receiving for each of the two required ports. And if there are more >than two ports, the overhead is even greater. Since this is a >multitasking machine, I don't want to bog down the system too much >because of network handling. But sending processes can hold off for long periods of time when the receiving process is fetching data. Plus if you want to do both (send and receive) at the same time you should put them both into the same thread such they use the same cycles. The simplest way to do this is to have one tight loop check for both the Transmitter Buffer Empty flag and the Receive Buffer Full flag and branch to the appropriate mini routine until you ran out of stuff to do (send or receive) and then exit. What you will never get away from without new hardware is that the CPU has to do everything, and no matter how you code it if you get 100% network utilization your CPU won't have time to do anything else. >Only the raw transfer of raw data is handled in hardware in this case, >while (for example) most Ethernet cards often handle things like error >checking and resending bad packets. In addition, with an Ethernet network, >packets go straight to the destination host without needing to be processed >and rerouted by other hosts. In a mesh network, many hosts will have lots >of data going through them, so there will be more traffic through each >host. This makes for some interesting real time code. When you use the same threads/buffer approach that I mentioned, you can use a trick whereby if the packet you are receiving isn't for you, you can just dump it into the transmit buffer. By doing so the transmit part of the thread will begin sending it back out immediately. >Now, one question: How many overhead cycles do the Amiga's interrupt >routines use (on a plain 68000)? I know it's not much, but I'd like to >know exactly *how* much. How about for software interrupts? Get Carl Sassenrath's book on Interrupts. (Guru's Guide #1). It's available from HT Electronics in Sunnyvale for sure. (Or direct from Carl). One project I worked on long ago realized that once the processor had responded they wouldn't have any trouble receieving the packet but latency was a problem. The solution they chose was to send a couple of 0xFF bytes first, which would start the interrupt proccessing part of the receiver who would always get an overrun error because it couldn't receive the first byte fast enough, but that was ok, it would clear the serial chip and wait for the 0xAA which signaled the start of the packet. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you. "A most excellent barbarian ... Genghis Kahn!"