> Exponential back-off is fancy
It's literally just a left bit-shift? It's as easy as a linear back-off. The only thing less fancy is no back-off at all.
It's literally just a left bit-shift? It's as easy as a linear back-off. The only thing less fancy is no back-off at all.
It's fancy.
At least the penalty is you just repeatedly cause every car of the model in the entire country to fail instead of crashing into a wall, but this kind of thing is why the T in IoT is for "shit".
And it just supports my point, which is that it's not "literally just a left bit-shift".
It's quite a lot of work to do, actually. Which -- of course -- should be done. But there are commenters here acting like it's a single line of code.
But I think we all know what actually happened here was a rush to release and then a failure to follow up with "the update that actually does it right". The Jira ticket is probably still "open - should do, version: next" somewhere. And there's a "told you so" email chain linked in there somewhere.
I guess you could always cap off the exponential interval increases at some max interval, making it basically a repeating timer.
Though there's still the question of why would you need this for telemetry. It doesn't feel like this type of "marketing" telemetry needs to be quite real time.
No you MUST have a max interval cap. Exponentials and all, you'll soon be waiting days or months for a retry.
Please cap your numbers for both user experience reasons, and safety reasons.
Yes, have dealt with this before. Nothing like doing a fault analysis and telling someone that it'll fix itself in a few months.
A capped fibonacci sequence is a very common back off timer.
*Rule One of IoT network design: NEVER assume that you even have a network * If at all possible, and to the maximum degree possible, an IoT device must work whether there's a network available or not.
* at least across module sleep/wake