<From: "Steven M. Schultz" &lt;sms(a)moe.2bsd.com&gt; <The TU58's lack of flow control (unless you were on the Vax-750 with <something I believed was called the MRSP roms) made them all but <useless except in a 'standalone' environment. As a boot device they <were just "slower than molasses in January". As a data storage device The tu58 also knows MRSP but the host still has to buffer a 128(plus wrapper) packet in one blast. It's assumption is that the host has plenty of ram and a suitable buffer should be no problem at most data rates. Call it a design error. It's also something that has to be dealt with in all cases of serial communication. As boot device, I used to take the average 750 console tape and rearrange it and on average cut the load time by 60% or more. Seeks are slow being 30 seconds end to end. The fewer the better also the ordder of files can make a difference. I use it to boot a PDT11/130 and also an 11/23 in a BA11va (four slot box). and it's accept able IF the files are in the best order for access. <I tried to use the TU58 on an 11/44 once and it just wouldn't work <reliably when trying to transfer a file from TU58 to disk. The first <time the system had to tape a couple milliseconds to write a block to <disk you had a DL11 overrun and the transfer was corrupt. I have some data and the problem was on the 11/44 console side. It could not keep up with the 9600 baud data from the tu58. <The DL-11 to which the TU58 was attached (could it be hooked up to <something a bit better? I would think so but don't know for sure) <had no buffering/silo - at 9600 there was only 1 millisecond to get <the character and that's cutting things a bit too fine on a ~.5 mips <machine, especially if other things are going on at the same time. I've run z80s/4mhz at 19.2k with no errors it's was the structure of the driver and a total level of hardware buffering of one byte. <Ummm, 'PC's I'm used to don't seem terribly upset at 10 or 20 thousand <interrupts per second - that should be sufficient to handle any 9600 <baud serial line I'd think. they can only because the '450 has a silo of 4 bytes and the 550 it's either 16 or 32 bytes. That's a whole lot of time before you must service it and then there is the matter of a few dozen mips of cpu behind it. <Not 'overhead' as much as just 'slowness'. An 11/44 is about .6 mips <(an 11/73 is about 15% less) - that's quite a bit less than even a <286. No comparison. My 11/23 runs just fine with the TU58 running at 38.4k. the difference is the 11/23 is not using a console processor inbetween. In that case the DLV11j is the higest priority in the bus. My 11/73 also uses the TU58 at 38.4 but the disks (RX02, RQDX3, RL02) are all lower priority. Again there is no problem unless the system is real busy and then the tu58 will do rereads for blocks that were not ack'd. You don't need a lot of mips to recieve data at 9600 and put it in a buffer for later use. Coding a routine to do it reliably is sometimes not as easy as it may look. Also coding in HLL (even C) can add overhead not anticipated and slows execution. the problem in most PDP-11s is the serial buffer in ram is rarely 140 bytes (data plus wrapper) so that 1mS you have then includes the whole file system and that takes a lot of mips to keep up with. <The biggest problem I ran into was the fact that the disk systems <all used SPL-5 while the serial ports (DL11,etc) were at 4. A disk <interrupt would (and did) come in and would delay things just enough <that the DL running at 9600 with no flow control would overrun. That would do it. Try using a DH or DZ interface as they have a silo and can sustain higher rates. <If it's not doing too much else. I don't see an 11/xx handling high <serial line rates without some form of RTS/CTS flowcontrol while a <kernel recompile is going on ;-) If you're using a DHV-11 the <data flow rate is quite a bit less than 38.4k - the bit timings are Its byte timing. the bits are handled at the uart. But your right my systems are lightly loaded and generally run RT11FB or XM. <that fast but the board can't handle it and the effective rate is <lower. A DHQ-11 is quite a bit better but all in all anything over <9600 requires hardware flow control, especially if the data has to <make its way to disk. The serial TU58 however does not have hardware flow control though it can be hacked on to the board. (hint inhibit the TX empty interrupt to the 8085.) FYI the PDT11/130 got around this by using a parallel interface tu58. The parallel interfaced tu58 cannot send a byte until the receiving system take the last one. At one time to prove a point I did do a hacked up tu58 with hardware flow control and a matching DLV card and ran it at 38.4, the performance was impressive even under heavy RSX11 loading. DEC did not do this as it would be a major redesign/requal of the product. They did know the problem well however. The key is look at interupt latency. PDP-11s are OK but when you add something like burst mode DMA where the CPU can be off the buss effectively for significant periods of time there can be performance hits. Allison Received: (from major@localhost) by minnie.cs.adfa.oz.au (8.8.5/8.8.5) id NAA25353 for pups-liszt; Sun, 1 Feb 1998 13:46:09 +1100 (EST) X-Authentication-Warning: minnie.cs.adfa.oz.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by minnie.cs.adfa.oz.au (8.8.5/8.8.5) with ESMTP id NAA25348 for &lt;pups(a)minnie.cs.adfa.oz.au&gt;; Sun, 1 Feb 1998 13:46:02 +1100 (EST) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.8.7/8.8.5) with ESMTP id NAA29575; Sun, 1 Feb 1998 13:15:59 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.8.8/8.8.7) id NAA08065; Sun, 1 Feb 1998 13:15:58 +1030 (CST) (envelope-from grog) Message-ID: &lt;19980201131558.50751(a)lemis.com&gt; Date: Sun, 1 Feb 1998 13:15:58 +1030 From: Greg Lehey &lt;grog(a)lemis.com&gt; To: Allison J Parent &lt;allisonp(a)world.std.com&gt; Cc: pups(a)minnie.cs.adfa.oz.au Subject: Re: Installing PDP-11 UNIX w. no tape - solution References: &lt;199801311818.AA26294(a)world.std.com&gt; Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.84e In-Reply-To: &lt;199801311818.AA26294(a)world.std.com&gt;; from Allison J Parent on Sat, Jan 31, 1998 at 01:18:24PM -0500 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 WWW-Home-Page: http://www.lemis.com/~grog Sender: owner-pups(a)minnie.cs.adfa.oz.au Precedence: bulk On Sat, Jan 31, 1998 at 01:18:24PM -0500, Allison J Parent wrote: Sure. UNIX drivers have never been particularly optimized for high async interrupt performance. The 16540 has only one byte buffer. The 16550 has 4 bytes, and the 16650 has (I think) 16 bytes. That's more to the point. Don't forget that a high-end Pentium is probably 1000 times the speed of an 11/20. I regularly get 50-60k interrupts per second when downloading fonts to my PostScript printer, and I think the printer is the limiting factor there. Have you modified the kernel? Normally disks will preempt ttys. Ah. Greg Received: (from major@localhost) by minnie.cs.adfa.oz.au (8.8.5/8.8.5) id PAA25590 for pups-liszt; Sun, 1 Feb 1998 15:21:11 +1100 (EST) X-Authentication-Warning: minnie.cs.adfa.oz.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f