4 ms·
Back pressure is often useful. Slow down the pipeline from the bottleneck to the source. At some point it’s important to cause failures, informing the source. T
by simpsond 5y ago
Back pressure is often useful. Slow down the pipeline from the bottleneck to the source. At some point it’s important to cause failures, informing the source. Those failures can also be intentionally delayed. These techniques are used by networking systems to keep services from falling over. Tuning the knobs for when to fail, when to delay, etc is a hard problem. That is probably why there are so many congestion control algorithms for TCP.
- kwhitefoot 5y agoThat reminds me of a time, many years ago, when we upgraded a from hubs to switches in the design office. All of a sudden all the HP Unix workstations started to misbehave. It turned out that NFS needed the immediate back pressure caused by collisions on the Ethernet. The switches had a buffer for each port so there was no back pressure until too late and NFS would report that packets were lost. We put the hubs back and all was well,
- cratermoon 5y agoI've never taken the time to really dig into the heuristics around fail-fast vs graceful degradation. The two strategies seem to contradict each other, and I'd love to read some analysis of how to navigate the options.
- ColinWright 5y agoIt depends on the at-the-time-consequences of the failure. You ask yourself: What happens if/when it fails? If you're in a position of the developer trying to get something working reliably, absolutely you need things to fail early and hard. But when something is in the field and in the hands of the user, you don't want things to crash.