[ros-users] image transport saturating network

Tue Apr 13 04:12:58 UTC 2010

Thanks for the suggestions, but unfortunately I don't think either are 
appropriate for what I'm doing. All images are needed in as close to 
real-time as possible for things like navigation and teleoperation, and 
I already have a few other measures in place to save bandwidth when 
possible. These are really small images (320x240 px which is ~225 kB for 
the raw data, and much less compressed), so even at 10 FPS, the network 
should be able to handle the data.

-Dan

On 4/12/10 9:34 PM, Billy McCafferty wrote:
> Dan,
>
> There are a couple of integration design patterns which may assist 
> here, both described in Hohpe's "Enterprise Integration Patterns."
>
> The first is "Event Message," briefly described at 
> http://www.eaipatterns.com/EventMessage.html.  This would be 
> particularly useful if the web cam images are not needed as often as 
> they're being sent. In this scenario, the web cam node would publish 
> events describing that a new web cam image is available along with an 
> identifier of the image itself.  It would not contain the image 
> itself.  Any receiver who then wants the image itself would send a 
> request-reply message back to the web cam node, requesting the image, 
> with the afore include image identifier.  The web cam node would then 
> send the requester the image itself.  This mechanism would require the 
> web cam node to keep a (likely short) history of recent images but 
> could result in far less data going over the network.
>
> The second approach is "Claim Check," briefly described at 
> http://www.eaipatterns.com/StoreInLibrary.html.  In this scenario, the 
> web cam node would store the images in a publicly accessibly data 
> store (e.g., file system or database).  Like "Event Message," the web 
> cam node would publish a message stating that a new image is available 
> and include an identifier to the image.  But instead of the receiver 
> sending a request back to the web cam node, requesting the image, the 
> receiver would simply retrieve the image from the shared data store.
>
> Both approaches would require a little more overhead, but could 
> provide the data transfer reduction you're looking for.
>
> Hope this helps,
> Billy McCafferty
> http://www.sharprobotica.com/
>
>
> On Mon, Apr 12, 2010 at 2:03 PM, Dan Lazewatsky 
> <lazewatskyd at cse.wustl.edu <mailto:lazewatskyd at cse.wustl.edu>> wrote:
>
>     So far no luck messing with fragmentation threshold and RTS threshold.
>     They default to 2346 and 2347 respectively, and I've tried bumping
>     them
>     both (and individually) way down with no effect.
>
>     ifconfig on the robot doesn't show any errors, dropped packets or
>     overruns.
>
>     -Dan
>
>     On 4/9/10 4:49 PM, Blaise Gassend wrote:
>     > Well, you defnitely do have some long packets in there, so the
>     steps I
>     > described before could help. Can you get error counts from your
>     wireless
>     > interface?
>     >
>     > On Fri, 2010-04-09 at 16:06 -0500, Dan Lazewatsky wrote:
>     >
>     >> Here's some more:
>     >>
>     >> 16:03:05.393873 00:16:44:c6:4f:f4 (oui Unknown)>
>      00:26:08:e9:8a:bc (oui
>     >> Unknown), ethertype IPv4 (0x0800), length 1514:
>     >> toil.robots.cse.wustl.edu.53552>  192.168.1.115.49680: .
>     >> 1130888:1132336(1448) ack 1 win 108<nop,nop,timestamp 5842447
>     497191153>
>     >> 16:03:05.393892 00:26:08:e9:8a:bc (oui Unknown)>
>      00:16:44:c6:4f:f4 (oui
>     >> Unknown), ethertype IPv4 (0x0800), length 66: 192.168.1.115.49680>
>     >> toil.robots.cse.wustl.edu.53552: . ack 1133784 win 65535
>     >> <nop,nop,timestamp 497191169 5842447>
>     >> 16:03:05.394168 00:16:44:c6:4f:f4 (oui Unknown)>
>      00:26:08:e9:8a:bc (oui
>     >> Unknown), ethertype IPv4 (0x0800), length 1514:
>     >> toil.robots.cse.wustl.edu.53552>  192.168.1.115.49680: .
>     >> 1132336:1133784(1448) ack 1 win 108<nop,nop,timestamp 5842456
>     497191153>
>     >> 16:03:05.394182 00:26:08:e9:8a:bc (oui Unknown)>
>      00:16:44:c6:4f:f4 (oui
>     >> Unknown), ethertype IPv4 (0x0800), length 66: 192.168.1.115.49680>
>     >> toil.robots.cse.wustl.edu.53552: . ack 1133784 win 65535
>     >> <nop,nop,timestamp 497191169 5842456>
>     >> 16:03:05.394233 00:26:08:e9:8a:bc (oui Unknown)>
>      00:16:44:c6:4f:f4 (oui
>     >> Unknown), ethertype IPv4 (0x0800), length 66: 192.168.1.115.49680>
>     >> toil.robots.cse.wustl.edu.53552: . ack 1129440 win 65535
>     >> <nop,nop,timestamp 497191168 5842437>
>     >> 16:03:05.394353 00:26:08:e9:8a:bc (oui Unknown)>
>      00:16:44:c6:4f:f4 (oui
>     >> Unknown), ethertype IPv4 (0x0800), length 66: 192.168.1.115.62595>
>     >> toil.robots.cse.wustl.edu.ssh: . ack 752 win
>     33304<nop,nop,timestamp
>     >> 497191168 5842439>
>     >> 16:03:05.394458 00:26:08:e9:8a:bc (oui Unknown)>
>      00:16:44:c6:4f:f4 (oui
>     >> Unknown), ethertype IPv4 (0x0800), length 66: 192.168.1.115.49680>
>     >> toil.robots.cse.wustl.edu.53552: . ack 1130888 win 65535
>     >> <nop,nop,timestamp 497191168 5842447>
>     >> 16:03:05.394563 00:26:08:e9:8a:bc (oui Unknown)>
>      00:16:44:c6:4f:f4 (oui
>     >> Unknown), ethertype IPv4 (0x0800), length 66: 192.168.1.115.49680>
>     >> toil.robots.cse.wustl.edu.53552: . ack 1133784 win 65535
>     >> <nop,nop,timestamp 497191169 5842447>
>     >> 16:03:05.395265 00:26:08:e9:8a:bc (oui Unknown)>
>      00:16:44:c6:4f:f4 (oui
>     >> Unknown), ethertype IPv4 (0x0800), length 98: 192.168.1.115>
>     >> toil.robots.cse.wustl.edu <http://toil.robots.cse.wustl.edu>:
>     ICMP echo request, id 12823, seq 5952, length 64
>     >>
>     >> -Dan
>     >>
>     >> On 4/9/10 3:56 PM, Blaise Gassend wrote:
>     >>
>     >>>> The man file isn't particularly useful for figuring out how
>     what the
>     >>>> output means, so here is a few lines:
>     >>>>
>     >>>> 15:04:57.045705 IP toil.robots.cse.wustl.edu.53552>
>     >>>> 192.168.1.115.49680: . 931064:932512(1448) ack 1 win 108
>     >>>> <nop,nop,timestamp 4970372 497156321>
>     >>>> 15:04:57.045710 IP 192.168.1.115.49680>
>     >>>> toil.robots.cse.wustl.edu.53552: . ack 931064 win 33304
>     >>>> <nop,nop,timestamp 497156335 4970352>
>     >>>> 15:04:57.045711 IP 192.168.1.1.http>   192.168.1.115.49706: P
>     1:351(350)
>     >>>> ack 597 win 6556<nop,nop,timestamp 172066583 497156334>
>     >>>> 15:04:57.045777 IP 192.168.1.115.49680>
>     >>>> toil.robots.cse.wustl.edu.53552: . ack 933960 win 33304
>     >>>> <nop,nop,timestamp 497156335 4970372>
>     >>>> 15:04:57.045809 IP 192.168.1.115.49706>   192.168.1.1.http: .
>     ack 351 win
>     >>>> 33129<nop,nop,timestamp 497156335 172066583>
>     >>>>
>     >>>>
>     >>>>> Have you tried using compressed image transports?
>     >>>>>
>     >>>>>
>     >>> Strange, I have never seen tcpdump not print packet lengths.
>     Try adding
>     >>> -e.
>     >>>
>     >>> _______________________________________________
>     >>> ros-users mailing list
>     >>> ros-users at code.ros.org <mailto:ros-users at code.ros.org>
>     >>> https://code.ros.org/mailman/listinfo/ros-users
>     >>>
>     >>>
>     >> _______________________________________________
>     >> ros-users mailing list
>     >> ros-users at code.ros.org <mailto:ros-users at code.ros.org>
>     >> https://code.ros.org/mailman/listinfo/ros-users
>     >>
>     >
>     > _______________________________________________
>     > ros-users mailing list
>     > ros-users at code.ros.org <mailto:ros-users at code.ros.org>
>     > https://code.ros.org/mailman/listinfo/ros-users
>     >
>     _______________________________________________
>     ros-users mailing list
>     ros-users at code.ros.org <mailto:ros-users at code.ros.org>
>     https://code.ros.org/mailman/listinfo/ros-users
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>    
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100412/1f0ccc99/attachment-0003.html>