Hi all,

For the first time, I installed a parport scanner under Linux, and it
is incredibly sloooooowww! Now I have read kernel docs and sane docs
for a while, but it seems I am either missing the decisive point, or
scanning with Linux is really that slow... Could anyone here shed some
light on this? I have googled for "linux scanner parallel EPP" and
things like that, but did not find much useful.

What do we have?
- Pentium 120 MHz, 96 MB RAM, 128 MB swap
- Linux 2.2.19 or 2.4.10
- Scanner Mustek 600 III EP plus
- sane 1.0.9 with mustek_pp backend

Now it takes about a minute for a preview, and about three minutes to
scan an A4 page at 300 dpi. This seems pretty slow to me - or am I
expecting too much?

The BIOS parport setting is EPP (I also tried ECP/EPP), and dmesg
says:

...
parport0: PC-style at 0x378 [PCSPP,TRISTATE,EPP]
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
parport0: cpp_daisy: aa5500ff(38)
parport0: assign_addrs: aa5500ff(38)
lp0: using parport0 (polling).
...

Does this mean EPP is really used? Would be nice... But if not it
would explain that it is slow. Is there a way to explicitly tell the
kernel parport driver to use EPP? I did not find anything in the boot
parameter docs.

I have switched off the "niceload" option in the sane config. So the
CPU gets nicely loaded, but scanning is still very slow. The CPU load
actually is "full", and BTW so it is for the cat process that runs
when I print. Why does parport stuff load the CPU so heavily? The data
rate is not really high enough to justify this. Or is it the
inefficiency of the polling? I am not (yet) a parport expert...

Another strange thing is that whenever I start xscanimage, it will
modprobe for usbcore for quite a while, before it finally gives up and
starts. But I have configured the mustek_pp - so it should not worry
about USB at all.

Scanning does not seem to be one of the strong sides of Linux...

I would appreciate any comments / experience reports related to this.

Cheers,

Helmut.

+----------------+
| Helmut Walle   |
| [EMAIL PROTECTED] |
+----------------+


Reply via email to