[OSPL-Dev] Sending large amounts of data through WiFi

[Jean-Louis THEKEKARA]

Hi,

I'm encountering difficulties to send some big sequence<octet> through Wifi.

I have a node A which publish every 2 sec a topic Foo containing a sequence<octet> of 1MB

My node B has a waitset triggering on every new sample from topic Foo.

If I use a ethernet wired link between A and B, I have no problem, my node B get every messages.

If I use a wireless link between them (for example A is a the AP and B is the station), i can send sequences of 0 to 100kB only. Between 100kB and 200kB, my node B starts to lose samples and after 200kB my node loses every samples sent from node A. With Tracing enabled on the node B, I see that a number is growing when it starts to lose samples : 

Receive        (2) Total number of defragmentation buffers for channel "Channels/Channel[@name='BestEffort']" has climbed to 80

Configuration  (1) Retrieved attribute General/Reconnection[@allowed], using value TRUE

Configuration  (1) Retrieved attribute General/Reconnection[@allowed], using value TRUE

[....]

Receive        (2) Total number of defragmentation buffers for channel "Channels/Channel[@name='BestEffort']" has climbed to 160

[....]

Receive        (2) Total number of defragmentation buffers for channel "Channels/Channel[@name='BestEffort']" has climbed to 320

Finally, I also get this kind of message in ospl-info.log (either node A or node B) :

Report      : WARNING

Date        : Fri Apr 23 13:38:55 2010

Description : No heartbeats received from Node 0xf02f304 (address 192.168.0.2)

Node        : nodeA

Process     : networking (11696)

Thread      : Channels/Channel[@name='Reliable'] b778fb90

Internals   : V4.3/networking: reliable protocol/nw_plugSendChannel.c/2236/0/777045250

========================================================================================

Report      : WARNING

Date        : Fri Apr 23 13:38:55 2010

Description : Node 0xf02f304 (address 192.168.0.2) not responding or no heartbeats received, removing it from the reliable protocol

Node        : nodeA

Process     : networking (11696)

Thread      : Channels/Channel[@name='Reliable'] b778fb90

Internals   : V4.3/networking: reliable protocol/nw_plugSendChannel.c/1542/0/777137286

sometimes, I even got this in addition on node B side, which forces me to restart ospl :

========================================================================================

Report      : INFO

Date        : Fri Apr 23 13:40:06 2010

Description : Service 'networking' DIED -> skip

Node        : nodeB

Process     : 6297

Thread      : ServiceManager 7fea2f5e6710

Internals   : V4.3/OpenSplice domain service/serviceMonitor.c/91/0/276425037

======================================================================================== 

it seems that when the network starts to be a bit loaded, even the heartbeats from A to B and B to A are lost.

- I have tried to use a RELIABLE QoS instead of BEST_EFFORT "just to see", and there is no differences.

- I have tuned a bit the default config file ospl.xml  (http://pastebin.org/170117), increasing things like fragmentSize or trying to not use broadcast messaging ...

- I have also tried various hardwares (differents AP and Bridge Wifi card), it's more or less the same thing.

- I'm using a OpenSplice V4.3 rebuilded in order to correct bugs 19 and 32.

Did anyone succeed in sending large sequences of data over Wifi there ? I would be grateful if anyone can give me a feedback or clues.

Thanks,

Jean-Louis Thekekara.

[Emanuel Varga]

Hi Jean,

Sorry i can't test this now on a wi-fi conection but this could help
with your problem. In the configuration file, you can limit the size
of the burst, ThrottleLimit is used when some nodes can't keep up with
the speed of the sending node so try defining a channel like this and
see if this solved your problem. You can do the same to define a
reliable channel, just set the reliable to true in the configuration
below.

<Channel default="true" enabled="true" name="lowpri_BE"
priority="25" reliable="false">
<PortNr>53320</PortNr>
<Sending>
<MaxRetries>216000</MaxRetries>
<RecoveryFactor>20</RecoveryFactor>
<QueueSize>72000</QueueSize>
<MaxBurstSize>16384</MaxBurstSize>
<Scheduling>
<Priority>25</Priority>
<Class>Realtime</Class>
</Scheduling>
<ThrottleLimit>8192</ThrottleLimit>
</Sending>
<Resolution>20</Resolution>
<Receiving>
<Scheduling>
<Priority>26</Priority>
<Class>Realtime</Class>
</Scheduling>
</Receiving>
</Channel>

Thank you,
Emanuel Varga

_______________________________________________
OpenSplice DDS Developer Mailing List
Deve...@opensplice.org
Subscribe / Unsubscribe http://www.opensplice.org/mailman/listinfo/developer

--
You received this message because you are subscribed to the Google Groups "OpenSplice DDS Community Edition Developers" group.
To post to this group, send email to ospl-de...@googlegroups.com.
To unsubscribe from this group, send email to ospl-develope...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/ospl-developer?hl=en.

[Jean-Louis THEKEKARA]

Thank you Emanuel for your answer. I added a ThrottleLimit parameter to my config files, but unfortunately it didn't improve the process.

However, I found out that the problem is located on the sending side. If the data are published through a laptop integrated wifi card (like Intel Pro/Wireless 3945ABG), everything is fine. If the data are published through kinds of semi-industrial wifi station (http://www.ubnt.com/nanostation), the receiving node starts to lose samples which are over 200kB. My issue is probably related to a misconfiguration of the hardware.

Regards,

Jean-Louis.

[Jean-Louis THEKEKARA]

I discover that it's a fragmentation packets issue. A fragmentation treshold from 256 to 2436 bytes can be set on my wifi device (emitter side). 

If I decrease the value, my receiving node "lost samples threshold" decreases as well. The best result I can obtain is still 200kB sample ...

I suspect something like a conflict between DDS UDP fragmentation parameter on IP layer and Wifi fragmentation size.

Regards,

Jean-Louis.