[HN Gopher] Graceful Degradation (2014)
       ___________________________________________________________________
        
       Graceful Degradation (2014)
        
       Author : ColinWright
       Score  : 38 points
       Date   : 2021-09-10 08:06 UTC (1 days ago)
        
 (HTM) web link (www.solipsys.co.uk)
 (TXT) w3m dump (www.solipsys.co.uk)
        
       | code_duck wrote:
       | Interesting. It reminds me of how traffic jams flow better when
       | drivers simply drive a slow, steady pace rather than repeatedly
       | accelerating to the car in front of them and stopping.
        
       | simpsond wrote:
       | 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.
        
         | cratermoon wrote:
         | I'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 wrote:
           | It 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.
        
         | kwhitefoot wrote:
         | That 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,
        
       | ColinWright wrote:
       | Prompted by the discussion[0] of "Suspicious Discontinuities"[1]
       | I thought I'd share my experience.
       | 
       | [0] https://news.ycombinator.com/item?id=28452926
       | 
       | [1] https://danluu.com/discontinuities/
        
       | [deleted]
        
       | [deleted]
        
       | kjellsbells wrote:
       | It feels like the diamond in the story is the insertion of
       | randomness in the backoff/retry. Networking protocols have an
       | awkward habit of not doing this and accidentally inducing
       | thundering herds of retries.
       | 
       | In the till situation, classic expo backoff would have been
       | catastrophic: since all tills at Xmas are about equally busy,
       | they'll all backoff and retry in the same way. So the randomness
       | essentially simulates different levels of till busyness.
        
       ___________________________________________________________________
       (page generated 2021-09-11 23:01 UTC)