Installing PDP-11 UNIX w. no tape - solution

[Allison J Parent]

<From: "Steven M. Schultz" <sms at moe.2bsd.com>

<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 at 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 at minnie.cs.adfa.oz.au using -f