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@cse.wustl.edu <mailto:lazewatskyd@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@code.ros.org <mailto:ros-users@code.ros.org>
> >>> https://code.ros.org/mailman/listinfo/ros-users
> >>>
> >>>
> >> _______________________________________________
> >> ros-users mailing list
> >> ros-users@code.ros.org <mailto:ros-users@code.ros.org>
> >> https://code.ros.org/mailman/listinfo/ros-users
> >>
> >
> > _______________________________________________
> > ros-users mailing list
> > ros-users@code.ros.org <mailto:ros-users@code.ros.org>
> > https://code.ros.org/mailman/listinfo/ros-users
> >
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org <mailto: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
>
(text/plain)