Skip site navigation (1)Skip section navigation (2)
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: <http://docs.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1105071528590.1476>