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 > > 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 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 > >> > >> 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 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 > >> > >> 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 > > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users >