Menu
▾
▴
hpoj-devel
|
From: <rj...@wo...> - 2001-05-06 18:08:54
|
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.
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.
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.
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.
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.)
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.
III USB
How stable is the USB these days? 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. These seem to be related to
query traffic, so things like eliminating the front panel emulation
might help a lot.
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.
At the moment the G55 is just a copier, attached to nothing, since its
previous Windows support host got moved.
R Horn
|
|
From: <pa...@rc...> - 2001-05-07 10:05:54
|
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 |
|
From: Tim W. <tw...@re...> - 2001-05-07 10:30:46
|
On Mon, May 07, 2001 at 03:04:07AM -0700, David Paschal wrote: > 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. Indeed; it doesn't do BECP yet, although ECP channels should work. Tim. */ |
|
From: Joe P. <joe...@sn...> - 2001-05-07 20:10:23
|
On Sunday 06 May 2001 02:08 pm, rj...@wo... wrote: <...> > 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. I don't think anyone has claimed that the xojpanel app is particularly important in itself. You never *have to* run it. You can avoid building it by specifying '--without-qt' at configure time. If you are instead referring to a future "xhpcontrol" application, do you mean that you would need a command-line version? My opinion of GUI applications in general is that they should look nice, and there should be more of them, particularly if we want to attract the average desktop user to "free" operating systems. -- Joe |
|
From: <rj...@wo...> - 2001-05-07 22:08:32
|
On 7 May, Joe Piolunek wrote: > On Sunday 06 May 2001 02:08 pm, rj...@wo... wrote: > > <...> >> 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. > > > I don't think anyone has claimed that the xojpanel app is particularly > important in itself. You never *have to* run it. You can avoid building it by > specifying '--without-qt' at configure time. > I didn't mean to imply that someone claimed it was required. It was that you need to read the code to figure out whether and when it is required. > If you are instead referring to a future "xhpcontrol" application, do you > mean that you would need a command-line version? > In my opinion, all applications should have a command-line version if possible. The wonders of scripting are manyfold, and there are always times when setting up a GUI is inconvenient at best. When dealing with remote support it is often difficult to get more than an terminal emulation session over to their system. In one case that I know, the decision to support only an HTML GUI access for service resulted in the requirement for a site visit. The site visit would cost as much as the equipment. So the "broken" (actually misconfigured) equipment was returned for a full refund as inherently defective. > My opinion of GUI applications in general is that they should look nice, and > there should be more of them, particularly if we want to attract the average > desktop user to "free" operating systems. > Yes indeed. There are also times where cute graphics are appropriate. Absence of a friendly GUI capability is just as big a mistake as absence of a command-line version. They are both needed, just at different times for different reasons. R Horn |
|
From: Tim W. <tw...@re...> - 2001-06-04 09:34:56
|
On Sun, May 06, 2001 at 02:08:40PM -0400, rj...@wo... wrote: > 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. FWIW, libieee1284 is an attempt to make ppdev easy to use, as well as falling back to other methods if ppdev isn't available. Tim. */ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X