Re: parallel port using lots of CPU
I decided to give USB a try, but am not having any luck. I also encountered some more oddities with the parallel port. Details below. If any USB gurus can give me any hints, I'd be very grateful; I've spent a couple hours fiddling and browsing the net, to no avail. On Mon, Sep 20, 2004 at 10:17:15PM -0500, Kirk Strauser wrote: > On Monday 20 September 2004 10:09 pm, Ross Boylan wrote: > > > Mine says > > parport0: Printer, Lexmark International Lexmark Optra E310 > > lp0: using parport0 (polling). > > parport0: PC-style at 0x378 [PCSPP] > > > > I don't really know what that means, but it apparently has no > > interrupts and there's no reference to DMA, just PCSPP. Perhaps I can > > tweak my BIOS. Unfortunately, my system is interrupt starved. > > Yep, that's what it means. What do you have contending for interrupts? ISA sound card and modem. 2 ethernet cards. USB scanner (I'm not sure if that's grabbing anything). serial cable to UPS. parallel port printer. And there used to be a bit more (also one of the ethernet cards isn't doing anything right now--though both are PCI). > > > The (polling) certainly suggests that I am, umh, polling. Which would > > explain the CPU useage. Would this also slow down how fast it takes > > to ship stuff out? Printing graphics is painfully slow, e.g., 20 > > minutes per page (with 300dpi!). An aside: I was printing my black and white images in color mode (gimp). Changing them to Black and White cut the spool file size, and print time, to 1/3 the original level: 7 minutes. Still bad, but not as bad. A bit surprisingly, the greyscale output was exactly the same size as black and white. The scans I'm printing are B+W, no grey. > > Absolutely! I have an HP LaserJet 1200 hanging off a FreeBSD server. When I > was using CUPS to print large PostScript images, it could easily spend 20 > minutes pushing the data across. DMA mode wasn't significantly faster - > maybe 20% or so - but the CPU was mostly idle the whole time instead of > pegged at 100%. Switching to USB cut those times in half, but that would be > even more pronounced if my printer didn't have a dog-slow engine. > > > I was under the impression that USB was a bit experimental on Linux, > > but I did form that impression awhile ago. > > I hope not! That'd make my keyboard, mouse, Palm, and keychain drive stop > working. ;-) > > > Partly as a result of that, and on a more mundane level, I don't have a USB > > cable, and I remember them costing more than a completely trivial amount. > > I'm sure you can get one for $5 or less. $5.95 for 3 meter cable (2 meters was under 5). First, I tried enabling ECP on the parallel port in BIOS (it was disabled). This has the odd effect of expanding the number of modes listed by the parallel driver to include, among others, EPP, but not ECP! (EPP is another option in BIOS). Sep 22 12:28:47 wheat kernel: parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE,EPP] Sep 22 12:28:47 wheat kernel: parport0: irq 5 detected Sep 22 12:28:47 wheat kernel: parport0: Printer, Lexmark International Lexmark Optra E310 Sep 22 12:28:47 wheat kernel: lp0: using parport0 (polling). Also, disappointingly, it still says (polling). Or is that unavoidable? At any rate, this produced no noticeable improvement in print speed or CPU useage. Second, I got a USB 2.0 cable. Note that I already have a working USB subsystem, since my scanner is USB (though only USB 1.0, I think). I disabled the parallel port in BIOS, and disconnected its cable. As advised in the USB guide, I did mknod /dev/usb/lp0 c 180 0 and (eventually) made it world writable. I also reset CUPS to use USB printer 1. Unfortunately, all I get is the message that "USB device is not responding". Here's the full log. Sep 24 12:51:11 wheat kernel: hub.c: port 1, portstatus 101, change 1, 12 Mb/s Sep 24 12:51:11 wheat kernel: hub.c: port 1 connection change Sep 24 12:51:11 wheat kernel: hub.c: port 1, portstatus 101, change 1, 12 Mb/s Sep 24 12:51:11 wheat kernel: hub.c: port 1, portstatus 101, change 0, 12 Mb/s Sep 24 12:51:11 wheat last message repeated 3 times Sep 24 12:51:11 wheat kernel: hub.c: port 1, portstatus 103, change 10, 12 Mb/s Sep 24 12:51:11 wheat kernel: hub.c: new USB device 00:07.4-1, assigned address 2 Sep 24 12:51:11 wheat kernel: usb.c: kmalloc IF d6d5eb40, numif 1 Sep 24 12:51:11 wheat kernel: usb.c: new device strings: Mfr=1, Product=2, SerialNumber=0 Sep 24 12:51:11 wheat kernel: usb.c: USB device number 2 default language ID 0x409 Sep 24 12:51:11 wheat kernel: Manufacturer: EPSON Sep 24 12:51:11 wheat kernel: Product: EPSON Scanner Sep 24 12:51:11 wheat kernel: scanner.c: USB scanner device (0x04b8/0x011e) now attached to scanner0 Sep 24 12:51:11 wheat kernel: usb.c: usbscanner driver claimed interface d6d5eb40 Sep 24 12:51:11 wheat kernel: usb.c: kusbd: /sbin/hotplug add 2 Sep 24 12:51:11 wheat kernel: hub.c: port 2, portstatus 101, change 1, 12 Mb/s Sep 24 12:51:11 wheat ke
Re: parallel port using lots of CPU
On Mon, Sep 20, 2004 at 05:13:05PM -0500, Kirk Strauser wrote: > On Monday 20 September 2004 17:07, Marc Wilson wrote: > > > Uh, that's a CUPS back-end, not the hardware directly. The port itself > > cannot consume CPU. Well, it can, but not in the sense that you mean. > > In what way do *you* think it can consume CPU? That's easy... it can do DMA and force the CPU off the bus, then not allow it back on again. It can assert endless interrupts and lock the CPU up trying to respond to them. -- Marc Wilson | Teach children to be polite and courteous in the [EMAIL PROTECTED] | home, and, when they grow up, they won't be able to | edge a car onto a freeway. signature.asc Description: Digital signature
Re: parallel port using lots of CPU
On Monday 20 September 2004 10:09 pm, Ross Boylan wrote: > Mine says > parport0: Printer, Lexmark International Lexmark Optra E310 > lp0: using parport0 (polling). > parport0: PC-style at 0x378 [PCSPP] > > I don't really know what that means, but it apparently has no > interrupts and there's no reference to DMA, just PCSPP. Perhaps I can > tweak my BIOS. Unfortunately, my system is interrupt starved. Yep, that's what it means. What do you have contending for interrupts? > The (polling) certainly suggests that I am, umh, polling. Which would > explain the CPU useage. Would this also slow down how fast it takes > to ship stuff out? Printing graphics is painfully slow, e.g., 20 > minutes per page (with 300dpi!). Absolutely! I have an HP LaserJet 1200 hanging off a FreeBSD server. When I was using CUPS to print large PostScript images, it could easily spend 20 minutes pushing the data across. DMA mode wasn't significantly faster - maybe 20% or so - but the CPU was mostly idle the whole time instead of pegged at 100%. Switching to USB cut those times in half, but that would be even more pronounced if my printer didn't have a dog-slow engine. > I was under the impression that USB was a bit experimental on Linux, > but I did form that impression awhile ago. I hope not! That'd make my keyboard, mouse, Palm, and keychain drive stop working. ;-) > Partly as a result of that, and on a more mundane level, I don't have a USB > cable, and I remember them costing more than a completely trivial amount. I'm sure you can get one for $5 or less. -- Kirk Strauser pgplaRfgnLyNZ.pgp Description: PGP signature
Re: parallel port using lots of CPU
On Mon, Sep 20, 2004 at 08:50:36PM -0500, Kirk Strauser wrote: > On Monday 20 September 2004 07:29 pm, Ross Boylan wrote: > > > I'm not sure who *you* means, but my original thought was that the > > device driver associated with the port might be using a lot of CPU > > cycles. > > I think that's exactly what's happening, and I was curious as to why > others thought that it wouldn't be. > > > So the thing reported as parallel:/dev/lpt0 (or whatever it was) is > > actually part of CUPS? > > Yep. It it's most likely the kernel accumulating all of that CPU time, > but since CUPS is the application making the IO request, it gets the blame. > > Is your parallel port running in DMA mode? Mine is, based on dmesg: > > parport: PnPBIOS parport detected. > parport0: PC-style at 0x378 (0x778), irq 7, dma 3 > [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] > > If it's in a non-DMA mode, then I wouldn't be surprised to see the poor > performance you're describing. Also, I'd strongly consider migrating to > using the USB interface if at all possible - it really is much faster > (and typically better-behaved) than parallel. Mine says parport0: Printer, Lexmark International Lexmark Optra E310 lp0: using parport0 (polling). parport0: PC-style at 0x378 [PCSPP] I don't really know what that means, but it apparently has no interrupts and there's no reference to DMA, just PCSPP. Perhaps I can tweak my BIOS. Unfortunately, my system is interrupt starved. The (polling) certainly suggests that I am, umh, polling. Which would explain the CPU useage. Would this also slow down how fast it takes to ship stuff out? Printing graphics is painfully slow, e.g., 20 minutes per page (with 300dpi!). I was under the impression that USB was a bit experimental on Linux, but I did form that impression awhile ago. Partly as a result of that, and on a more mundane level, I don't have a USB cable, and I remember them costing more than a completely trivial amount. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: parallel port using lots of CPU
Doh, you are absolutely right, I meant XP. /icebiker - Original Message - From: "Marc Wilson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 20, 2004 18:06 Subject: Re: parallel port using lots of CPU On Mon, Sep 20, 2004 at 05:42:30PM -0400, Icebiker wrote: In NT/XP, MS supports parallel ports grudgingly and encourage you to invest in a USB device. I imagine it's the same for Linux. Just as an aside, NT certainly does nothing of the kind, as it has no clue what USB is. -- Marc Wilson | Lensmen eat Jedi for breakfast. [EMAIL PROTECTED] | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: parallel port using lots of CPU
On Monday 20 September 2004 07:29 pm, Ross Boylan wrote: > I'm not sure who *you* means, but my original thought was that the > device driver associated with the port might be using a lot of CPU > cycles. I think that's exactly what's happening, and I was curious as to why others thought that it wouldn't be. > So the thing reported as parallel:/dev/lpt0 (or whatever it was) is > actually part of CUPS? Yep. It it's most likely the kernel accumulating all of that CPU time, but since CUPS is the application making the IO request, it gets the blame. Is your parallel port running in DMA mode? Mine is, based on dmesg: parport: PnPBIOS parport detected. parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] If it's in a non-DMA mode, then I wouldn't be surprised to see the poor performance you're describing. Also, I'd strongly consider migrating to using the USB interface if at all possible - it really is much faster (and typically better-behaved) than parallel. -- Kirk Strauser pgphSM226WFcQ.pgp Description: PGP signature
Re: parallel port using lots of CPU
On Mon, Sep 20, 2004 at 05:13:05PM -0500, Kirk Strauser wrote: > On Monday 20 September 2004 17:07, Marc Wilson wrote: > > > Uh, that's a CUPS back-end, not the hardware directly. The port itself > > cannot consume CPU. Well, it can, but not in the sense that you mean. > > In what way do *you* think it can consume CPU? I'm not sure who *you* means, but my original thought was that the device driver associated with the port might be using a lot of CPU cycles. So the thing reported as parallel:/dev/lpt0 (or whatever it was) is actually part of CUPS? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: parallel port using lots of CPU
On Mon, Sep 20, 2004 at 05:13:05PM -0500, Kirk Strauser wrote: > On Monday 20 September 2004 17:07, Marc Wilson wrote: > > > Uh, that's a CUPS back-end, not the hardware directly. The port itself > > cannot consume CPU. Well, it can, but not in the sense that you mean. > > In what way do *you* think it can consume CPU? Well, if you feed a couple kA through the data lines, it'll probably consume everything attached to the mobo :) consume == destroy -- The world's most effective spam filter: ln -sf /dev/full /var/mail/$USER -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: parallel port using lots of CPU
On Monday 20 September 2004 17:07, Marc Wilson wrote: > Uh, that's a CUPS back-end, not the hardware directly. The port itself > cannot consume CPU. Well, it can, but not in the sense that you mean. In what way do *you* think it can consume CPU? -- Kirk Strauser pgpSLMRaidtRT.pgp Description: PGP signature
Re: parallel port using lots of CPU
On Mon, Sep 20, 2004 at 10:58:52AM -0700, Ross Boylan wrote: > Originally I was using lpd in the lpr package. With that, lpd showed > as the CPU consumer. I just switched to CUPS; now parallel:/dev/lp0 > shows as the CPU consumer. My guess is that it was before, but the > time was just being attributed to lpd. Uh, that's a CUPS back-end, not the hardware directly. The port itself cannot consume CPU. Well, it can, but not in the sense that you mean. -- Marc Wilson | Playing an unamplified electric guitar is like [EMAIL PROTECTED] | strumming on a picnic table. -- Dave Barry, | "The Snake" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: parallel port using lots of CPU
On Mon, Sep 20, 2004 at 05:42:30PM -0400, Icebiker wrote: > In NT/XP, MS supports parallel ports grudgingly and encourage you to invest > in a USB device. I imagine it's the same for Linux. Just as an aside, NT certainly does nothing of the kind, as it has no clue what USB is. -- Marc Wilson | Lensmen eat Jedi for breakfast. [EMAIL PROTECTED] | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: parallel port using lots of CPU
Parallel ports generate an interrupt (and so a context switch) for every byte that goes out, the hardware provides no buffering as serial ports do (and for some reason, the industry never saw the need). In NT/XP, MS supports parallel ports grudgingly and encourage you to invest in a USB device. I imagine it's the same for Linux. Your printer appears to support USB, why not give it a whirl? /icebiker - Original Message - From: "Ross Boylan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Ross Boylan" <[EMAIL PROTECTED]> Sent: Monday, September 20, 2004 13:58 Subject: parallel port using lots of CPU When I print graphics my parallel port consumes all available CPU. Admittedly the jobs are large (40-90MG), but it seems odd so much attention is required. Is something wrong, or do I just have to live with it? 2.4.26 kernel on Athlon CPU. Lexmark Optra E310 is the printer; it speaks postscript natively. Gigabyte GA-7IXE4 motherboard; the parallel port is on the board. Originally I was using lpd in the lpr package. With that, lpd showed as the CPU consumer. I just switched to CUPS; now parallel:/dev/lp0 shows as the CPU consumer. My guess is that it was before, but the time was just being attributed to lpd. P.S. Maybe it is a hardware limitation; under Windows NT the parallel got a kind of odd treatment, including the fact that the driver had to poll it and some utilities couldn't use it, though they could under Win95. I always thought it was just an NT quirk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
parallel port using lots of CPU
When I print graphics my parallel port consumes all available CPU. Admittedly the jobs are large (40-90MG), but it seems odd so much attention is required. Is something wrong, or do I just have to live with it? 2.4.26 kernel on Athlon CPU. Lexmark Optra E310 is the printer; it speaks postscript natively. Gigabyte GA-7IXE4 motherboard; the parallel port is on the board. Originally I was using lpd in the lpr package. With that, lpd showed as the CPU consumer. I just switched to CUPS; now parallel:/dev/lp0 shows as the CPU consumer. My guess is that it was before, but the time was just being attributed to lpd. P.S. Maybe it is a hardware limitation; under Windows NT the parallel got a kind of odd treatment, including the fact that the driver had to poll it and some utilities couldn't use it, though they could under Win95. I always thought it was just an NT quirk. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
