Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!sceard!mrm From: mrm@sceard.Sceard.COM (M.R.Murphy) Newsgroups: comp.periphs.printers Subject: Re: How fast is a parallel port? (LONG, sorry) Keywords: Centronics, Drivers, Hardware, Dataproducts, Message-ID: <1991Feb28.125919.10505@sceard.Sceard.COM> Date: 28 Feb 91 12:59:19 GMT References: <1991Feb25.220636.23155@cbnewsh.att.com> <1991Feb26.175726.14215@bilver.uucp> Reply-To: mrm@Sceard.COM (M.R.Murphy) Organization: Sceard Systems, Inc. San Marcos, CA 92069 Lines: 130 In article <1991Feb26.175726.14215@bilver.uucp> bill@bilver.uucp (Bill Vermillion) writes: >In article <1991Feb25.220636.23155@cbnewsh.att.com> wcs@cbnewsh.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs) writes: >>I'm trying to find out how to connect big laser printers (50-100ppm) >>to normal computers, in particular to 386/486 boxes running UNIX. I used to run a 45ppm C.Itoh Ion Deposition Printer, a 15ppm Talaris laser printer, and an HP LJ2 off 3 parallel ports on a 10MHz '286. When printing ASCII (not graphics, for obvious reasons:-), the '286 could keep all three putting out paper at printer limited speeds. The '286 was running Microport System V/AT with Excelan TCP/IP. It was used as a print server. There was enough CPU poop left over to handle the SysV LP spooling, the part of TCP/IP that happend to be on the '286 and not on the Excelan 205 board, and the occasional login to check on print job status. I didn't bother to check on how much CPU poop was left over, and now the printers are gone. :-( The printers would each stop for a few seconds between jobs as the spooler figured out what to do next, but during the printing of a job, the printer would just keep putting out paper. A fast disk and controller helped. >.... >>How much CPU does it burn? ... > >Only addressing this one issue, CPU processing. > >A couple a years one of the vendors I used did some testing as to >the efficiency of some of the serial boards he was using. He >printed to parallel and serial buffer boxes (to eliminate any >potential differences in printers &/or their serial/parallel >differences). > >He printed his termcap file, about 75k. The following is >from memory, but should be easy to test. > >CPU time to the parallel port was about 17 seconds. >CPU time to a non-smart multi-board serial port was 7 seconds. >CPU time to a smart serial board was .75 seconds. > >I found I could get higher sustained throughput to something like a >LaserJet if I used serial vs parallel. THis was also during the >time that some parallel ports in the SvsV 386 world weren't as >robust as they should be. Or maybe the driver in the OS was a loser. Like not doing interrupt service right, or maybe just using polling mode? > >Suggest you make your own timings to see. > >-- >Bill Vermillion - UUCP: uunet!tarpit!bilver!bill > : bill@bilver.UUCP The test above may not be testing just the parallel port board, the dumb serial board, and the smart serial board, I say with a smile. It sure does depend upon the software that drives the board. It also does depend upon the response of the printer attached to the board. Now for the long and anecdotal part :-) Back in the days when you could actually buy a Centronics 101, Centronics had a specification for the interface. Now that nobody remembers what a Centronics 101 looks like, people don't pay as much attention to the spec as they might. The original spec (correct me when I'm wrong) was for 250KByte/sec, i.e., 4us/byte transfer rate. The 101 would accept data at 4us/byte until the line buffer filled, then go busy until the line printed (as in about 1/60 sec busy whilst waiting for the mechanical stuff to move). This is really bursty behavior. So, drivers for printers on parallel ports would do something like the following in an interrupt routine: A:if done with user buffer, print request complete and exit interrupt if printer busy, then exit interrupt routine get a character from the user buffer print the character go back to A The 4us was short enough so that the time between "print the character" and "if printer busy" in the loop meant that the printer wasn't busy except when the mechanical stuff had to move (or the paper jammed or something broke). Then came the really clever use of microprocessors in the printer. Let's have fancier fonts, and more graphics, and slicker control, and maybe control more of the print engine. All with the same microprocessor. Overburdened microprocessor. This dropped the rate at which the printer could accept characters to about 5K characters/second, give or take. It also meant that drivers that use the scheme above get to test the interrupt context switch capabilities of their operating system and CPU to the hilt. Coupled with faster CPUS that do the loop in the driver faster, the result is a lot of time spent servicing interrupts. NOP's between "print the character" and "go back to A" can help, but sometimes not enough. What this all comes down to is o If the driver is well written, the parallel ports available for the ISA will put out more than enough bytes/second to drive the fastest printers now available that are able to accept those bytes from Centronics parallel ports. Certainly they will put out more than 5K bytes/sec. o Serial ports are probably going to be limited to 38.4K bits/sec. With one start, one stop, that works out to less than 4K bytes/sec. o A page of plain ASCII is about 80x60 characters, or a little less than 5K bytes. o A parallel port with an OK driver will drive a 1 page/second printer at full out speed on plain ASCII. o A serial port at 38.4K won't. If we go to graphics, say for example, PostScript, where a PS file might be 2MB for a page, then it really is a lot nicer to have a parallel connection rather than a serial connection. 2MB/(3840cps) = 500+ seconds. A long time to wait for a page. The advantage of the parallel port is true only if the driver is worth a hoot. Bill is right about testing. It pays to look at the horse's mouth. Why not try sending a really long file that doesn't move anything, like maybe a long string of unprintable characters, to the printer and timing the results? That'll test the OS, driver, port, and printer input combination. Then try sending multiple pages of printable stuff and timing it. That'll test the paper jamming tendencies of the printer :-) BTW, a cheap XT clone with one floppy, an NE1000 clone Ethernet card, a parallel port, DOS, and NCSA Telnet using the FTP client stuff (free, BTW) makes a real nice little box to hang off an Ethernet as an Ethernet/Centronics converter. Total cost of less than $500. More like $300 if used equipment. Easy to hook into BSD or SV spooling, too. More than one parallel port on the box, and it'll do more than one printer at a time. With the right BIOS, it doesn't even need a keyboard or monitor. -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874