Note: please don't spam any of the e-mail addresses which you see here. Follow this link if you want some addresses to misuse.
From: David Chappell <David.Chappell@mail.trincoll.edu> Date: Thu, 08 Feb 2001 08:06:48 -0500 Subject: Re: PPR: Spoolong to printer priority adjustment? - --------------C2520D358D18631CA8F5796E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alain.Lachapelle@Heimannsystems.Com wrote: > Hello, > > Is there a mechanism already built-in PPR to decrease the throughput > of > data to a networked printer? The situation is this: the Linux > machines are > near operating as real-time and needs a lot of time resources to > respond to > real-time hardware events. When an opearator asks for a printout the > printout is generated and spooled with PPR to a printer. The whole > process, from spooling to printing, takes about 60 seconds (files are > average 6 MB in size) during which the operator sees a progress bar > indicating the bytes received by the printer (ppop -m progress). > There is > a very real possibility that the printer may be busy at that time, in > which > case the printing daemon will try several times to send the file. And > this > sending may finally occur when the operator is doing > hardware-intensive > work with the machine. At such times it would be pratical to regulate > the > data transmission throughput. Is there an option in PPR that may > provide > this utility? > > Regards, > > Alain We, you could run pprd at reduced priority. Then pprdrv and the interface programs would inherit that reduced priority. You could also insert a usleep() call in the loop that calls write() in pprdrv/pprdrv_buf.c:printer_flush(). Since write() will manage 4096 or maybe 5120 bytes each time (that is typically the chunk size for pipes), if you delayed for 25,000 microseconds, that would limit the bandwidth to about 160 kilobytes per second. - --------------C2520D358D18631CA8F5796E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> <pre> Alain.Lachapelle@Heimannsystems.Com wrote:</pre> <blockquote TYPE=CITE>Hello, <p> Is there a mechanism already built-in PPR to decrease the throughput of <br>data to a networked printer? The situation is this: the Linux machines are <br>near operating as real-time and needs a lot of time resources to respond to <br>real-time hardware events. When an opearator asks for a printout the <br>printout is generated and spooled with PPR to a printer. The whole <br>process, from spooling to printing, takes about 60 seconds (files are <br>average 6 MB in size) during which the operator sees a progress bar <br>indicating the bytes received by the printer (ppop -m progress). There is <br>a very real possibility that the printer may be busy at that time, in which <br>case the printing daemon will try several times to send the file. And this <br>sending may finally occur when the operator is doing hardware-intensive <br>work with the machine. At such times it would be pratical to regulate the <br>data transmission throughput. Is there an option in PPR that may provide <br>this utility? <p>Regards, <p>Alain</blockquote> We, you could run pprd at reduced priority. Then pprdrv and the interface programs would inherit that reduced priority. You could also insert a usleep() call in the loop that calls write() in pprdrv/pprdrv_buf.c:printer_flush(). Since write() will manage 4096 or maybe 5120 bytes each time (that is typically the chunk size for pipes), if you delayed for 25,000 microseconds, that would limit the bandwidth to about 160 kilobytes per second. <br> <br> </html> - --------------C2520D358D18631CA8F5796E--