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

[Mathew D. Watson]

Derek Simkowiak wrote:
> /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.
> 

OK. That would be an improvement, as at least the images would not be 
corrupted. My user application could still get interrupted.

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

I too think the computer <-> camera interface is where it is at, but the 
question is why?/what?/how? In another posting that just arrived in my 
inbox, Chuck Wolber suspects the code may be looking for a resource that 
is not readily available to regular users. Both you and Chuck feel the 
scheduler is probably not the problem.

> One GigE camera vendor that we know of  ;) requires root 
> permission to set the network card into "Jumbo frames" mode;

I set the MTU to 8000 near the start of this adventure.

>    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):

My vendor ;) supports multicasting, but I recall reading that the camera 
needs to be run by root to use it. Honestly, I don't even know what 
multicasting is. I'll do some homework now that you have mentioned it. 
It might be useful.

Thanks!

Mat