Bug#446643: saned is started twice with the same priority, one copy gets in the way of another c

[sasha mal]

Nobody requires the behaviour to be generalized to other scanner drivers and 
other scanner. To claim that something is a bug, it suffices to give one 
counterexample of bad behaviour, for one configuration. Here is one. (Well 
knowing that MS Windows allowed even a faster scanning, even many years ago, 
when the scanner was bought; so it's a software problem).

___
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]

Bug#446643: saned is started twice with the same priority, one copy gets in the way of another c

[Julien BLACHE]

sasha mal [EMAIL PROTECTED] wrote:

Hi,

 Nobody requires the behaviour to be generalized to other scanner
 drivers and other scanner. To claim that something is a bug, it
 suffices to give one counterexample of bad behaviour, for one
 configuration. Here is one. (Well knowing that MS Windows allowed even
 a faster scanning, even many years ago, when the scanner was bought;
 so it's a software problem).

Renicing the parent process means renicing the frontend, which means
renicing the GUI when it's a GUI, which is intolerable.

EOD.

JB.

-- 
 Julien BLACHE [EMAIL PROTECTED]  |  Debian, because code matters more 
 Debian  GNU/Linux Developer|   http://www.debian.org
 Public key available on http://www.jblache.org - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#446643: saned is started twice with the same priority, one copy gets in the way of another c

[Julien BLACHE]

sasha mal [EMAIL PROTECTED] wrote:

Hi,

 Probably the idle copy of saned doesn't give away its time slice

It's *NOT* an idle copy. It's actually the saned process you started,
the one which beams back the data to your frontend.

 when it has nothing better to do. Well, renicing is not help a bit,
 it's help a lot.

In *your* case. This can't be generalized to other backends or
scanners.

Again, this is not a bug.

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 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#446643: saned is started twice with the same priority, one copy gets in the way of another c

[sasha mal]

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]