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

[Derek Simkowiak]

/Technically speaking, what might the vendor do?/

    They could implement their API as kernel-space device driver, 
instead of a user-space application.  Then any user could access the 
"hardware" directly, perhaps using a device file like /dev/the_camera or 
similar.  This is how Video4Linux works: it provides a /dev/video.

    But considering this is a GigE camera, that's probably not the way 
to go.  It would be a little strange for them to write a kernel module 
to talk to the GigE network card, considering that you already have a 
device driver for your GigE network card (i.e., your standard eth0 
device driver). 

    I am skeptical about the vendor's "RTOS" response.  It would really 
surprise me if the bottleneck in reading the GigE data turned out to be 
the kernel's scheduler.

    Instead, I'd guess that the bottleneck is in the networking to the 
GigE camera.  One GigE camera vendor that we know of  ;) requires root 
permission to set the network card into "Jumbo frames" mode; i.e., an 
extremely large MTU, with a command like:

ifconfig eth0 mtu 8228

    This command requires root privileges.  Perhaps your vendor's 
software application does this automagically, when run as the user 
root?  (Note that not all GigE network cards support Jumbo frames; the 
GigE on my laptop does not, for example.)

    The aforementioned vendor also supports multicasting; so perhaps 
their software app is automagically adding the multicast route for you, 
calling a command like this behind the scenes (when run as root):

route add -net 224.0.0.0 netmask 240.0.0.0 eth0

    If their software app calls these commands, then when it is run as a 
regular user, it would not be able to enable Jumbo frames (or manage the 
routing table for multicasting).  As a simple test, try running the 
above commands as root first, and then launch their software app as a 
non-root user.  See if the performance is better.  (But that is not a 
definitive test; their app software may not even try to use multicasting 
if it detects it's not being run as user "root"...)

    If it's not the GigE network settings, you'll need to dig to find 
where the bottleneck is.

    In general, I agree that an application should not run as the user 
root.  But sometimes it's unavoidable; network servers (like Apache, 
Samba, OpenSSH) must be launched as root to bind to low ports (below 
1024) and to become regular users for shell logins and filesystem access.


--Derek

Mathew D. Watson wrote:
> I am struggling with a gigabit ethernet machine vision camera that 
> randomly sends corrupted images when I run my app as a regular user 
> (even when I renice it to -20 and set the frame rate really low, like 
> 5 frames per second). When run by root at 30 fps with no renicing, the 
> camera almost never sends corrupted images. The problem is, I _really_ 
> think it's a bad idea to run user apps as root. I said as much to the 
> vendor and threw in that I consider requiring to run as root an API 
> defect.  I received the following reply.
>
> "
> 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.
> "
>
> To my eye "it is beyond our control or influence" is not true, but I 
> am not an expert (I just know enough to be dangerous).  Technically 
> speaking, what might the vendor do? (short of using something like 
> rtlinux or rtai)
>
> Mat
>