🚀 go-pugleaf

In article <2p3db5$944@mojo.eng.umd.edu> mfinn@eng.umd.edu (Michael J. Finn) writes:
>
>Postscript may be printed on the Xerox 4050F (and 9000F, 4135, DTech as 
>well) printers with software from Entire (Entire Fibre 400) which is 
>written for Unix (SunOS) converts the Postscript page to a *.IMG file, 
>adds the Interpress info and sends it to the controller, and is 
>subsequently processed by the graphics handling subsystem (GHO or its 
>successor - GVG) for output to the printer. Graphics handling is the 
>only option required, unless network access is used, where the 
>appropriate interface would be required. 

  We have a Xerox 4850 and are using the Entire software. We've had the
printer only a few months and are still adjusting to running it, but
we've run into some problems with large (2,600+ pages) PostScript jobs.

  First, it's slow. Each page is converted to an Interpress *.IMG and
transferred over the network. The file must be completely received
before printing will start. After the file is received, it is apparently
re-copied on the printer's disks, from a receiving area to a printing area.
Printing will begin as soon as the output buffer is full. However, we often
see the printer print faster than the file will re-copy. Typically, we see
the printer print a couple hundred pages, stop, re-fill the output buffer and
print a couple hundred pages, etc, etc, etc. Hardly the rated 50 ppm.
  The transfer step is the slowest portion of the process, although we're
able to print files from out mainframe's tag-and-bus connection while
the transfer runs over the network. For our 2,600 page file, the best
we've seen is about 5 hours, while the worst is 10+ More on this later.

  The second problem w/ our 2,600 PostScript job is that we sometimes
fill up the printer's disk, and when this occurs, no message is
received on the printer's console, the job just appears to be "stuck"
on a page on the Unix queue monitor.

  The third problem is that abort PostScript jobs don't clean up after
themselves, they leave all the *.IMG files on the disk, making it more likely
that the disk will fill up. We have to remember to clean up the disk
regularly.

  Back to the transfer... The queue monitor on our Unix host shows us the
number of pages converted to Interpress format, and the number transferred
to the printer. We invariably see the conversion run ahead of the transfer
until it fills up its buffer, getting 228 pages ahead, then a page will
convert every time a page transfers. On the printer side, we've been told
that each page image requires a contiguous chunk of disk space, and it
seems that the printer's file system is relatively simplistic, since it
appears that it must chain down a list of free spaces until it finds
one large enough for the page image. We've found that we can acheive a 
dramatic increase in performance by compressing the disks prior to running
a large PostScript job, cutting the time in half or better, trimming a
10+ hour process down to 5.

  These disk-related issues weren't explained to us when the printer
was installed, and we've stumbled upon them via trial and error. If
anyone knows of other things to get better performance out of our
PostScript jobs, please post.

Stu Derby
Baylor College of Medicine
Systems Support Center
-- 
------------------------------------------------------------------------
Stu Derby          | 
sderby@bcm.tmc.edu |      This space intentionally left blank.
Houston, Texas     |