Slow Printing

[Pete Randall]

A recent upgrade of our Netware file server has changed the way print queues are defined. It is my understanding that there are no queues any longer and Netware simply funnels the job directly to the network attached printer without any interference.

We have one particular print job, duplexed, with graphic images on the back (cow pictures, actually), that is now taking forever to print. It seems to start printing at a reasonable rate, but then starts to slow down, pause, resume, pause, resume, etc. Based on the theory that Netware used to provide some queueing that we are not getting the benefit of now, we added memory to the printers and have seen some improvement, but it's still not as good as it used to be.

I have tried defining these queues as network printers with pretty much the same results. At the moment, they're defined as remote printers because I want to debug from a known starting point.

So, any suggestions? Do we keep throwing more memory at these printers? How much is a reasonable amount of memory to have in them (they're HP8100DN's, by the way). Is there anything that could be done to the print job itself to improve things?


Pete

[Bryan D. Quinn]

Hey Pete,

Are you sure there is not some kind of network bottleneck going on? That sounds suspiciously similar to a network issue I am fighting right now. Although I must say that I have not had any printing complaints, but then again we do not have any really big print jobs going across the network.

Just a thought.

-Bryan

[Pete Randall]

Bryan,

Thanks for the thought. I can't see how it could be the network, though. The network is exactly the same (other than the upgraded Netware file server that lives on it). We saw no network bottlenecks before and we see no network bottlenecks now.


All,

One additional item. I'm not sure whether this might be a cause or an effect, but I'm curious about it. We get messages, starting around the time of the slowdown (I think), that say "lp: cannot create temp file dfA475yukon". The 475 portion changes with each message occurence and the yukon is the hostname. Any guesses where and why this file can't be created?


Pete

[Steven E. Protter]

I think we have our key Pete:

lp: cannot create temp file dfA475yukon

Where does this get created? /var

We have some big massive print jobs with graphics(no cows) that can cause similar issues with us. I hav /var pretty liberally defined but when someone does a 36,000 page job with graphics, /var get up in the low 80% range, and temporory spools and logs start to slow down, even on a rp5450.

I'd say /var is getting full of spool files and the attempt to create another is file.

Try running the print job through a box with a larger /var filesystem and seee if there is a performance improvment. Or simply watch the syslog and /var space during one of these BUFCJ

Big
Ugly
Fat
Cow
Jobs

Cheers,

Steven

[Pete Randall]

SEP,

Nice try, but there's a couple of flaws with that theory. First, and free space, of /var has not changed. Second, there would be a message (in dmesg) if it had filled.

I don't think that's it.


Pete

[Steven E. Protter]

Ours gets near filled, so there is no message just a slow down.

I think the message is the key.

file can't be created.

Not enough room.
No permissions.
Directory does not exist.

Netware stopped queueing and now your box has to. Thats got to be a factor.

I have to get organized and get to work. I'll think about it on the train.

SEP

[Pete Randall]

SEP,

That should have said "First size, and free space, of /var have not changed".

My /var is 12GB and generally has 6GB free. I intend to try and catch it during one of these errors to see if I can figure anything out, but I have a real hard time believing that a print job is filling some 6GB of /var!


Pete

[Pete Randall]

Make that "neither size nor free space of /var have changed".


Pete

[Patrick Wallek]

Hey Pete,

Check out TKB doc id: A3137254. It is old (HP-UX 8! and references /usr/spool rather than /var/spool) but there's a slim chance it might apply.

I know this doesn't help much, but an LP error message document (Doc id: HPUXERR03) shows:

cannot create temp file xx.

Unable to create a temp file when copying to the request directory.

Maybe the lp is trying to use the same temp file name and is having trouble copying over one that is already there?

[Pete Randall]

Patrick,

Thanks for digging that nugget out!!

I'll have to see if I can catch it in the act to determine what it's doing. The TKB doc's solution of making sure there's no leftover requests doesn't seem to apply here, though. We'll see.


Pete

[Jeff Schussele]

Pete,

LP spools the actual requests in /var/spool/lp/request/ptr_name
Dir also holds the .sendingstatus file - the actual status the remote/network printer at the time as well as the .remotesending file - which I believe is a job status file.

Check this dir & those files - especially the .remotesending file while the job is printing.

Rgds,
Jeff

[Pete Randall]

Thanks, Jeff, that's what I hope to be able to do. I've got to catch it in the act. The problem is that it seems to take up to 1200 or so pages before the problem starts. In order to keep things "moo"ving here, they've been running smaller, more frequent batches of 600 or so. We're going to let things accumulate tomorrow morning so I can babysit a BIG batch and we'll see what we see there.


Pete

[Jeff Schussele]

Pete,

Yep sounds like a plan...

