3 ms·
2 is rather irrelevant to the intended use case: devices connecting to a network with pre-shared credentials. Think cash registers and crop humidity sensors con
by azernik 2y ago
2 is rather irrelevant to the intended use case: devices connecting to a network with pre-shared credentials. Think cash registers and crop humidity sensors connecting to the internet, not cafe wifi.
1 is kind of unavoidable if you want a massively shared medium, mildly reliable connections once set up, and decent throughput.
- jessriedel 2y ago1 is not unavoidable. I’ve never gotten a clear answer on the explanation, but the most reasonable ones involve power-saving and frequency-saving strategies (only poll for new connections for a few hundred microseconds per second). And I think these are eminently solvable. On 2, my question isn’t “why haven’t they fixed #2 for this use case?” it’s “where does the effort to address this relatively small use case come from while #2 remains unaddressed “?
- azernik 2y agoA few hundred microseconds is not enough time to send an announcement at the low bitrates required for noisy channels, and then you need to multiply it by the number of cells in a collision domain. This is a hard limit of information theory and physics. And it is possible for the vast array of computer scientists in the world to work on more than one thing at a time; this particular work was done by a small team, whose specialties are in any case not suitable for work on better open authentication/consent protocols.
- jessriedel 2y agoMy memory of the consensus, the last time this topic came up, is that the number is in fact less than a hundred microseconds. But it doesn't matter for my point if it's a few milliseconds or whatever. The problem is solvable.