Trouble with a DR11-C driving a typesetter under 4.2bsd

[whm at bocklin.UUCP]

We're having some device-driver-related problems with an AM 4510 typesetter
that we've got connected to our 780 running 4.2 and I was wondering if some
of you might be able to offer some advice.

We have a DR11-C board in our VAX that is connected to a home-built piece
of hardware that runs into an 8-bit parallel port on the typesetter.  This
parallel port is actually meant for a paper-tape reader and thus, the
typesetter thinks that it is reading a paper tape while it is actually
being fed bytes from the VAX.

The typesetter is basically a very slow device; it reads a sequence of bytes
and then sets the information, reads another sequence, etc.  An average
page of text usually takes a couple of minutes to set.  We don't seem to
have any hard data on how fast it reads characters, but an observational
estimate of less than 150 bytes/second is probably safe.  Now for the
interesting part: when the typesetter wants a character but one isn't
available on the parallel port, i.e., the VAX hasn't sent another one yet,
it just re-uses the last character.  Locally, this phenomenon has been termed
"stalling" and as a sample: "This is a liine set by the typesettter when
it is stalliing.". 

The frequency of stalling seems to be related to the load on the system
in various ways, but there is not a strong correlation.  We have also
noticed that programs with a large virtual address space, Macsyma to
name a specific example, seem to be troublesome.  Usually, stalls are
only a character or two long.  When the system is mostly idle, the
frequency of stalls is usually no more than one for every three to four
pages of text.

The device driver is very simple.  Basically, the driver's write routine
gets bytes from the user's write call with uwritec, puts them on a clist,
and the interrupt routine gets bytes from the clist and it just stuffs
them into the output register of the DR11.

The typesetter was originally on a V7 11/70 and I am told that there
were never any stalls unless the system itself locked up for some
reason.  We've had this problem on both 4.1 and 4.2 on a 780.  We've
experimented with writing the entire text to be typeset in a single
write call and we still get stalls, so it doesn't appear to be a matter
of the user program not getting enough cycles.

The real question in my mind is whether or not it's reasonable to expect
the kernel to be able to always keep up with the maximum throughput rate
of approximately 150 bytes(writes)/second.  If this in fact provides
ample time for the kernel, then what could explain the stalls?  Since
the presence of processes with large virtual address spaces seem to
precipitate stalls, could the problem be that the process writing to the
typesetter is being paged/swapped out and that the system isn't able to
get the required pages back into memory fast enough?

I should mention that upon reception of its EOL character, 0x02, the
typesetter will pause without a stall until transmission resumes.

Several potential solutions to the problem have been formulated.

	Supposing that the problem is related to paging, it seems that
	 if we put a buffer in the driver and buffered up text until an
	 EOL and then started writing, that would provide immunity from
	 paging-related problems.
	
	Supposing that the problem is that the kernel just can't keep
	 up at all times, a simple hardware device which would buffer
	 up a supply of characters seems to be a sure-fire solution.
	 
	Another solution would seem to be to get a serial to parallel
	 converter and run a DH or DMF line to the converter which would
	 in turn plug into the typesetter.  I might have this figured
	 wrong, but since the DH and DMF use DMA output, if we write
	 to the typesetter in whole lines (i.e. up to an EOL), it would
	 seem that once the operation starts, nothing short of a system
	 crash can delay the write.  This would also appear to provide
	 immunity from console printfs.

Any advice or comments of any sort that you could offer about this
will be *greatly* appreciated.

					Thanks in advance,
					Bill Mitchell
					whm%arizona at csnet-relay
					{ihnp4,noao,mcnc,utah-cs}!arizona!whm