Re: [hpoj-devel] Comments on parallel performance, questions on USB

[<pa...@rc...>]

R Horn (rj...@wo...) wrote:
> I  Parallel interface performance
> 
> A major factor in the poor performance of the new usermode parallel
> interface is the use of usermode itself.  I've been through this
> before.  You cannot get really good performance of ECP in usermode on
> Linux.  Speeds up to 30 KB/sec are easy.  With great difficulty you can
> push it to 60 KB/sec.
> 
> The 2.4 kernel (and 2.2 backports) provide the "ppdev" module for
> implementing customized protocols like 1284.4 in usermode
> applications.  It provides basic building blocks like "negotiate" via
> ioctl()s.  It provides efficient I/O transfer through the ioctl()
> modes and the read()/write() transfers.  I've built customized
> protocols using ppdev and gotten over 350KB/sec transfer rates without
> any special effort.
> 
> There may be some internal reason or Windows port reason for wanting the
> whole thing in usermode, but switching to the use of ppdev lets the
> development of the 1284.4 protocol remain usermode without losing the
> performance of kernel drivers.  It also simplifies extending support
> beyond the generic x86 parallel device world.
Hi.  Thanks for your feedback.  I will probably look into ppdev as an
alternative parallel port interface, particularly if it can give the great
performance gains that you suggest.  I decided to start out with a generic
user-mode driver which is easy to port and won't break when the kernel
changes, but I tried to leave it open to leveraging platform-specific
kernel support when available.  Of course, such optimized support would have
to be optional, so that people aren't tied to specific kernel versions the
way they were with hpoj-0.7 and before, and so there's something to fall
back on if ppdev ever breaks.

I expect there will be risk areas where ppdev may not satisfy all of my
requirements, like proper bounded ECP support, sending ECP channel
addresses, and other things that must correctly go over the wire to ensure
proper communication with the device.  However, I suppose I can try to fix
any such problems myself and submit them to Tim Waugh for inclusion into
future kernel versions/backports, similar to what I did with fixing bugs in
the USB printer.c code.

> II Architecture Documentation
> 
> When you get around to documenting the structure it would help to have
> a high level view of which parts perform what functions.  What is
> mandatory for anything to work.  What are the dependencies.  I know
> that reading the source eventually reveals this, but having a short
> paragraph on each major part would help.
Will do.  I'm planning a major reorganization of the documentation before
I release 0.8.  You might want to keep an eye on it so that when I get
around to it you can help me make sure I properly cover what you want.

> I am planning to attach a G55 to a headless Linux box that hides under
> a desk.  I have no need or desire for cute display stuff.  It will
> get in the way.  What I want is three things:
>  1) a printing daemon with reasonable network status reports.
>     Something like CUPS for instance.
The ptal-printd daemon in hpoj is designed to work with any spooler that can
print to a /dev/lpX style character device.  What sort of "network status
reports" are you looking for?

>  2) Good security.  I do not want anything to run as root.  (With
>     ppdev the entire protocol can run as a spooler ID.  I just need to
>     give that ID permission to read and write the parallel device.)
>     Anything that runs as root requires extensive code review and I do
>     not have unlimited time.
Likewise, with USB, ptal-mlcd needs write access to the /dev/ptal-mlcd
directory and read/write access to /dev/usb/lpX.

>  3) A scan -> email.  This is actually where some of the front panel
>     features could be nice.  If it lists the usernames that are
>     members of a group (e.g. scan users) then the controls on the
>     scanner could be used to select the username.  Then the scan can
>     be turned into a mail attachment and mailed to that user.  (Again
>     avoiding the need for anything to be root.)
After the recent discussion on the "scan to" feature, I started thinking
along these lines of using the Scan To button to scroll through a list of
users and e-mailing the scan to the selected user.  A similar feature could
be used for receiving faxes on models that support this functionality.

> This gives me a nice shared light duty printer/scanner/copier.  Which
> is what the G55 is for.  I'm rummaging around through code and
> emails to figure out how to put this together.
If you don't want to dedicate a whole PC as a print server, you could
consider getting an HP JetDirect print server, such as the new USB 175X,
from which the MLC/1284.4 driver was leveraged and open-sourced for this
project.

> 
> III USB
> 
> How stable is the USB these days?
I've used it quite a bit and found it to be quite stable, as long as you're
running a sufficiently recent kernel version (2.2.19 or 2.4.2) and the
underlying hardware is good.  I've run into major stability problems due to
defective motherboard USB host controllers, which I solved by switching to
a PCI USB add-in card.

> Since I have no desire for cute
> graphics, can I improve stability by leaving out some portions?  I
> understand that part of the stability problem is inherent in some
> buffering bugs internal to the G55.
What buffering bugs are you referring to?

> These seem to be related to
> query traffic, so things like eliminating the front panel emulation
> might help a lot.
You're certainly free not to run xojpanel (the LCD display app) if you don't
want it.  The core drivers and libraries, including ptal-mlcd, ptal-printd,
and libptal, are probably what you'll be most interested in.

> USB is more attractive from a performance and cabling point of view.
> In my case, the headless machine parallel port is already in use for
> something else, but it has spare USB ports.  So I'm gradually working
> along the USB path.
It's certainly worth looking into.

David