There may be a couple of reasons - but since you didn't post the OS and version, I'll just have to hope this also applies to your OS (it probably does)
Quote:
As implemented, the Solaris Operating System's (versions 9,8, and 7) LP spooling subsystem for receiving inbound print jobs, releases print jobs based on when they finish arriving versus when they were actually submitted (for performance reasons). Consequently, a small job submitted second from a client computer may actually arrive first and be released to a physical print device before a large job that was submitted first. This scenario has also been inherit to many other LPR/LPD printing implementations because their original designs all use at least 11 "logical ports" for sending data (LPR requests). Unfortunately, in some implementations, the receiving side (LPD) has not always taken responsibility for FIFO, either as a part of the standard design or as an option. This presents major operational problems in "statement", "invoice", and "check" printing environments.
What makes this problem particularly elusive and troublesome is the fact that by "chance" FIFO is generally maintained under Solaris LP. However, it is NOT guaranteed and is evident primarily when extremely small print jobs (<= 50 Kbytes) are intermixed with more normal or large sized print jobs. This problem has been discussed with Sun and they stand behind the current design and do not consider it to be a defect.
|
(quote from
FIFO of print jobs )
And if I remember correctly, print queues will usually print smaller files first (no matter the OS) - could be a problem on a different print queue than just your OS. You need to also mention the how's and where's - is this a UNIX only print queue or does it ship it off to a LAN/WAN print queue in NT or some other OS?
You might look to see if there is a hold option for your lp command - if so, putting all printjobs on hold and then releasing once they are all there may solve your problem (you will still need to check that it's not going to re-arrange the jobs by size).
