From owner-freebsd-hackers Tue May 2 10:34:43 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from usc.edu (usc.edu [128.125.253.136]) by hub.freebsd.org (Postfix) with ESMTP id 447F837B9BB for ; Tue, 2 May 2000 10:34:40 -0700 (PDT) (envelope-from walker@usc.edu) Received: from skat.usc.edu (walker@skat.usc.edu [128.125.253.131]) by usc.edu (8.9.3.1/8.9.3/usc) with ESMTP id KAA09692; Tue, 2 May 2000 10:34:34 -0700 (PDT) Received: from localhost (walker@localhost) by skat.usc.edu (8.10.1/8.10.1/usc) with ESMTP id e42HYWY22981; Tue, 2 May 2000 10:34:32 -0700 (PDT) Date: Tue, 2 May 2000 10:34:31 -0700 (PDT) From: Mike Walker To: freebsd-hackers@freebsd.org, Lorenzo Iania Subject: Re: lpr: order of print requests In-Reply-To: <027b01bfb446$0262c100$0500000a@sintesi.intr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Submitting the files with a single command should prevent reordering. lpc's topq command can be used to move a job to the top of the queue. Printing small jobs first is a desirable feature. Too often I've found a dozen people waiting while large jobs tied up the printers and that user wasn't present. I haven't looked at the code, but was told it took both size and submission time into consideration so that even large jobs would eventually print. If sending to a private printer, who does the print order matter? Are you trying to use forms? > 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? > > Thanks. >> 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message