Poss. bug 2.7.2 sACN viewer

Following up on this problem (I am in the same venue where this problem occurred). Through troubleshooting we have found the problem.

The culprit was the network switches we were using. Whenever we connect 2 TP-Link Gigabit Desktop Switches, the output of the universe that we are sampling with the sACN window freezes.

To replicate, I connected two LED PARS to two separate ports on a 4 port node that is connected to the console via 2 of the above switches. Then patched them to two separate universes.
-Set them both running a basic intensity effect.
-Open the sACN sampling window and sample the universe of one of the fixtures. The effect on the fixture will freeze even though the sampling screen will still have moving values.
-Change to the universe of the other fixture and the effect on that fixture will freeze and the first one will resume it's effect.
-Close the sACN window, and both will resume their effect.

If there is only one switch between the console and the node, the problem doesn't replicate.
When we replaced the second switch with a domestic router, the problem doesn't replicate.

So our first solution of 'Don't open the window', has now been replaced with 'Buy better switches'.

However we do find it interesting that while we thought it was a network being flooded with too much back and forth info when doing sACN monitoring, it was still only one universe that is being affected, not the entire node.

Hope this helps.

There is a probable explanations of what is going on, but its a bit of an Interesting/challenging one.

Its probable that the sACN monitoring window is doing that by acting as an sACN subscriber at actual IP level (rather than grabbing the output higher up the code stack).

sACN is probably being sent multicast over IP.

Once upon a time we used hubs rather than switches and in fact IP was designed around hubs (really to be historically accurate actually radio broadcast transmission), where everything on your local network segment is sent to every device. The device then has a filter in it at hardware level to only respond to packets sent to its mac addresses or to packets marked broadcast. The IP address of a device gets mapped to the mac address using ARP requests. This means the processor in the device only gets interrupted by packets of data that actually are for the device.

What's not always fully understood about multicast is that actually like the above it would still go to all the devices but it has a kind of fake mac address that is made up of a standard prefix and the group (ie the last 23 bits of IP address in the 224.x.x.x - 239.x.x.x range).

sACN agrees a group number with the devices it wants to multicast to and then sends to that dummy mac address and the devices that have subscribed pick it up.

All good so far if we are using an old hub, but when switches came along they start doing smarter things to allow several devices to talk to each other totally simultaneously on the local net. They do that by working out from the mac addresses which connection to switch the signal down.

That's straight forward for normal IP but multicast becomes a bit more problematic as the switch doesn't know about what things the device on the other end of wire has subscribed to. So simple switches just send any multicast down all cables and allow the original design of IP multicast to sort it out at the device.

However smarter switches do something devious. We all know there are TCP and UDP packets on an IP network and we may have come across ICMP (ip control protocol - what you are using when ping something) but there is another low level packet type that we might think was a typo IGMP which control the setup of the multicast groups. The smarter switches do something call IGMP snooping, which is basically spying on the network traffic and looking at the IGMP negotiations between devices, from which they can deduce what multicast groups things are listening to on the end of each of their wires and then only send the multicast down those wires.

So back to the sACN viewer issue. What is probably happening when the switches are cascaded are they are not correctly working out things from the IGMP and when they see the IGMP traffic created by the sACN viewer connecting, they end up incorrectly assuming they dont need to pass on the traffic to the other devices that want it. When it disconnects they resume.

All pretty devious and unexpected.

The solution counter intuitively is (as with a lot of network connectivity issues in lighting) to use cheaper lower spec switches - not as you were suggesting 'Buy better switches'.

Ironically almost all the network connectivity issue that are logged on this forum are due to smarter more expensive network switches. As you noted using a "domestic router, the problem doesn't replicate". It kind of makes sense as the better devices have a lot of optimisation in them for heavy bandwith usage - streaming video, large data volumes etc. so they try hard not to send data anywhere its not actually needed, whereas in lighting we are at trivial levels of bandwidths 250Kbits for a single universe but we definitely dont want it randomly blocked by something being smart.

Hope that makes sense to someone

There is a probable explanations of what is going on, but its a bit of an Interesting/challenging one.

Its probable that the sACN monitoring window is doing that by acting as an sACN subscriber at actual IP level (rather than grabbing the output higher up the code stack).

sACN is probably being sent multicast over IP.

Once upon a time we used hubs rather than switches and in fact IP was designed around hubs (really to be historically accurate actually radio broadcast transmission), where everything on your local network segment is sent to every device. The device then has a filter in it at hardware level to only respond to packets sent to its mac addresses or to packets marked broadcast. The IP address of a device gets mapped to the mac address using ARP requests. This means the processor in the device only gets interrupted by packets of data that actually are for the device.

What's not always fully understood about multicast is that actually like the above it would still go to all the devices but it has a kind of fake mac address that is made up of a standard prefix and the group (ie the last 23 bits of IP address in the 224.x.x.x - 239.x.x.x range).

sACN agrees a group number with the devices it wants to multicast to and then sends to that dummy mac address and the devices that have subscribed pick it up.

All good so far if we are using an old hub, but when switches came along they start doing smarter things to allow several devices to talk to each other totally simultaneously on the local net. They do that by working out from the mac addresses which connection to switch the signal down.

That's straight forward for normal IP but multicast becomes a bit more problematic as the switch doesn't know about what things the device on the other end of wire has subscribed to. So simple switches just send any multicast down all cables and allow the original design of IP multicast to sort it out at the device.

However smarter switches do something devious. We all know there are TCP and UDP packets on an IP network and we may have come across ICMP (ip control protocol - what you are using when ping something) but there is another low level packet type that we might think was a typo IGMP which control the setup of the multicast groups. The smarter switches do something call IGMP snooping, which is basically spying on the network traffic and looking at the IGMP negotiations between devices, from which they can deduce what multicast groups things are listening to on the end of each of their wires and then only send the multicast down those wires.

So back to the sACN viewer issue. What is probably happening when the switches are cascaded are they are not correctly working out things from the IGMP and when they see the IGMP traffic created by the sACN viewer connecting, they end up incorrectly assuming they dont need to pass on the traffic to the other devices that want it. When it disconnects they resume.

All pretty devious and unexpected.

The solution counter intuitively is (as with a lot of network connectivity issues in lighting) to use cheaper lower spec switches - not as you were suggesting 'Buy better switches'.

Ironically almost all the network connectivity issue that are logged on this forum are due to smarter more expensive network switches. As you noted using a "domestic router, the problem doesn't replicate". It kind of makes sense as the better devices have a lot of optimisation in them for heavy bandwith usage - streaming video, large data volumes etc. so they try hard not to send data anywhere its not actually needed, whereas in lighting we are at trivial levels of bandwidths 250Kbits for a single universe but we definitely dont want it randomly blocked by something being smart.

Hope that makes sense to someone