Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Queues don't fix overload (2014)

ferd.ca

Post reply on HN
Print view View original

151–156 of 156 posts

Re: Queues don't fix overload (2014)

#151

Post by aidenn0 »

withinboredom wrote: post #150
aidenn0 wrote: post #140

Earlier quoted context omitted.

Ugh. WiFi signals aren't the best in my A/V cabinet, so I ran G.hn powerline to it. This works great 98% of the time, but occasionally there will be something that blocks traffic for a short period of time, and those things must have huge buffers. If I'm e.g. watching Netflix when there is a hiccup, I see ping times of over a minute! I wrote a program that monitors ping times and reboots the G.hn adapters when they g…

Do you live near an airport ( https://en.wikipedia.org/wiki/Dynamic_frequency_selection ? You are probably using channels that interfere with radar and when a router detects the radar, it should shutdown for a minute or so.

Does that apply to G.hn? I thought it was only WiFi on the 5Ghz band?

Re: Queues don't fix overload (2014)

#152

Post by withinboredom »

gpderetta wrote: post #26
User23 wrote: post #6

So far as I know there is no theoretical alternative to load shedding or increasing handling capacity if your average request arrival rate is greater than your average request handling rate. At least, not if you want to handle every accepted request using a finite queue[1]. It would appear that with an unbounded queue every request will eventually be handled, but with an unbounded latency guarantee. Which appears equ…

> It would appear that with an unbounded queue every request will eventually be handled Of course there is no such a thing as an unbounded queue.

In reality, there are machines with enough memory that, for all practical purposes, they are unbounded.

Re: Queues don't fix overload (2014)

#153

Post by withinboredom »

tonyarkles wrote: post #74
weego wrote: post #4

Earlier quoted context omitted.

The overflow goes to the same drain, but further down, past a bottleneck that's designed to be there for a logical reason. It's a good example of real world flow control considerations vs paper theory.

Continuing the analogy from the article though, the sink overflow doesn't go past the red arrow in their diagrams. It's there to solve the specific problem of "the sink drain is plugged, either because you left the water running with the plug in or because there's a ball of hair immediately below the drain".

Indeed, if the clog is big/deep enough, the overflow won't work at all.[1]

[1]: Flooded 4 floors of a five-star hotel by puking in a sink and falling asleep before turning the water off.

Re: Queues don't fix overload (2014)

#154

Post by withinboredom »

aidenn0 wrote: post #151
withinboredom wrote: post #150

Earlier quoted context omitted.

Do you live near an airport ( https://en.wikipedia.org/wiki/Dynamic_frequency_selection ? You are probably using channels that interfere with radar and when a router detects the radar, it should shutdown for a minute or so.

Does that apply to G.hn? I thought it was only WiFi on the 5Ghz band?

Ah, I read it as though you switched to G.hn because of wifi issues and thought you were describing that issue.

Re: Queues don't fix overload (2014)

#155

Post by foofie »

Animats wrote: post #137
foofie wrote: post #132

Earlier quoted context omitted.

> (...) people really did think of network congestion as a buffer allocation problem, so the obvious solution was more buffering - i.e. adding queues. I don't think people believed network congestion was a buffer allocation problem. I think people believed buffering was a way to mitigate congestion caused by a spike in traffic before allowing connection problems to surface (dropped packets, dropped connections, etc).…

> I don't think people believed network congestion was a buffer allocation problem. Actually, they did, because everything in the early days had very small memory sizes. This was the 16-bit era.

> Actually, they did, because everything in the early days had very small memory sizes. This was the 16-bit era.

I don't think that's a possibility. If buffers are smaller then buffer capacity was not infinite, and the same failure modes applied. Triggering dropped packets/connections was just a matter of sending enough network traffic down a pipe, which given buffers were small then it wasn't a technical feat.

Re: Queues don't fix overload (2014)

#156

Post by lanstin »

o11c wrote: post #134
lanstin wrote: post #107

Earlier quoted context omitted.

Which is why your test integration environment has to throw 429 and 5xx errors consistently from day one. The error handling paths are hard to retrofit but easy to do before deployment.

(What test environment?) That will make you introduce error handling , but not necessary "correct" handling. "Retry after errors" is a great way to overload a system.

The idea behind forcing your clients to handle 429 isn't because they will do the right thing (although you'd think since ethernet won with exponential and random backup with some max timeouts that would be the default) but because it allows you the flexibility server side to start returning 429s when you need to - maybe just based on some idea of server load, maybe as some way of hard rate limits for a certain caller ID, maybe to do maintenance, whatever. It's the semantics "not processed, not fatal, try again in the future" which is hard to shoe horn into a large deployed number of callers after the fact, without angering people.
Post reply on HN