IGMP problem with PXI under LabVIEW 2015SP1

[joergh]

Hello,

we are using UDP multicast to transmit measurement data to a group of PCs and one PXI realtime system (LabVIEW RT 2015SP1). This works fine when we turn off the ethernet switch's IGMP snooping feature. When we turn it on, the PXI receives data for about 5 minutes and then no more data is received until we reboot the PXI. Our conclusion is that the IGMP messages do not get re-sent by the PharLap TCP/IP stack during this 5 minute timeout period. All other PCs (Windows 7, Windows 10 and Linux) work indefinitely. Turning off IGMP is not an option, as the multicast traffic affects some connected embedded systems negatively (e.g. a DCF77 realtime clock with NTP time server and a printer), they simply 'give up' completely after random time periods and do not react any more. When IGMP is on, they too work indefinitely.

Is there any option in the PharLap OS (or whereever) to force re-sending of the IGMP messages?

Best regards,

    Jörg

[JacquesS]

Hi Jörg,

this might be due to the fact that the Real-Time system does not respond to the IGMP membership query. The RealTime OS does send out a subscription message on startup. This results in the application working for a short time after startup, but without the system responding to the membership query, the switch ceases to forward messages and the application stops receiving data and thus is no longer working as part of the system.
- What PXI system are you using? It could be that IGMP is not supported on that specific target with Phar Lap.

- Are you using IGMPv2 or IGMPv3? Possibly only IGMPv2 is supported.

- Could you track the queries sent out by the switch (using Wireshark e.g.)? Are maybe only group specific queries sent out, for groups the RT system is not part of?

Best regards,

[joergh]

Hello,

we are using an PXIe-8135 controller in an PXIe-1085 under LabVIEW RT 2015 SP1 f5.

The switch uses IGMP v3 AFAIK, but I need to confirm this. As the system is on the customer's premises, I can do that only next week.

Thank you,

   Jörg

[JacquesS]

Hi Jörg,

have you managed to get more information about the system yet?

Regards,

[joergh]

Hi again,

yes, the switch uses IGMPv3, and there are no further configuration options. There is only one multicast group.

I wasn't able to trace the IGMP messages for the PXI, because I could not get the port mirroring to work (and did not have enough time...).

One question out of curiosity: would periodically opening and closing another port for the same group on the PXI help? Unfortunately I cannot test this, as I don't have another PXI here.

In the meantime, we are using 2 cascaded switches: one cheap switch with no IGMP support linked to

another one with full IGMP enabled. All multicast nodes are plugged into the first switch, so we can connect the non-multicast systems to the second switch and they still do not get overrun by traffic. But this solution is far less than optimal.

[Bob_Schor]

You don't say what data rates you are using, but if you are not "straining the system", and if the "problem" is the UDP communication with the PXI, you could consider setting up two TCP/IP streams -- UDP multicast to everyone who is "listening", and a TCP (or, even easier to implement, a Network Stream) to the PXI.  We've used multiple Network Streams to communicate with a PXI (LabVIEW RT 2012 and 2014), using two Streams to set up a bidirectional Message Handler (PC sends Messages to PXI, PXI sends Messages to PC), an Analog Data Stream (16-24 channels at 1KHz), and an "Event" Stream (point-in-time data, such as Digital I/O state changes, Start of Trial times, etc.).

Bob Schor

[joergh]

Well, the data rates vary but we need to send at 1KHz rate, usually 1 or two datagrams per system for 5 systems in total (this is very test configuration dependent, and test configurations change very often, usually multiple times per day) . The PXI needs to receive the data with lowest possible latency, so TCP/IP is not an option (we have to avoid waiting for retransmit timeouts). Lost datagrams are not as bad as delayed datagrams in this system.

So, we feel we need a broadcasting solution, and UDP multicast is a good fit for this system (it really works quite well when we work around the IGMPv3 problem).

[JacquesS]

As far as the information I could find goes, IGMPv3 has not yet been implemented in the PharLap ETS. Therefore, the controller is simply not responding to IGMPv3 queries. Is there a possibility to work with the switch and IGMPv2?

As a different option you could consider using Network Streams as Bob already suggested.