Results 1 to 10 of 10

Thread: Help with Vixen 3.5u4 and San Device E682

  1. #1
    Join Date
    Jan 2019
    Posts
    2
    Post Thanks / Like

    Default Help with Vixen 3.5u4 and San Device E682

    Right now I can get my lights to work in Unicast and not with Multicast. I go from my PC to the Router to the E682 with Cat 5e cable. Any ideas how I can get it to work in Multicast?

  2. #2
    Join Date
    Dec 2013
    Location
    Winter Haven Florida
    Posts
    2,961
    Post Thanks / Like

    Default Re: Help with Vixen 3.5u4 and San Device E682

    why do you want multicast the 682 doesnt do as many universes in multicast
    James WinterHaven Fl

  3. #3
    Join Date
    Jan 2010
    Posts
    419
    Post Thanks / Like

    Default Re: Help with Vixen 3.5u4 and San Device E682

    Did you set Multicast on your 632? Did you set Multicast ethernet for the controller in Vixen?

    Capture.JPG

  4. #4
    Join Date
    Dec 2012
    Location
    Hudson MA
    Posts
    3,372
    Post Thanks / Like

    Default Re: Help with Vixen 3.5u4 and San Device E682

    Multicast on a wired network is actually a detrimental configuration. the switch will forward the data to devices that do not need nor want it. Multicast is the choice for Wireless systems due to the fact that the broadcast packets do not need an acknowledgement which frees up the relatively slow WiFi output queue. Wired networks don't have that issue and are not significantly impacted by the Acks flowing through the switches.


    2018 - Moving and going to visit my Daughter in New Zealand. Most likely I will be dark or nearly dark, Some static stuff that is simple to put up.

  5. Likes TazChaLet liked this post
  6. #5
    Join Date
    Jan 2019
    Posts
    2
    Post Thanks / Like

    Default Re: Help with Vixen 3.5u4 and San Device E682

    Yes both are set to multicast.
    Thanks MartinMueller2003 I will just go ahead and keep on unicast.

  7. #6
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,576
    Post Thanks / Like

    Default Re: Help with Vixen 3.5u4 and San Device E682

    Quote Originally Posted by MartinMueller2003 View Post
    Multicast on a wired network is actually a detrimental configuration. the switch will forward the data to devices that do not need nor want it. Multicast is the choice for Wireless systems due to the fact that the broadcast packets do not need an acknowledgement which frees up the relatively slow WiFi output queue. Wired networks don't have that issue and are not significantly impacted by the Acks flowing through the switches.
    Just to round out the concept for educational purposes: Martin's statement makes the assumption that you're using inexpensive unmanaged network switches with no IGMP management. And that's an understandable assumption, as that's what most people use, at least at first. Multicast requires IGMP functionality on the network switches for proper operation. With IGMP snooping/querying in place, the traffic behaves the same as unicast with regard to data only going where it's needed. (in simplified terms) So if you're using cheap unmanaged switches, unicast is better. If you're using managed switches (or smart switches) multicast does have some benefits.

    Multicast's big benefit is the ability to reduce traffic by sending one universe of data to many receiving devices at the same time. Another benefit is that you don't need knowledge of IP addresses to get data around the network. The first advantage doesn't really apply when a device is consuming a full universe or more of data and it doesn't need to go anywhere else. The second advantage is diminished by the fact that devices often require you to use a web interface to configure it. So you still need to configure IP addresses and be aware of them.

    So these reasons combined, along with the ability to work well with cheap switches is why most people around here gravitate to unicast.

  8. Likes gassy liked this post
  9. #7
    Join Date
    Apr 2011
    Location
    Redding Ca
    Posts
    295
    Post Thanks / Like

    Default Re: Help with Vixen 3.5u4 and San Device E682

    I thought the E682 only worked in Unicast?

  10. #8
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,576
    Post Thanks / Like

    Default Re: Help with Vixen 3.5u4 and San Device E682

    Quote Originally Posted by JLStout View Post
    I thought the E682 only worked in Unicast?
    Actually the sandevices controllers were originally multicast only. It wasn't till they were around for a while that unicast was added. Artnet support came at some point as well. Unicast/multicast/artnet mode is set up near the IP address in the top line of the GUI.

  11. #9
    Join Date
    Mar 2012
    Location
    Lebanon, Illinois, USA
    Posts
    2,385
    Post Thanks / Like

    Default Re: Help with Vixen 3.5u4 and San Device E682

    Jon, when you use a switch that has IGMP, is there a change from the "no response required" that multicast uses to a "response required" between the IGMP switch and the controller? (I know what I believe, but want to hear it from someone who uses it.)
    Live, Laugh, Love.

  12. #10
    Join Date
    Nov 2011
    Location
    Chicago - Southwest Suburbs
    Posts
    7,576
    Post Thanks / Like

    Default Re: Help with Vixen 3.5u4 and San Device E682

    IGMP is out of band from the sACN traffic. That is, it's not part of the e1.31 sACN packets directly. it's a separate communication that happens on the side, and is infrequent and very small packets so it doesn't really impact traffic flow. The sACN itself is no different. It's still UDP traffic and has no acknowledgement at the IP level.

    (doing this from memory, hope I get all the specifics right)

    IGMP stands for Internet Group Management Protocol. It's all about managing groups.

    When a receiver (controller) is interested in receiving data from a universe, it sends out an IGMP subscription request. This is the "I want to be part of this group" message.
    Somewhere on the network, there should be either a multicast router (mrouter) or IGMP querier. This listens to the IGMP subscriptions and manages them. Mrouters are rare, they're used to route multicast traffic between networks which is rarely done. In the absence of an mrouter, you'd use an IGMP querier instead. This only does the group management, and no routing functionality. It's usually a function found in most (but not all) managed switches. once the querier gets the subscription request, that endpoint stays in the group until it either proactively leaves on it's own (aka fast leave) or some timeout occurs after the querier hasn't heard from it in some amount of time. It should send out periodic queries to check if receivers are still present on the network and still interested in being part of the group. This is the message: "there's at least one receiver connected to me that cares about this stream so I'm going to continue to forward it."

    IGMP Snooping is just like it sounds. It snoops on IGMP traffic flowing thru all of its ports. When it sees IGMP messages that indicate that something is connected to a specific port that is interested in a multicast stream, that stream will be forwarded to that port. But if there's no IGMP subscription requests from the clients happening, there's nothing to snoop on.

    Generally by default, if there's been no IGMP membership requests on an entire switch, it will forward that multicast stream to all ports just like an unmanaged switch. This makes sure that all receivers can get the data, even in the absence of IGMP. Once the first IGMP subscription is seen by the switch, then the filtering starts. Only the interested port(s) get the stream. But on most managed switches, this behavior can be adjusted to suit. You'll see settings for "unregistered multicast" and you can decide whether you want to filter all or forward all unregistered multicast traffic on a port by port basis.

    The membership request is sent by the receiver when it wants to get a stream, but it will generally only do so once if it never gets any group membership reports from the querier/mrouter. So if you have a receiver that gets data just fine for a few minutes, but then it just stops all of a sudden, this is because the switch stopped forwarding because it hasn't seen any IGMP communications for a given amount of time. So if you're seeing this symptom, you're using IGMP snooping without a properly configured querier/mrouter.

    Note: The ESPixelSticks implement a small workaround. Technically it's out of spec, but it works and doesn't break anything else doing so. It will send out periodic membership requests, even without getting group membership reports back from the querier/mrouter. This is done because WiFi Access Points will not forward unregistered multicast traffic. So to get it working at all on WiFi, you need at least this part of IGMP functioning. (I really wish Dave would do the same for the Falcons)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •