Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Round Robin Strategy to Minimize Queue Latency? #855

Open
alexhulbert opened this issue Nov 25, 2024 · 1 comment
Open

Use Round Robin Strategy to Minimize Queue Latency? #855

alexhulbert opened this issue Nov 25, 2024 · 1 comment

Comments

@alexhulbert
Copy link

Hi, first of all, thank you for keeping this project maintained and up to date. I upgraded the firmware recently and I'm really appreciating the additional features and stability!

However, I sometimes send many light updates at once and its kind of jarring how they all turn on in sequence. I was thinking maybe a round-robin system would be better here since that would minimize the total latency until all lights are enabled. Like instead of sending 30 packets for light A, then 30 packets for light B, etc, maybe it could send one for A, one for B, etc until it has sent the necessary number of repeats for each light. Not sure how hard of a change this would be, but it sure would make the lights change a lot quicker.

Thanks again!

@sidoh
Copy link
Owner

sidoh commented Nov 25, 2024

Hello!

I actually suspect this would not work super well, especially if the packets have different radio configs. It'd be a little hard for me to test without having a bunch more lights to test with.

If you're interested in tinkering with it yourself, I think the appropriate place for this change would be here:

https://github.com/sidoh/esp8266_milight_hub/blob/master/lib/MiLight/PacketSender.cpp

Would need to change PacketQueue a bit as well. The interface is structured around dealing with one packet at a time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants