moore@PULSAR.FAC.CS.CMU.EDU (Dale Moore) (09/21/88)
Here are some of my thoughts about onboard vs outboard PostScript. Outboard is the way most all PostScript printers work today. The processing is done out on the peripheral rather than in on the general purpose processor. Some folks concern is that the extra bandwidth necessary to ship the image to the printer will be a bottleneck. Ethernet and other mediums operate at 10mps. With a large number of vendors building hardware for such networks, it is entirely feasible to build inexpensive Ethernet (rather than serial line or Appletalk) printer. Several folks have already done so. At an effective usage of 20% of the network bandwith, 300 dots per inch, 1 bit per dot, that comes down to less than 5 seconds per page. With the advent of FDDI and other networking technology, the time necessary to ship that many bits over a standard cable will decrease. Many of todays PostScript printers have more memory and faster CPU inside the printer than the general purpose machine that is generating the PostScript and sending it to the printer. The analogy is that the slave peripheral has more potential power than the master. That is something that seems entirely backward to me. Much of the time, a PostScipt printer (and its CPU and memory) are sitting idle. If the CPU and memory were available to the user to perform other computing tasks when the printer was not in use, this would result in a more effective use of the hardware. Multi-Processors with multi-processing systems are commercially available. Sequent, Balance and Next are systems that produce (or will shortly) commercial multi-processor systems. The hardware that is typically devoted to the task of changing page description languages into bitmaps could instead be part of a multi-processor operating system. Upon demand a single processor could be devoted to doing its traditional task of turning a page desciption language into bitmaps, and shipping those bitmaps to the printer. But when the printer was not needed for that task the processor could be devoted to performing other tasks as a normal part in the multi-processor system. The time necessary to ship images to a printer will only decrease as networking technology develops. More effective use can be made of the hardware if the hardware is part of a general purpose system, rather than devoted to supporting a complex function inside a peripheral. Dale Moore Computer Science Carnegie Mellon University
ron@topaz.rutgers.edu (Ron Natalie) (09/22/88)
Of course one thing that off printer processing does is allow you to do computation without tying up the engine. A majority of our runs are text, listings, copies of net news articles (:-). When a big postscript graphics job comes in the engine sits idle while the CPU intensive stuff ties up the 68000. Kind of limits throughput. However, a smart printer ought to be albe to do this on board as well with some sort of mutitasking or multiprocessing as well. -Ron
aad@stpstn.UUCP (Anthony A. Datri) (09/24/88)
In article <3068@pt.cs.cmu.edu> moore@PULSAR.FAC.CS.CMU.EDU (Dale Moore) writes: >Some folks concern is that the extra bandwidth necessary to ship the >image to the printer will be a bottleneck. Ethernet and other mediums >operate at 10mps. With a large number of vendors building hardware for >such networks, it is entirely feasible to build inexpensive Ethernet >(rather than serial line or Appletalk) printer. An ethernet (tcp/ip -- get that lps40 out of my sight) printer is certainly fine, and eliminates the transfer bottleneck, but then you need to have the printer running software to deal with that. From what I see with our Imagen, that's basically an operating system. Is this necessarily true? I can't say. >Many of todays PostScript printers have more memory and faster CPU >inside the printer than the general purpose machine that is generating >the PostScript and sending it to the printer. The analogy is that >the slave peripheral has more potential power than the master. >That is something that seems entirely backward to me. That's if you've got a laserwriter hooked to a PC. If I hook one to our Sun 3/280, that doesn't really hold. But of course, the laserwriter was probably targetted towards the existing macintosh market, where the host and printer cpu's would be about equal. In this case, putting the computational load on the cpu wouldn't cut it at all. >Multi-Processors with multi-processing systems are commercially >available. Sequent, Balance and Next are systems that produce >(or will shortly) commercial multi-processor systems. >The hardware that is typically devoted to the task of changing >page description languages into bitmaps could instead be part >of a multi-processor operating system. You have the problem here that you're always going to have more than one make of printer, with different resolutions and possibly even page sizes. You'd have to have the host software constantly updated with information about every manufacturer's fonts and imagable region size. You'd also have to come up with a standard format for shipping those bitmaps. And you'd have to have that postscript interpreter running on every kind of machine in land. One of the wins with PostScript as it is is that you can plug any PostScript printer into any machine that's got a PostScript file on it. * >The time necessary to ship images to a printer will only decrease >as networking technology develops. More effective use can be >made of the hardware if the hardware is part of a general purpose >system, rather than devoted to supporting a complex function >inside a peripheral. The relative power of that processor in the peripheral compared to the host is also going to decrease. Now, what *I'd* like to see is PostScript printers with either 1) engines that don't wear out or 2) an engine that is easily separable from the printer electronics, so when it goes you can replace it without throwing away the printer electronics. Here's why I say this: The practice here has been for years (I got here several months ago) than when the Canon engine on our Imagen (with separate IP) gets fuzzy (sometime after around 100,000 pages), they throw it out and buy a new engine. Now, this seems a little silly to me, since we never junked a canon engine at CMU or Scribe -- when I left they were all at a couple hundred thousand pages, and had periodically been "PM'd". If someone can turn me on to such a "PM"ing process, I would be grateful. * Except, of course, with things like @#$%#$#$%&*&* Interleaf, which purportedly outputs laserwriter-dependent code. -- @disclaimer(Any concepts or opinions above are entirely mine, not those of my employer, my GIGI, or my 11/34) beak is beak is not Anthony A. Datri,SysAdmin,StepstoneCorporation,stpstn!aad