spg@alpha.sunquest.com (Steve Gibbons) (02/26/91)
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. #For a variety of ugly reasons, I don't want to use Ethernet - #I'd really like to use a parallel port. But nobody I've talked to #knows how fast a parallel port can go on a typical machine, and #nobody's tried it at speeds over about 10ppm. #50-100 ppm is 1-2 pages/second, or typically 40-80 kilobits/second; I'm _Not_ an expert so take this with a grain of salt... There are communications packages that claim rates up to 250 kilobits/second, The three mitigating factors that I can see in drawing a parallel (*heh*) would be data-compression, and bi-directionality, and tweaking the hardware/driver. My back-of-the-envelope estimate is that a fast iX86 ought to be up to the task. The real question is whether the port itself can handle that kind of throughput, but I guess that's really your original question... ___________________________________________________________________________ | Steve Gibbons, H.I.S. Interfacing | 602/885-7700x2649 or 602/296-8936(Fax)| | Sunquest Information Systems | spg@{alpha|nereid|beta}.sunquest.com | | 930 N. Finance Center Drive |---------------------------------------| | Tucson, Arizona 85710-1343 | "Stone walls do not a prison make..." | ---------------------------------------------------------------------------
debra@wsinis03.info.win.tue.nl (Paul de Bra) (02/26/91)
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. >For a variety of ugly reasons, I don't want to use Ethernet - >I'd really like to use a parallel port. But nobody I've talked to >knows how fast a parallel port can go on a typical machine, and >nobody's tried it at speeds over about 10ppm. > >50-100 ppm is 1-2 pages/second, or typically 40-80 kilobits/second; >not much faster than a 38.4 kbps RS-232 port. Using the non-interrupt parallel driver (pp) which is public domain one can drive the parallel port as fast as it can go. The maximum speed depends largely on the combination of printer and interface. (there is a big difference between interface boards) I tried several interfaces on my Everex Step 386/25 and a Nec P5 printer, and at 360dpi the best I got was about 3 seconds per 'line', which means about 4kbyte per second. This most certainly will not be enough to keep a fast printer busy, especially not when you are printing bitmaps. Paul. (debra@win.tue.nl, debra@research.att.com)
ar12@prism.gatech.EDU (REGISTER,ANDREW H) (02/27/91)
In article <14740@sunquest.UUCP>, spg@alpha.sunquest.com (Steve Gibbons) 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. > #For a variety of ugly reasons, I don't want to use Ethernet - > #I'd really like to use a parallel port. But nobody I've talked to > #knows how fast a parallel port can go on a typical machine, and > #nobody's tried it at speeds over about 10ppm. > > #50-100 ppm is 1-2 pages/second, or typically 40-80 kilobits/second; > In the old days most of the parallel ports were made from an Intel 8255 programmable peripheral interface. Now a`days, many are integrated in the vlsi chip sets. Anyway I pulled the data sheet and if I am decifering the timing diagram correctly for mode 1 strobed output I get somewhere in the neighborhood of 1000 to 1500 nS per write cycle. This is from the 80x86 write going active to the end of data going out of the i8255 and onto the peripheral. Of course this assumes that the peripheral acks immediately. This corresponds to a *very* large data rate. Given this, the port is most likely software limited. If you want to figure out the max rate then you would have to figure out the most efficient assembly code and count cycles. Something like beginloop: mov ax,[dx] mov "port address",ax inc dx jmp beginloop please forgive my coding, it has been a long time since I had to resort to assembly. And I don't remember if you have to poll the ack line. I think that you do. Toodles Andy -- Andy Register Internet: ar12@prism.gatech.edu Bitnet: aregiste@gtri01.bitnet -- Sometimes the Bears Win, Sometimes the Bulls Win -- -------- But the Pigs *Always* Lose -------- (author unknown)
sichermn@beach.csulb.edu (Jeff Sicherman) (02/27/91)
In this vein, does anyone know of any smart port cards, or DMA driven parallel cards for the ISA bus that will offload the main processor of this task. Seems like a waste to use 386 and 486 processors for this kind of junk. Jeff Sicherman
mrm@sceard.Sceard.COM (M.R.Murphy) (02/28/91)
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
craig@mstr.hgc.edu (craig chaiken) (03/01/91)
An IBM PC parallel port is generally capable of transmitting data at rates up to 50 kilobytes per second. Part of this limitation is the PC's CPU speed, but the printer port itself is actually a bottleneck, too. Most parallel ports consist of various gates and buffers which introduce considerable delay. It is possible to achieve far greater speeds by using faster gate and buffer ICs. In fact, the parallel port on the Hewlett Packard HP9000/400T workstation is rated at 300 kilobytes per second. Craig Chaiken craig@mstr.hgc.edu
rjn@hpfcso.FC.HP.COM (Bob Niland) (03/03/91)
re: > It is possible to achieve far greater speeds by using faster gate and > buffer ICs. In fact, the parallel port on the Hewlett Packard > HP9000/400T workstation is rated at 300 kilobytes per second. Vendors also play fast and loose with the "spec" (which is pretty vague in the first place). Tektronix runs the "Centronics" interface on their 4693DX at a megabyte/sec. Regards, Hewlett-Packard Bob Niland Internet: rjn@FC.HP.COM 3404 East Harmony Road UUCP: [hplabs|hpfcse]!hpfcrjn!rjn Ft Collins CO 80525-9599
harkins@casbah.acns.nwu.edu (Don Harkins) (03/03/91)
>> re: > It is possible to achieve far greater speeds by using faster gate and >> > buffer ICs. In fact, the parallel port on the Hewlett Packard >> > HP9000/400T workstation is rated at 300 kilobytes per second. > Vendors also play fast and loose with the "spec" (which is pretty vague in > the first place). Tektronix runs the "Centronics" interface on their 4693DX > at a megabyte/sec. > > Regards, Hewlett-Packard > Bob Niland Internet: rjn@FC.HP.COM 3404 East Harmony Road > UUCP: [hplabs|hpfcse]!hpfcrjn!rjn Ft Collins CO 80525-959 The Tektronix 4693DX manual specifies a 700KB / second rate in a data burst using an extended definition of the Centronics protocol called TPI (Tektronix Parallel Interface). I heard from a Tek rep that a Metheus Display controller was the only device Tek knew about that could out-run the 4693DX. I tried a 286 10Mhz PC and could only do 12KB / second using int17 commands! On the same PC, using my own assembly language routines like the ones described previously, I was able to get 70KB / second. I suspect Tek made the 4693DX this fast so that they could use their terminals to offload color data quickly. Remember color needs rates 24x faster to keep up with a monochrome printer (1 bit vs. 24 bits per pixel). As far as your message Bob, this newsgroup is not the place for one printer manufacturer (HP) to put down another. It dosen't reflect well on you or your company. Internet: harkins@casbah.acns.nwu.edu Don Harkins, Northwestern University
sgothard@hpdmd48.boi.hp.com (Steve Gothard) (03/05/91)
The way I test the speed of the centronics port of a PC is to tie BUSY to GND and send a few megabytes while timing with a stop watch. Steve Gothard Hewlett Packard Designing LaserJets for Bill and Dave
sschaem@starnet.uucp (Stephan Schaem) (03/06/91)
Well if you want to know how fast your parralelle port goes you need to know how both end handle it... If you are using a 386 you will get more than 69k for sure. But doing that is not to good for the system operation, and if you already have a DMA scsi port... I never tested the parallel port higher than 60k with a 68000 at 7mhz, but both end count for the troughtput performance.
jkm@astro.as.utexas.edu (James McCarthy) (03/09/91)
In [comp.periphs.printers] article <1991Feb28.10505>, Mike Murphey writes ... > ... > 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 if 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) > .... >--- > Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874 This discussion in comp.periphs.printers regarding the Centronics printer inter- face prompts me to wonder about the feasibility of a PARALLEL interface to MIDI (Musical Instrument Digital Interface -- serial current loop at 31.25Kbaud, 5mA on/off signal in a typical serial protocol of 1 start bit followed by eight data bits and one stop bit -- serial MIDI interfaces using 9600 [or even 19.2K] baud aren't really fast enough). An article in _Computer_Music_Journal_, vol. 10, no. 3 (Fall 1986), pp.79-82 discusses "A MIDI Output Interface to a [Centronics] Parallel Printer Port" and gives a schematic and timing diagrams. BUT, it is only a one-way interface (computer ---> musical instrument); today's MIDI key- boards transmit event codes thru a separate "MIDI OUT" port, and ideally the parallel I/O interface should accept these data as well with a "MIDI IN" port. [ Sorry if this is too basic for you, but (i) I'm still fairly new to MIDI and (ii) I'm cross-posting this to several non-MIDI groups since I'm really after computer hardware information ... but I'm getting ahead of myself .... ] Indeed from the ref_manual of my computer/dinosaur it appears both are possible: my UCSD Pascal p-machine uses an ``8255A Programmable Peripheral Interface'' IC chip behind its 37-pin parallel port, and by default the p-system configures the parallel port to provide 8-bit parallel _input_ and _output_ capability through this port. The manual, however, doesn't say much more about _input_ but only goes on to discuss the parallel-port-to-Centronics-cable-wiring necessary for the proper _output_ handshakes ... using a small subset of the 37-pins on the computer's parallel port. Has anyone out there in net-land ever heard of this 8255A parallel I/O chip ? Can you point me towards some [old??] documentation ??? Do typical "parallel [printer] ports" on most of today's computers also have provision for 8-bit parallel *input* as well as output ? (it seems to me the best modern-day MIDI interfaces are cards for expansion slots [with direct access to the bus], but they're therefore very computer-specific [which won't help me w/ my dinosaur]; the other approach these days is to drive the MIDI interface from the serial port, but again this isn't really fast enough, and/or requires buffering the MIDI computer input). Followup please to rec.music.synth, or e-mail to me. Thanks in advance, -- Jim McCarthy 7201 Wood Hollow Dr. #326 Austin, TX 78731 (512) 346-7892 jkm@astro.as.utexas.edu -------------- Assuming I get this interface built someday, I'd also like to hear from folks writing their own [UCSD?] Pascal software for MIDI applications. I'm the new owner of a used Ensoniq Mirage digital sampling keyboard .... At the risk of embarrassing myself further (and causing laughter among the comp.* readers of this post :-), my `dinosaur' computer is a Western Digital "Pascal Microengine" [WD/90 or ME/1600] UCSD P-system w/ 128K RAM -- technology circa 1979 but still running !! ______________ Disclaimer: It goes without saying this has nothing at all to do with astronomy.... ------------------------------------------------------------------------------
gene@digibd.com (Gene H. Olson) (03/12/91)
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. >For a variety of ugly reasons, I don't want to use Ethernet - >I'd really like to use a parallel port. But nobody I've talked to >knows how fast a parallel port can go on a typical machine, and >nobody's tried it at speeds over about 10ppm. I am afraid you are in for the big hurt. In the tests I have conducted, the parallel port on a typical SCO 386 machine runs about 5000 cps, and uses about 80% of the host cpu to service the interrupts. This performance level is truly appalling, and I would strongly suggest you look at vendors of intelligent parallel ports before you commit yourself to running 20 ppm on a 100 ppm laser printer.... -- _________________________________________________________________ __ / ) Gene H. Olson uunet!digibd!gene / __ _ __ _ DigiBoard Inc.