[jinpan]

Another fun surprising result from queuing theory is that if you have a buffer of pending RPC's that have some deadline, it is better to service them in a "unfair" LIFO order, as opposed to a fairer FIFO order. [0] goes into more gory details.

In the bank example from the article, LIFO would dramatically shorten the median wait time (~5 minutes), at the cost of really upsetting customers [1]. In the case of a support queue, where the waiters are blind to each other, this cost could be reconsidered ...

[0] https://arxiv.org/pdf/1008.4895.pdf

[1] from the article, "We really, really hate it when someone shows up after us but gets served before us.

[_v7gu]

After a while people would grow wise of this tactic and start redialing after waiting for some time. We could build a whole lot of efficient and beautiful systems, if only not for the people...

[SilasX]

Exactly. I've never had the time to dig into it, but these LIFO-optimality results always strike me as being non-physical or introducing some implicit hard-to-model effects.[1]

Like you say, people can just re-enter the queue, or (in meatspace) form a meta-queue that vies for entering the moment it has an open slot, reproducing FIFO all over again.

Furthermore, you get a lot of pro-cooperation effects (necessary for queues to work at all) by giving people "skin in the game" in the form of valuing their place in line. Once people lose nothing by inventing a new name and re-entering the line, that's all gone, and they no longer have an incentive not to be disruptive, which throws off disproportionate negative utility onto the rest of the system.

One day, I promise, I will unpack this result.

[1] My comment from 2015 expressing similar reservations: https://news.ycombinator.com/item?id=10182781

[papln]

What's wrong with degrading from LIFO to a random queue due to client retry, when you're starting from a FIFO that is already failing client expectations?

[SilasX]

Nothing, if it's just used for that (narrow, least-bad, degraded) situation. I was addressing the more general point that LIFO queues have some actionable superiority over FIFO in the general case because of the theoretical results cited in the literature.

[gpderetta]

Spherical customers in a vacuum.

[papln]

What's the problem with this? redialing essentially converts the FIFO/LIFO queue to a random queue, which isn't particularly worse.

Ultimately, the utility of "lower 50%ile" vs "lower 99.9%ile" is a subjective choice.

The value in LIFO is the observation that real people would rather their 10-minute request fail and require a retry due to LIFO (since they are already disatisfied with the original service*) than their 1second request take 1 minute due to FIFO.

[_v7gu]

People feel cheated when you request them to wait, but they can get better outcomes by redialing. It violates the trust between the call center and the dialer. Leaving people to wait forever is a bad, bad, bad move.

Alternative scenario: Someone figures out the best way of dealing with LIFO is spamming requests until one gets through and you end up with several multitudes of queuing work.

[oarabbus_]

On the contrary, a system is only beautiful if it successfully serves the people.

[jules]

That's just a result of your loss function. If you consider going over the deadline by a lot equally bad as going over the deadline a little, then of course. This doesn't apply to people waiting.

[macleginn]

The paper also suggests that they should turn some customers away altogether to achieve lower MWT, which makes this method even less appealing ("We must drop a small fraction of packets in order to dramatically improve delay for the remaining ones. <...> [Our] experiments, combined with those of [10] suggest strongly that the drop rate scaling may be inconsequential in many real world applications.")

[burtonator]

This isn't really unsurprising though. The problem is that your outliers are going to rise significantly.

You're basically trading some higher latency for lower median latencies.

[radomir_cernoch]

This explains a lot when applied to replying to e-mails.

[pstuart]

I thought the queuing algorithm for banks was to line up transactions so the largest go through first to increase the opportunity for overdraft fees.

[awshepard]

I heard from a customer service rep at a bank that they did that based on customer feedback. The general reasoning being that large amounts were most likely to be things like housing payments and car payments, where missing payments would incur larger charges from those companies, and/or put housing or transportation at risk.

[ahmedalsudani]

Debits first, credits last—just as the lord commanded.

[gumby]

By the way "debit" means "given" -- as in you "give" the money to the bank. "credit" means the money is being taken from them.

Tells you a lot about their attitude to your money!

[irishsultan]

Debit comes from a latin verb that means to owe, and credit from a verb that means to trust.

So a debit card is for the money that the bank owes you, and a credit card is for money that the bank trusts you will pay them back.

[dullgiulio]

Sure, which implies the money I store in the bank is debit they owe me. But worded that way I might be induced to think I deserve some kind of interest payment...

[jtms]

It doesn’t just imply it, that is exactly what it is. The bank is loaning your money out and then some (multiplied by whatever the current reserve ratios are). They quite literally don’t have the money you deposited, but just owe it back to you if you ask for it. That’s one of the ways a bank makes money.

[c3534l]

That's the etymological fallacy. Debit and credit just mean left and right side of the ledger.