Page 38 of 85 FirstFirst ... 28363738394048 ... LastLast
Results 371 to 380 of 841

Thread: ESPixelStick - E1.31 WiFi Pixel Controller

  1. #371
    Join Date
    Jul 2007
    Posts
    87
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Ok, so a few things:

    Your "unicast" is basically TCP. If e1.31 unicast is indeed implemented with no-ack, it uses optimistic delivery. That means the sender assumes the packet got there ok and will not resend the packet unless it hears otherwise. A no-ack packet is a packet that a client sends back to the sender with essentially a list of packets it believes it did not receive. In your analogy, that means you'd send a reply back to the sender which contained a list of letters you were suspicious never got delivered.

    I appreciate the explanation but I didn't need the analogy :-P. I was asking about specifics of the protocol. I'm not clear why a unicast e1.31 would ever want reliable transmission. By the very nature of DMX, at some point you are going to be retransmitting packets that are out of date for the current timing frame. If multicast e1.31 is indeed more reliable over 802.11 (which I still find hard to believe as a multicast frame is sent first as an acked unicast frame to the AP and then rebroadcast as a multicast frame by the AP), why not just remove the no-ack requirement in the protocol? Transmission would revert to best effort (just like multicast) but you'd still get the routing benefits of a unicast frame.

    Might have to read the protocol tomorrow after my morning cup of coffee.

  2. #372
    Join Date
    Jul 2007
    Posts
    87
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by jchuchla View Post
    It has nothing to do with e1.31. And it has nothing to do even with UDP vs TCP. This is an 802.11 wifi thing. It's not at the protocol layer, it's at the transport layer. That's a lower level mechanism that's in play regardless of the protocol and application layers on top of it. This is something we have no control of from our side of the picture. It's inherent to how WiFi works. So long as we're using regular WiFi equipment , it's something we need to work with.
    Ahh, yes I forgot about the inherent ack in the 802.11 side. That also explains why you don't see slowdowns on the wired side. A multicast frame over wifi is a unicast frame until the AP transmits it. Go it.
    Last edited by wingrunr; 01-02-2017 at 08:29 PM.

  3. #373
    Join Date
    May 2007
    Location
    Robbinsville, NJ
    Posts
    1,532
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    It seems better now that I converted them to Multicast. Also, I saw reference to 2.1 code? Where/how do you get that code? Github is still 2.0
    Michael



    New for 2016: Getting my ESPixel network to function, 4 HDPE Pixel Arches, Pixel matrix on tree trunks. PIXELS!!!
    FACEBOOK: https://www.facebook.com/GothambeatProductions?fref=ts

    Gotham Beat Productions LLC

  4. #374
    Join Date
    Jan 2015
    Location
    Folsom, CA, USA
    Posts
    1,402
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by michaelc View Post
    It seems better now that I converted them to Multicast. Also, I saw reference to 2.1 code? Where/how do you get that code? Github is still 2.0
    V2.1 look at post 333 of this thread
    In Lights Therapy...

  5. #375
    Join Date
    Dec 2015
    Posts
    105
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Any scheduled group buy for these for 2017?

  6. #376
    Join Date
    Aug 2012
    Location
    Charleston, SC
    Posts
    1,013
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by wingrunr View Post
    Ok, so a few things:

    Your "unicast" is basically TCP. If e1.31 unicast is indeed implemented with no-ack, it uses optimistic delivery. That means the sender assumes the packet got there ok and will not resend the packet unless it hears otherwise. A no-ack packet is a packet that a client sends back to the sender with essentially a list of packets it believes it did not receive. In your analogy, that means you'd send a reply back to the sender which contained a list of letters you were suspicious never got delivered.

    I appreciate the explanation but I didn't need the analogy :-P. I was asking about specifics of the protocol. I'm not clear why a unicast e1.31 would ever want reliable transmission. By the very nature of DMX, at some point you are going to be retransmitting packets that are out of date for the current timing frame. If multicast e1.31 is indeed more reliable over 802.11 (which I still find hard to believe as a multicast frame is sent first as an acked unicast frame to the AP and then rebroadcast as a multicast frame by the AP), why not just remove the no-ack requirement in the protocol? Transmission would revert to best effort (just like multicast) but you'd still get the routing benefits of a unicast frame.

    Might have to read the protocol tomorrow after my morning cup of coffee.
    E1.31 is strictly UDP. At the 802.11 link layer however, all unicast packets are "reliable" - ACK'd at the link layer. This can cause buffering and lag across the whole show if one node has an issue. Multicast 802.11 packets are handled much differently. They'll "broadcast" at a rate dependent upon the slowest node connected to the AP. If you have a power conscious device, like a phone, laptop, tablet, etc... connected to the same AP, the effects can even be worse. 802.11 has flags for handling devices which like to sleep and can further effect how the AP handles multicast traffic (even slowing it down to the DTIM interval).

    Now.... to really muck things up, some AP manufactures like to get fancy with multicast. Enter Ubiquiti's "Multicast Enhancement"... This will attempt to segment the traffic using IGMP snooping and transmit at higher rates that those devices support and makes multicast "reliable" - that means link layer ACKs and buffering again.. which means its really just taking your multicast traffic and converting it back to unicast which gets us right back to where we were before. For 802.11 multicast to work in our shows, it has to be in its purest form with no devices setting the 802.11 power saving flags.

    What makes e1.31 via multicast more reliable for shows isn't from a data perspective, but from an observers perspective. People will never notice some dropped packets (up to a threshold of course), however they will surely notice lag spikes and timing issues if the AP has to retry and buffer unicast transmissions too much. Many packets may die a short unfulfilled life, but its ok up to a point

  7. #377
    Join Date
    Aug 2012
    Location
    Charleston, SC
    Posts
    1,013
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by Not My Monkeys View Post
    Any scheduled group buy for these for 2017?
    I plan on starting one soon, probably this week.

  8. #378
    Join Date
    Jul 2007
    Posts
    87
    Post Thanks / Like

    Default ESPixelStick - E1.31 WiFi Pixel Controller

    Right. Realized that after it was pointed out the 802.11 layer was the culprit. I was thinking wired.

    I'm curious if setting ack timing to 0 on a dd-wrt router (which disables ack on Broadcom hardware) will allow the best of both worlds.


    Sent from my iPhone using Tapatalk

  9. #379
    Join Date
    Aug 2012
    Location
    Charleston, SC
    Posts
    1,013
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    Quote Originally Posted by wingrunr View Post
    Right. Realized that after it was pointed out the 802.11 layer was the culprit. I was thinking wired.

    I'm curious if setting ack timing to 0 on a dd-wrt router (which disables ack on Broadcom hardware) will allow the best of both worlds.


    Sent from my iPhone using Tapatalk
    I don't think that really disables it does it? When I looked before, all the references point to it as more of an ACK delay modifier to support long haul links. I had originally looked into hacking on OpenWRT to bypass the ACKs, but it looks like the juicy parts required are in closed source drivers for the vendors chipsets.

  10. #380
    Join Date
    Jul 2007
    Posts
    87
    Post Thanks / Like

    Default Re: ESPixelStick - E1.31 WiFi Pixel Controller

    From my reading it depends on the build and chipset. Recent builds disable on Broadcom and set to auto on Atheros. I'm planning on running some tests tonight so I guess we will find out.


    Sent from my iPhone using Tapatalk

Page 38 of 85 FirstFirst ... 28363738394048 ... LastLast

Tags for this Thread

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
  •