Bug#446643: sane-utils: alleged performance problems with saned
Hello, this bug was closed and archived in 2010. Then in 2011 this bug was reopened and unarchived without any comments. I close this bug. Thank you for spending your time. If this bug still occurs please feel free to file a new bug. CU Jörg -- pgp Fingerprint: 7D13 3C60 0A10 DBE1 51F8 EBCB 422B 44B0 BE58 1B6E pgp Key: BE581B6E CAcert Key S/N: 0E:D4:56 Jörg Frings-Fürst D-54526 Niederkail Threema-ID: SYR8SJXB IRC: j_...@freenode.net, j_...@oftc.net signature.asc Description: This is a digitally signed message part.
Bug#446643:
I know what you propose won't work. Ok. If solutions A and B don't work this doesn't mean there exists no third solution. It's not my job to propose a solution anyway, it's the job of a SANE-programmer. My job is the telling the discrepancy between the wanted and observed behaviour. You are unwilling to help fixing this discrepancy. So it's a waste of time reading the code and proposing other solutions to you. Again, if you don't want to fix the bug yourself, leave it to people who have more resources than you. Closing eyes on a flawed design doesn't repair it. ___ 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:
sasha mal [EMAIL PROTECTED] wrote: What you are saying is that it costs too much to fix the slowdown and my solutions are not good because of some reasons I have no idea of. What part of what you propose is going to induce horrible side effects for the frontends and it's not portable accross all the platforms supported by SANE don't you understand ? However, having or not having time resourses on your side is absolutely irrelevant to the question whether something is a bug or not. Again, what part of if this can be fixed it'll probably require a massive amount of work and redesign of the current SANE architecture, and it's definitely not worth it don't you understand ? Don't tell me that you want an A4 page to be scanned in 20 minutes if a slightly You can't expect a parport scanner to be fast, because the parport is dogslow to begin with anyway, and these scanners are nothing more than gross hacks. You see, I would even spend a couple hours on hacking the code if I (1) could get support in terms of explanation and (2) knew exactly the time to spend on it, but (3) your minunderstanding made this definitely impossible. Read the code, read the SANE standard, identify and get to know all the SANE frontends, identify all the platforms supported by SANE, read up on your proposed solutions and get a clue all by yourself. I know what you propose won't work, I know it's not worth the effort, ergo I'm not spending any more time on that. 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: Info received (Bug#446643: saned is started twice with the same priority, one copy g
Renicing saned doesn't renice xsane automatically. Renicing one process influences only the future children. So your note is irrelevant. Look at setpriority(...) and/or sched_yield(). Good example for any of the saned copies: if(number_of_read_bytes==0) sched_yield(); ___ 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: Info received (Bug#446643: saned is started twice with the same priority, one copy g
sasha mal [EMAIL PROTECTED] wrote: Hi, Renicing saned doesn't renice xsane automatically. Renicing one process influences only the future children. So your note is irrelevant. Because in this case, the frontend, as far as the mustek_pp backend is concerned, is saned itself and not xsane (which, in this case, uses the net backend). What you are suggesting just isn't applicable. 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: Info received (Bug#446643: saned is started twice with the same priority, one copy g
If you suppose that my suggestion is not applicable, it's not a reason to close the bug. 100% slowdown is a bug. What solutions are applicable and what are not applicable is a different question. ___ 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:
What you are saying is that it costs too much to fix the slowdown and my solutions are not good because of some reasons I have no idea of. This is your explanation for your unwillingness to fix it. Well, I have to accept that. However, having or not having time resourses on your side is absolutely irrelevant to the question whether something is a bug or not. A bug is an unwanted behaviour of the program. Don't tell me that you want an A4 page to be scanned in 20 minutes if a slightly changed piece of software is able to do it in less than 10 while still having resourses left. You way call it a whish that data should be transferred faster, if the word bug disturbes you. You have to accept this too. Abstractly speaking, the task is well-defined. You know the total data volume (which can be computed from the paper size and resolution) and you know the physical transfer speed (parallel port + kernel driver) or can compute this on average. So a 2Ghz machine should be able to get this data and store it without wasting the user's time. Debian+saned+xsane fails to do it. You finally had to admit that this can't be repaired easily. This is a hint to a disastrous design of some piece of software. We are not talking about a whish or a simple bug, it's much more, it's a failed design. I have no doubt that you are bright enough to understand that. You see, I would even spend a couple hours on hacking the code if I (1) could get support in terms of explanation and (2) knew exactly the time to spend on it, but (3) your minunderstanding made this definitely impossible. ___ 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
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
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
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 copy
Package: xsane Version: 0.99+0.991-2 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. However, if during a scan the priority of the former copy of saned (that starts together with xsane and terminates at its end) is manually reniced to a worse value (i.e. +19), scanning gets a lot faster. This suggests that the former copy of saned is not really useful. The next time scanning is started (e.g. for the next sheet of paper), the priority of the new copy of saned is automatically niced to the priority of the copy already in memory (which is +19) for an unknown reason, which makes the scanning even slower than before. To get scanning faster again, the user has to set it manually to a better value (e.g. to 0). I expect that either only one copy of saned is in the memory or, if two are really needed (for what reason I cannot understand), then former one should start with a worse priority and the latter one with a better priority. I'm using the mustek_pp driver and the scanner called MD 9890. The system is a debian etch with a few newer packages. Other configuration data: $ aptitude show sane-utils | grep Version Version: 1.0.18-5 $ aptitude show libsane | grep Version Version: 1.0.18-5 $ aptitude show libc6 | grep Version Version: 2.5-7 $ grep sane /etc/services sane-port 6566/tcpsane saned # SANE network scanner daemon $ grep sane /etc/inetd.conf sane-port stream tcp nowait saned.saned /usr/sbin/saned saned $ grep sane /etc/xin* grep: /etc/xin*: No such file or directory $ uname -a Linux mpino2412 2.6.18-5-686 #1 SMP Sun Aug 12 21:57:02 UTC 2007 i686 GNU/Linux $ cat /etc/sane.d/mustek_pp.conf ... scanner mustek * cis1200 Hoping to see a soon fix Best regards Sasha ___ 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
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]
