reopen 446643
Probably the "idle" copy of "saned" doesn't give away its time slice when it
has nothing better to do. Well, renicing is not "help a bit", it's "help a lot".
The same scanning task was performed twice (computer has a 2GHz processor).
Without renicing : 20 minutes 17 seconds.
Giving the worst priority 19 to the former "saned" copy: 10 minutes 40 seconds.
Working in parallel is unproblematic in both cases.
Sorry, but I consider a slowdown of 100% a severe bug. Would you mind reopening
it (in a package for mustek_pp) please?
Since the driver cannot transfer data fast enough, a faster scanner (for the
same driver) doesn't repair the slowdown. You see, even changing to a faster
computer just shifts the problem to larger resolutions.
What concerns the cases that you describe as "the other way round", there are
certainly software solutions to determine which of two processes is idly
waiting for the input and should give away its time slice. In the laziest case
one can imagine a new mustek_pp configuration option which sets the priorities.
Thanks a lot
Best regards
Sasha Mal
--- On Sun 10/14, Julien BLACHE < [EMAIL PROTECTED] > wrote:
From: Julien BLACHE [mailto: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Date: Sun, 14 Oct 2007 19:25:26 +0200
Subject: Re: Bug#446643: saned is started twice with the same priority, one
copy gets in the way of another copy
"sasha mal"<[EMAIL PROTECTED]> wrote:Hi,> I turned on the local scanner, put
some sheet of paper into in,> started xsane. Looked with "ps aux" on the
process list and saw saned> there. Then I started acquring a preview of a A4
sheet of> paper. Looking of the list of processes with "top", I noticed two>
copies of "saned", both running at the same priority (NI 0). After the> preview
was acquired, I discovered that one "saned" copy terminated.>> Scanning was
very slow.> I'm using the mustek_pp driver and the scanner called "MD 9890".
TheThe mustek_pp forks a reader process when scanning, so having 2
sanedprocesses running while scanning is perfectly fine and expected.Your
scanner is a parallel port scanner, so you have to expect it tobe slow ...By
renicing the parent saned process you're slightly modifying thescheduling
priority and the reader process gets more CPU time whichcan help a bit, as
you've seen, but it could as well have degradedperformance.No bug here, sorry,
you
need a faster scanner.JB.-- Julien BLACHE - Debian & GNU/Linux Developer -
<[EMAIL PROTECTED]> Public key available on <http://www.jblache.org> - KeyID:
F5D6 5169 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
