[SLL] technically speaking, what might the vendor do?

[Chuck Wolber]

On Tue, 2 Dec 2008, Mathew D. Watson wrote:

[...]

> The camera app (2% cpu) and Xorg (23% cpu) are the only running 
> processes shown on the system monitor.

I'm not sure what the system monitor is, but I can most assuredly say that 
it's not giving you the full picture. Open a terminal and run the "top" 
command. 



> There is a large performance difference between running the camera app 
> as root and running the app at 30 fsp and as a regular user, at a -20 
> nice value, at 10 fps. The fraction of corrupted images drops by 
> dramatically (a factor of a 1000 IIRC) when running as root.

I don't deny that what you're observing is real. It sounds strange though. 
One thing you might consider is running an strace on the app when it's 
running as root and non-root. I suspect that it's trying to access a 
protected resource and, when running as non-root, it is failing. If that's 
the case, it probably is not affecting the operation of the app and should 
be removed or handled properly.


> That doesn't square with your claim, and, therefore, I suspect there is 
> more to the story than nice and priorities. The vendor mentioned user 
> thread interruptions, not priority. Is that significant?

That does not make sense on several levels. There is no user thread 
interruption going on unless the app is doing that on its own. Each 
non-kernel process gets time slices as determined by the scheduler. It 
does not matter what user you are, everyone gets time slices based on the 
same rules.

I think there's someone buried deep in the vendor's company who can give 
you a coherent answer. This problem probably, at one time, trickeled down 
to them and h/she gave a coherent answer. It has probably been changed 
several times since then. Since most people give you a "deer in the 
headlights" stare when you say things like "user thread interruptions", no 
one bothered to question it.

In other words, I call BS. If I were you, I'd go back to them and demand a 
better explanation, preferably from someone more qualified to give it. If 
you don't feel qualified to defend your position, there are several people 
(me included) on this list who will gladly do it if you cover their hourly 
consulting rate.



> I am hoping someone can propose a model for what's going on that is 
> consistent with observations. My real motivation is knowing whether or 
> not this is a fundamental Linux limitation, or if it's the vendor's API.  
> Either way I would like to understand what I am dealing with.

What's happening is that a resource is not available when it should be. 
There are many ways to fix this in the vendors app. The other way is to 
install a real time kernel. It appears from other posts, that someone has 
given an excellent explanation of how to do just that.


> > My instinct tells me that the hardware they tested the app on was much 
> > faster than your hardware.
> 
> My hardware is equivalent to what the vendor recommends. 

That's hard to believe. Not to pick nits or anything, but I'm sure I could 
find a difference if I put your hardware next to theirs. One of the most 
ambiguous things this industry has to offer is "minimum hardware 
standards".


> The vendor said several times that the issue is Linux (vs. Windows) and 
> not hardware.

And if you believe that, I have a bridge in New York to sell you :) Such a 
statement from them makes me wonder if they somehow used Win32 code on the 
Linux system with WINE, instead of correctly porting the app to the 
POSIX/Linux environment.


> > They probably have a systemic problem in the software that's being 
> > duct taped over with fast hardware. [...]
> 
> Not masked over by fast hardware, rather "solved" by being root if you 
> run linux. They don't seem to see have this problem with Windows.

IIRC you mentioned that you still have the problem (to a much lesser 
extent) when running as root.



> > The first step towards solving the problem is to find out if it is CPU 
> > or IO bound.
> 
> Without camera running:
> matw at catalina:~$ vmstat
> procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
>  0  0      0 680868 120812 553192    0    0     3     1   59   18  1  0 99  0

Did you run vmstat for a bit? Never trust the first couple of responses 
from vmstat.



> With camera running:
> matw at catalina:~$ vmstat
> procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
>  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
>  1  0      0 657340 120904 553620    0    0     3     1   59   21  1  0 99  0

Make sure you run vmstat for a while and try to get a capture at the same 
time an image gets corrupted. What you have above does not tell me much.



> Ifconfig reports no drops, errors, or overruns.

I wouldn't expect to see any.


> The system seems like it is not even "breaking a sweat."

And it likely never will. You need to get a vmstat capture before, during 
and after an image gets corrupted. Preferably you'd get a capture that 
includes a few good image captures, a bad one and then a few good ones.


> > Some other things you should consider is to max out the RAM on the 
> > machine and update the kernel to the very latest release (2.6.27.7).
> 
> Installing a new kernel is beyond my skill level. I do update whenever 
> ubuntu tells me a new kernel is available. Right now it is 2.6.24-22.

Understood. But it sounds like you are getting into pretty technical 
areas. It might be a good idea to learn how. I offered some free books on 
the list a while back, a few of which would teach you exactly what you 
need to know. You're welcome to them, since no one else made an offer.

..Chuck..


-- 
http://www.quantumlinux.com                 | "An idea does not gain
 Quantum Linux Laboratories, LLC.           |  truth as it gains
 ACCELERATING Business with Open Technology |  followers." Amanda Bloom