Date: Sat, 7 May 2011 15:32:49 +0200 (CEST) From: Wojciech Puchar <wojtek@tensor.gdynia.pl> To: Warren Block <wblock@wonkity.com> Cc: questions@freebsd.org Subject: Re: about ulpt speed Message-ID: <alpine.BSF.2.00.1105071528590.1476@wojtek.tensor.gdynia.pl> In-Reply-To: <alpine.BSF.2.00.1105051908570.28646@wonkity.com> References: <alpine.BSF.2.00.1105060029040.1292@wojtek.tensor.gdynia.pl> <alpine.BSF.2.00.1105051908570.28646@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>> >> Larger postscript files are transmitted longer. >> >> I am not sure but seems it is not printer problem. Any ideas what to >> check/change in ulpt? > > It's worth trying unlpt. But if the sending time is proportional to the file already tried. The only difference is that printer doesn't know when each jobs end - so pressing "cancel" on printer by user mean nothing more will ever print after that ;) - as cancel works by ignoring data until end of job. speed is same. > size, it's probably not that. Yes it's not that. i tried making dumb 200MB postscript file and pressed cancel just after starting sending data. so printer just had to receive and ignore data - got 2.5MB/s with cat file >/dev/ulpt0 tried dd if=file of=/dev/ulpt0 bs=1m - same speed. in actual printouts it's more like 200kB/s or less. It may be printer's problem but not it's postscript processor Kyocera FS-3920DN have identical CPU and identical amount of RAM and handles printouts by LAN at 100Mbit/s speed even on complex postscript files. Do you have any idea what to check more ?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1105071528590.1476>