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 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 > >> 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 > >> > >> 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 > >> 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 > >> > >> 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 > >> > >> 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 >> 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 > >> > >> 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 > >> > >> 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 > >>>> > >>>> 15:04:57.045710 IP 192.168.1.115.49680> > >>>> toil.robots.cse.wustl.edu.53552: . ack 931064 win 33304 > >>>> > >>>> 15:04:57.045711 IP 192.168.1.1.http> 192.168.1.115.49706: P > 1:351(350) > >>>> ack 597 win 6556 > >>>> 15:04:57.045777 IP 192.168.1.115.49680> > >>>> toil.robots.cse.wustl.edu.53552: . ack 933960 win 33304 > >>>> > >>>> 15:04:57.045809 IP 192.168.1.115.49706> 192.168.1.1.http: . ack 351 > win > >>>> 33129 > >>>> > >>>> > >>>>> 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@code.ros.org > >>> https://code.ros.org/mailman/listinfo/ros-users > >>> > >>> > >> _______________________________________________ > >> ros-users mailing list > >> ros-users@code.ros.org > >> https://code.ros.org/mailman/listinfo/ros-users > >> > > > > _______________________________________________ > > ros-users mailing list > > ros-users@code.ros.org > > https://code.ros.org/mailman/listinfo/ros-users > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >