<From: "Steven M. Schultz" <sms(a)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@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
>From Greg Lehey <grog(a)lemis.com> Sun Feb 1 12:45:58 1998
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 <pups(a)minnie.cs.adfa.oz.au>; 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: <19980201131558.50751(a)lemis.com>
Date: Sun, 1 Feb 1998 13:15:58 +1030
From: Greg Lehey <grog(a)lemis.com>
To: Allison J Parent <allisonp(a)world.std.com>
Cc: pups(a)minnie.cs.adfa.oz.au
Subject: Re: Installing PDP-11 UNIX w. no tape - solution
References: <199801311818.AA26294(a)world.std.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.84e
In-Reply-To: <199801311818.AA26294(a)world.std.com>; 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:
>> From: "Steven M. Schultz" <sms(a)moe.2bsd.com>
>
>> 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.
Sure. UNIX drivers have never been particularly optimized for high
async interrupt performance.
>> 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
The 16540 has only one byte buffer.
> and the 550 it's either 16 or 32 bytes.
The 16550 has 4 bytes, and the 16650 has (I think) 16 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.
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.
>
>> 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.
Have you modified the kernel? Normally disks will preempt ttys.
> Its byte timing. the bits are handled at the uart. But your right
> my systems are lightly loaded and generally run RT11FB or XM.
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
<I get some error messages with restor (``Missing address (header) block''
<which I believe are to do with the 10,240 byte record requests from resto
<My code expects 512-byte requests, and I'm doing 20 a time to fulfill th
<10,240 request, but still problems.
Try slowing down. You may be overflowing the input buffer. This was
a common problem on TU58s hooked to the 2nd DL on some systems at speeds
above either 4800 or 9600. It only happend in the TU58 to host direction
(read) as the opposite path expected a handshake every 128 bytes(to allow
the tu58 to actually do the write to tape). It seems the tu58 would send
a 512byte block as 4 128byte packets at a sustained rate fast enough to
overrun the PDP-11 host input buffer; before it could be emptied. You
may be emulating a similar problem. PCs do not service interrupts all
that fast and OS overhead can make that longer.
Note PDP-11s can have enough overhead and higher priority stuff ahead of
the 2nd DL that it cannot take data at greater than 4800 baud (sustained
rate) without some kind of handshake to allow processing in between.
If the system is basically unloaded like my minimal 11/23 it can run at
38.4! The most likely time when this overrun can happen is while doing
processing to write (via file system) to disk and recieving data at the
same time.
Allison
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.5/8.8.5) id JAA21620
for pups-liszt; Sat, 31 Jan 1998 09:06:40 +1100 (EST)
X-Authentication-Warning: minnie.cs.adfa.oz.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From Warren Toomey <wkt(a)henry.cs.adfa.oz.au> Sat Jan 31 08:06:42 1998
Received: from henry.cs.adfa.oz.au (henry.cs.adfa.oz.au [131.236.21.158])
by minnie.cs.adfa.oz.au (8.8.5/8.8.5) with ESMTP id JAA21615
for <pups(a)minnie.cs.adfa.oz.au>; Sat, 31 Jan 1998 09:06:37 +1100 (EST)
Received: (from wkt@localhost) by henry.cs.adfa.oz.au (8.7.5/8.7.3) id JAA07375; Sat, 31 Jan 1998 09:06:43 +1100 (EST)
From: Warren Toomey <wkt(a)henry.cs.adfa.oz.au>
Message-Id: <199801302206.JAA07375(a)henry.cs.adfa.oz.au>
Subject: Re: Installing PDP-11 UNIX w. no tape - solution
To: allisonp(a)world.std.com (Allison J Parent)
Date: Sat, 31 Jan 1998 09:06:42 +1100 (EST)
Cc: pups(a)minnie.cs.adfa.oz.au
In-Reply-To: <199801301446.AA19117(a)world.std.com> from Allison J Parent at "Jan 30, 98 09:46:31 am"
Reply-To: wkt(a)cs.adfa.oz.au
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
In article by Allison J Parent:
>
> <I get some error messages with restor (``Missing address (header) block''
> <which I believe are to do with the 10,240 byte record requests from resto
> <My code expects 512-byte requests, and I'm doing 20 a time to fulfill th
> <10,240 request, but still problems.
>
> Try slowing down. You may be overflowing the input buffer.
I found the problem - my dump image was corrupt :-). I now have a clean
v7 dump of /, and there are no complaints from restor.
I've had a few people volunteer to try out the code. I'll clean it up,
finish off the docs, and put it up for ftp in a few days, with an email
on the PUPS mailing list on how to retrieve it.
Cheers,
Warren
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.5/8.8.5) id QAA22547
for pups-liszt; Sat, 31 Jan 1998 16:52:16 +1100 (EST)
X-Authentication-Warning: minnie.cs.adfa.oz.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
>From "Steven M. Schultz" <sms(a)moe.2bsd.com> Sat Jan 31 15:36:05 1998
Received: from moe.2bsd.com (0(a)MOE.2BSD.COM [206.139.202.200])
by minnie.cs.adfa.oz.au (8.8.5/8.8.5) with ESMTP id QAA22542
for <pups(a)minnie.cs.adfa.oz.au>; Sat, 31 Jan 1998 16:52:10 +1100 (EST)
Received: (from sms@localhost)
by moe.2bsd.com (8.8.5/8.8.5) id VAA23209
for pups(a)minnie.cs.adfa.oz.au; Fri, 30 Jan 1998 21:36:05 -0800 (PST)
Date: Fri, 30 Jan 1998 21:36:05 -0800 (PST)
From: "Steven M. Schultz" <sms(a)moe.2bsd.com>
Message-Id: <199801310536.VAA23209(a)moe.2bsd.com>
To: pups(a)minnie.cs.adfa.oz.au
Subject: Re: Installing PDP-11 UNIX w. no tape - solution
Sender: owner-pups(a)minnie.cs.adfa.oz.au
Precedence: bulk
Hi -
I thought I'd chime in with my experience with "high" speed serial
transfers...
> From: allisonp(a)world.std.com (Allison J Parent)
>
> Try slowing down. You may be overflowing the input buffer. This was
> a common problem on TU58s hooked to the 2nd DL on some systems at speeds
> above either 4800 or 9600. It only happend in the TU58 to host direction
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
to be used while the system was up and doing other stuff the TU58 was
quite poor.
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.
> (read) as the opposite path expected a handshake every 128 bytes(to allow
> the tu58 to actually do the write to tape). It seems the tu58 would send
> a 512byte block as 4 128byte packets at a sustained rate fast enough to
> overrun the PDP-11 host input buffer; before it could be emptied. You
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.
> may be emulating a similar problem. PCs do not service interrupts all
> that fast and OS overhead can make that longer.
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.
> Note PDP-11s can have enough overhead and higher priority stuff ahead of
> the 2nd DL that it cannot take data at greater than 4800 baud (sustained
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.
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.
> rate) without some kind of handshake to allow processing in between.
> If the system is basically unloaded like my minimal 11/23 it can run at
> 38.4! The most likely time when this overrun can happen is while doing
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
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.
Steven Schultz
Received: (from major@localhost)
by minnie.cs.adfa.oz.au (8.8.5/8.8.5) id FAA24275
for pups-liszt; Sun, 1 Feb 1998 05:19:03 +1100 (EST)
X-Authentication-Warning: minnie.cs.adfa.oz.au: major set sender to owner-pups(a)minnie.cs.adfa.oz.au using -f
