CUPS slowness :(

[Ric_]

OK... as you are all aware I have been tinkering with CUPS and Pykota. I am currently using the box with just one queue - implementation brought forward by the driver going mental on my Win 2003 box.

 

Anyway... jobs seem to take an age to pop out! From my readings on the net, it seems that Ghostscript/EPS may be to blame but no fixes are forthcoming . Any ideas on how to fix would be gratefully received.

[openhgs]

Have you tried downloading ESP Ghostscript version 8.15.4 from the cups website? http://www.cups.org/espgs/index.php

[NeoS]

What driver are you using?

 

Is this a postscript printer or are you using PCL and passing it through the server as raw data?

 

If you are using the CUP's Windows Drivers then this may be your problem. We had a similar problem that didn't support postscript and therefore GhostScript took ages to do its thing!

[Ric_]

I'm currently running ESP v8.15.3.dfsg from Debian Testing.

 

I am using the CUPs Windows Postscript Drivers on the clients and then the Foomatic drivers on the server.

 

Is it worth me upgrading the GS version?

[NeoS]

Hard to say.

 

I had many issues with the Foomatic Filters and cups drivers.. even though i upgraded the ESP version to 8.15.3 and then even switched to version 8.54 of GS (Non ESP). Nothing solved my inability to print. (I switched back to PCL Drivers after this)

 

Can you post your Foomatic Logs/Cups Logs

 

If foomatic isnt logging, reconfigure foomatic-filters using dpkg and enable logging. the log file will be dumped into /tmp/.

 

This may shed some light onto what's actually happening on the server. It could even be something like locales not being set properly!

[CyberNerd]

I recall reading from the samba manual that if the printer is a true postscipt printer then it's best to print directly to postscript. Might not help you though ..

[Geoff]

Are you using Psyco?

[Ric_]

Are you using Psyco?

 

Since I've never heard of it... no.

 

The printers are all PCL-based HPs without postscript.

 

I'll try scouring the logs tomorrow... it's not as if the things aren't printing... they just take a ridiculous amount of time. Although I do have a problem printing to my Business Inkjet 3000 printers but I'll fix that once I've done this.

[Ric_]

@Geoff: So you think that Python might be slowing things down?

 

If that is the case, I could quickly test the theory by creating a second queue to the same printer, without the PyKota part. This would narrow things down a bit if CUPS-only is quick and CUPS+PyKota is slow.... hmmmmmmm

[Geoff]

If your printers are PCL/PCLXL and your not using psyco, yes. It makes a massive difference. At least according to the PyKota docs.

[Ric_]

Hmmmm.... well my scientific experiment has shown that without Pykota my test document takes approx. 17s to appear at the printer but with PyKota it takes approx. 31s!!!

 

Looks like I may need to take a look at Psyco.

[Ric_]

I already have Pysco 1.5.1-3 installed.

 

I have also tried installing pscopg to see if that has an impact... alas it does not

[Ric_]

Sussed it!!!!

 

It was the accounting method.... I was using hardware(pjl) and a test with software() speeds things up no end. I really want to change to SNMP though.

[NeoS]

I have only every gotten Software() accounting to work with our Brother Printers. Maybe its limitation with hardware.. if your using postscript drivers, how much memory is assigned to processing postscript in device options?

[Ric_]

@NeoS: I only have HP printers - I don't like brother ones

 

As I mentioned above, the hardware accounting works but is incredibly slow (at leat the pjl type since I haven't managed to get the SNMP type working YET).