Slow Printing

[Pete Randall]

Well, we learned a couple things and we created some new questions.

The message "lp: cannot create temp file dfA475yukon" is created when the sequence number wraps around to starting point. In other words, if we start printing with a sequence number of 407, the sequence numbers progress up to 999, wrap back to 000, then proceed on up from there. If we've printed 58 since the start, we're going to have overlap on sequence number 475 and that causes that message. The interesting part of that is that I can see number 475 in the /var/spool/lp/request/printername directory and, in fact copied it elsewhere for later perusal, but that particular page will never print. Operations staff have to go back through and manually re-print that single page. I should mention that (I think) we're limited to 3 digit sequence numbers because Novell made us define the printers as BSD style in order to get them to work at all.

We also had a smaller batch of 13 this morning that exhibited the stall behaviour after printing 9. There was no "cannot create temp file" message, so the message is unrelated. We re-printed this batch of 13 this afternoon and it printed 10 before stalling so it's related to the content or complexity of any particular page.

Out of curiosity, we reprinted the batch of 13 to a network queue (rather than the one defined on the Novell Netware server). The print times for each individual page shot up from 5 seconds to 30 or so. There didn't seem to be any of the pauses but that's unacceptable. Even with the occasional delays, we can get the whole batch done faster with the remote printers. Why would network printers be so slow?

During this whole process, I monitored (via tail -f) the .remotesending and .sendingstatus files. Nothing ever appeared so that seems to be a dead end.

Once this giant batch of 1356 finishes, I'll dump the printer's error log and see if there's anything in there.

The only other thing I learned out of this is that the dfA475yukon file has a corresponding
cfA475yukon file, the c version being the front and the d version being the back. Not germaine but amusing.

Well, it's getting late on a Friday afternoon. I think I'll give this a rest for now and get back after it come Monday.

Have a good weekend, all!


Pete

[Pete Randall]

ping!

[Pete Randall]

Correction to above:

We re-printed this batch of 13 this afternoon and it printed 10 before stalling so it's *NOT* related to the content or complexity of any particular page.


Pete

[Steven E. Protter]

Morning Pete,

I think it has to be in relation to the overall size of the job versus how much memory is allocated for the lp spooler in HP-UX. Since Novell no longer provides the queue, it ques until you run out of space on HP-UX and then stalls.

Helpful? Probably not, just an observation. Is there a way to give the spooler more memory reserved? That might fix it.

SEP