Date: Tue, 2 May 2000 15:57:00 -0500 (CDT) From: Chris Dillon <cdillon@wolves.k12.mo.us> To: Konrad Heuer <kheuer@gwdu60.gwdg.de> Cc: Lorenzo Iania <l.iania@sintesi.net>, freebsd-hackers@FreeBSD.ORG Subject: PROBLEM FOUND (sort of): Re: lpr: order of print requests Message-ID: <Pine.BSF.4.20.0005021309580.92225-100000@mail.wolves.k12.mo.us> In-Reply-To: <Pine.BSF.4.05.10005021716540.3805-100000@gwdu60.gwdg.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2 May 2000, Konrad Heuer wrote: > > On Tue, 2 May 2000, Lorenzo Iania wrote: > > > Warren Losh wrote: > > > > > LPR queues up the reuqests and prints them in order smallest to > > > largest to reduce the average wait time for a job at the expense of > > > having a larger standard deviation in the wait times for jobs. Maybe > > > this is what you are running into. I don't know if there's a way to > > > disable this behavior or not. At least that's what I recall lpd doing > > > years ago when I ran a unix lab in school. I didn't go check the code > > > to see if it still did that or not. > > > > > > Warner > > > > > > > I think you're right, because the process that generates the requests is > > only one. It consecutively opens pipes to lpr and then closes them. In > > effect it builds invoices from delivery documents and the printed numbers of > > invoices is effectively out of order, while the requests are ordered by > > number of invoice. Each pipe is opened and closed: so the processes are not > > concurrent: one begins after the other has finished. > > So, is there a way to disable this strange behavior? > > Hmm, I've never seen such a strange behaviour. Lpd should do FIFO. Could > you give some more infos about your environment (os release, input filter > program, printer type)? I had the same problem when I used Samba and a FreeBSD box as an intermediary print queue to a networked laser printer for some Win95 boxes. Needless to say, the secretaries didn't like the fact that all of the checks they printed were out of order on numbered check stock. :-( This is definately a bug, probably in the queue sort routine in usr.sbin/lpr/common_source/common.c. I'm no good at C programming, or I'd take a shot at finding the exact culprit and fixing it myself. I'm on 4.0-STABLE, and here is what I can produce: # lpq -a # for foo in 1 2 3 4 5 6 7 8 9 10; do echo "$foo" | lpr -Praw; done # lpq -a raw: Warning: raw is down: printing disabled Warning: no daemon present Rank Owner Job Files Total Size 1st root 41 (standard input) 3 bytes 2nd root 33 (standard input) 2 bytes 3rd root 34 (standard input) 2 bytes 4th root 35 (standard input) 2 bytes 5th root 36 (standard input) 2 bytes 6th root 37 (standard input) 2 bytes 7th root 38 (standard input) 2 bytes 8th root 39 (standard input) 2 bytes 9th root 40 (standard input) 2 bytes 10th root 32 (standard input) 2 bytes Notice the rank and job numbers, and that jobs 32 and 41 are swapped. Looking at the raw job data in the spool directory verifies that each sequential job is being placed into the queue with a correct sequential job number. Investigating further, this happens: Place just six jobs in the queue, and things are peachy: # lpq -a raw: Warning: raw is down: printing disabled Warning: no daemon present Rank Owner Job Files Total Size 1st root 79 (standard input) 2 bytes 2nd root 80 (standard input) 2 bytes 3rd root 81 (standard input) 2 bytes 4th root 82 (standard input) 2 bytes 5th root 83 (standard input) 2 bytes 6th root 84 (standard input) 2 bytes Add a seventh job and the odd sorting behaviour happens: # lpq -a raw: Warning: raw is down: printing disabled Warning: no daemon present Rank Owner Job Files Total Size 1st root 82 (standard input) 2 bytes 2nd root 80 (standard input) 2 bytes 3rd root 81 (standard input) 2 bytes 4th root 79 (standard input) 2 bytes 5th root 83 (standard input) 2 bytes 6th root 84 (standard input) 2 bytes 7th root 85 (standard input) 2 bytes The print queue is sorted by qsort(), so this wouldn't have anything to do with the magic number "7" I see in lib/libc/stdlib/qsort.c, would it? (ignore me... its probably just a coincidence) :-) -- Chris Dillon - cdillon@wolves.k12.mo.us - cdillon@inter-linc.net FreeBSD: The fastest and most stable server OS on the planet. For Intel x86 and Alpha architectures. ( http://www.freebsd.org ) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.20.0005021309580.92225-100000>