As to the file name - I'm fairly certain that's going to be the actual spool request name in that dir. I believe the d stands for data, fa I'm not sure about, the 475 should be the sequence # (Check the /var/spool/lp/seqfile to verify), and the hostname is obvious.

I'm wondering whether lp "sees" a problem with the job or printer (like a connection dropped to the printer) and is trying to respool the job from the start and in fact the job is OK & still running so the spool file is still there & *that's* the msg. It can't create the spool file *because* it's already there.
Just a guess....

That's why you should check those status files for bogus status as well as the spool file name.

Good Hunting,
Jeff

[Jeff Schussele]

And a couple other things...

What is the printer's NIC connected to? A switch or hub port? If it's a switch or an intelligent hub, then check the link type. It's possible that it's at 10HD & you're getting a lot of collisions & retrans that might be causing a status change & the job IS actually respooling. And if the ptr's NIC & it's link partner - the port - are capable of 100FD, then get them to that connection type.

You should be able to telnet to the ptr & check the link type, I think, & even set it.

Rgds,
Jeff

[Jay Bollyn]

Pete,

I saw the pause-between-pages on our 8100 and 8150 LJs. I'm not sure what fixed it, because we changed several things at about the same time. We use Novell NDPS.

I suggest make sure your JetDirect firmware is up-to-date.

We have about 100MB printer RAM in our 8100 LJs. I'm not sure is one needs that much, but it is pretty cheap. Check crucial.com.

We don't have any 1000+ page print jobs. Our print jobs are mostly less than 50 pages.

What file format is the print job?

:-) Jay

[Pete Randall]

Jay,

Thanks for your response!

Firmware is the absolute latest. We had to upgrade just to get Net(una)Ware to talk to them.

We're now at 176MB RAM.

File format is PCL, I think? Would that make any difference?


Pete

[Bill Brayford_2]

Hi Pete

Have you checked the error log on the printer? If printer sees an error it should be there even if its continuable.

Only possible printer condition I can see is fuser temp temporarily out of range?

And since I can't resist the pun is it possible the printer is mistaking Cows for Sheep and simply nodding off?

Bill

[Jay Bollyn]

Pete,

My best guess was JD f/w, and you already have that covered.

When we saw slow printing, it was PDF docs. The pause was sometimes as long as 30 seconds. We changed the printer driver on the winXP clients from PCL to Postscript. PS is well suited for graphics in general, particularly PDF.

You might want to think about upgrading the firmware ROM in the printer. It just snaps into the print formatter like a RAM module. Here is the partsurfer link:

http://makeashorterlink.com/?W237230B7

I'm not sure what Firmware Datecode this upgrade will give you. We have not upgraded our 8100 LJs.

Since you are only seeing this problem on a very long print job, only a small % of 8100 customers are going to see this problem. So I think you might need to try a few things before finding the solution.

:-) Jay

[Pete Randall]

Bill,

Thanks, especially for the pun ;^).

I've checked the lp logs to no avail. It sounds, though, like you might be referring to a log the printer itself maintains??


Pete

[Pete Randall]

Jay,

I'll have to check for sure whether it's PCL or PS. Thanks for the hint about the firmware ROM. We'll look into it.


Pete

[Jay Bollyn]

On the printer control panel, under Information Menu, is an option Print Event Log.

:-) Jay

[Pete Randall]

Thanks, Jay, I'll check!


Pete

[Pete Randall]

I'm still waiting to run a big batch today but thought this would be a good time to float this back to the top.

I'd also like to point out a potentially similar query from Yvonne that you could take a look at:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=502950


Pete

[Jay Bollyn]

Regarding the printer firmware ROM I mentioned earlier, here is a link:

http://www2.printerworks.com/cgi-win/tpwall.exe/find?C4214-60009

This ROM will give you Firmware Datecode MB5.62. Our 8100 LJs are using MB5.48. It would be nice to find a HP doc which lists all the issues which each firmware revision addresses. Like they do with PC BIOS revisions. I'm sure there is an internal HP doc with this information.

The scenario of printer speed initially OK, and then gradually slowing down, is fairly common with the 8000-series. It also affects the 5si. Most people report that rebooting the printer brings fast speed back, but the problem eventually returns. I wonder if this could be a memory leak. If so, one might hope that a printer firmware upgrade might fix it.

:-) Jay

[Pete Randall]

Jay,

That theory sounds promising. I don't think we've tried turning it off and back on at that point (probably nobody wants to risk losing the rest of the 1400-1500 page job!). We're looking into the ROM firmware upgrade, though that's going to take some time.

This afternoon we're scheduled to try a big batch so I can watch what happens and try to gather some evidence. I just might try turning the damn thing off!

Thanks again,


Pete