2 ms·
Perhaps you are right. Though it seems easier to reason about a system with a hundred timers running at a set cadence than a hundred exponential back-offs. Mayb
by clnq 3y ago
Perhaps you are right. Though it seems easier to reason about a system with a hundred timers running at a set cadence than a hundred exponential back-offs. Maybe I just have more experience with the former.
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.
- peheje 3y ago"I guess you could always cap off the exponential interval increases at some max interval, making it basically a repeating timer." No you MUST have a max interval cap. Exponentials and all, you'll soon be waiting days or months for a retry.
- mmac_ 3y agoIt's ok, if you wait long enough it'll go back down to a small number. Or maybe a negative number and then the car crashes? 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.
- dublin 3y agoMost (actually almost all) IoT systems are not well-thought-out in this regard. It requires a bit of paranoiac foresight. Designers far too often think it's really, really important that remote devices stay connected to the mothership, when in reality, most IoT devices would be far better off NEVER requiring a cloud connection, but leveraging one if/when available. *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.