[ros-users] image transport saturating network

Tue Apr 13 02:34:05 UTC 2010

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/
<http://www.sharprobotica.com/>

On Mon, Apr 12, 2010 at 2:03 PM, Dan Lazewatsky
<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: 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
> >>> 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
> >>
> >
> > _______________________________________________
> > ros-users mailing list
> > 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/f31d53e2/attachment-0003.html>