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

[Mathew D. Watson]

Chuck Wolber wrote:
> You did not say what the machine was *ALSO* used for. Nor did you describe 
> where the machine sits in relation to the Internet.

Good points; let me fill in some blanks. The machine is a 2+GHz Phenom 
box with 2GB of RAM. The motherboard's ethernet interface attaches to 
the office network. There is also an Intel 1000PT ethernet adapter that 
connects directly to the camera. Nothing else is attached to that 
interface. This interface has been configured for jumbo packets (MTU 
8000, per vendor's recommendation).  The OS is ubuntu 8.04 running the 
gnome desktop. The camera app (2% cpu) and Xorg (23% cpu) are the only 
running processes shown on the system monitor.

> *IF* the machine is a dedicated box for this application only *AND* it is 
> not directly connected to the Internet or any other unsecured network, 
> *THEN* there's nothing wrong with running the app as root.
> 
> Failing the above, there are still good reasons to run an app as root. I 
> simply do not have the time to outline them all... Suffice to say, it is 
> not an *EITHER*/*OR* proposition. It requires some critical thinking to 
> decide if you are at risk or not.
 >
> However, as a *GENERAL* rule, the safest policy is to run each app as a 
> different non-root user within its own chroot jail. Keep reading though...

I may well be forced to run as root, but I want to explore user-space 
options first. Going down the root path "requires some critical 
thinking" at least.

>> " Machine Vision applications and processes are highly demanding on the 
>> host OS. Since Linux is a non RTOS, we need to run the application as a 
>> super user to prevent other (non [Vendor] API) threads from interrupting 
>> the process.  This is not a "[Vendor] API defect", it is beyond our 
>> control or influence. "
> 
[...]
> As far as what your vendor is saying about running as root allowing you to 
> run at a higher priority, that is just not the case. As the root user, you 
> can renice anything to the highest priority (-20), even processes *NOT* 
> running as root. In other words, it does not matter which user the app 
> runs as, it still gets the same priority as root owned processes. The only 
> thing you get running as root is access, not extra performance.

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.

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?

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.

> As for what they would 
> do to fix it, it is hard to tell without knowing the app better.

More details follow.

 > 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. The vendor said 
several times that the issue is Linux (vs. Windows) and not hardware.

> 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.

> 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

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

Ifconfig reports no drops, errors, or overruns.

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

The app does not use the disk. The c++ app gets images from the camera 
(1600 x 1200 pixels x 8 bits per pixel)  and checks to see if the image 
data is corrupted (there is a flag provided with the image). Sometimes I 
  pass the data on to a Java application (via SWIG) that displays the 
images. Displaying the image has no effect on the corruption. Eventually 
the app will provide real time image analysis, but for now I throw the 
data away or simply display it.

> 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.

Thanks!

Mat