The publishers aren't the ones footing the bill for a major internet-connected business server operation ...

But it does get cranked into the price. TANSTAAFL: The customer pays for it somehow.

Good grief. Why did you wait UNTIL THE DAY they should be used to actually post about useful gadgets that require time to purchase, set up, and check out before use?

Now any of us who would have liked to obtain and use one of these gets to fret about how much BETTER the holiday could have been, rather than actually having the gadget operating and ENJOYING it.

TFA was updated two days ago so it obviously had been up for at least that long. A week or two lead would have been ideal.

This is right up there with not mentioning eclipses, meteor showers, and the like until the day of, or the day before, rather than at least a week back, so people who had forgotten about them have no time to arrange their schedules for a watch-it excursion. B-b

I'm pretty sure I can find something interesting to do with the extra years. :p

Ditto.

Even more so if, during the extra years, I am as healthy as I was at 20 (jogging as a normal gait) rather than at 65 (aching slightly all the time, pain in the morning, joints starting to fail, ...)

Coming from a line of people that typically lives to see birthdays numbered in the low nineties, I can say that even if I DON'T get any extra years it would still be a fine bonus to live just the rest of the same number without the inflammation and the impairment of body functions and healing due to cell senescence.

Charging as much for an ebook as a physical book is completely off-base. You still have to make the money back on editors, artwork, advertisement, etc., but the physical print, transportation, and storage costs should cause those books to be discounted a good amount.

On the other hand, a hardcopy book is an asset on which the publishers and booksellers can be charged an inventory tax. Thus it is often to their financial advantage to actually destroy them rather than hold them in the hope of future sales. Holding them effectively becomes a liability rather than an asset (though the tax man doesn't see it that way). This is one reason it becomes hard to find many books after a year or so. It's also a reason for deep discounts on books to clear inventory.

(Interestingly: Science Fiction is an exception. It has a track record of slow long-term sales - for decades - that makes it advantageous to hang on to physical copies for future sales.)

Electronic books don't have this problem. The publisher has only one copy (plus backups) and creates additional copies for sale on-the-fly.

As it is, much of the time you can buy a print edition cheaper than an eBook version on new releases...

When the value of the hardcopy book has actually gone negative, selling it for any price above the transaction cost is better than pulping it. Meanwhile, operating a major Internet-connected business server operation is not cheap.

Eliminate the inventory taxes on books, bringing the cost of holding onto a book until it sells down near the cost of the storage space and environmental control, and you should see a drastic change in hardcopy book availability and pricing structure. (Assuming electronic books haven't substantially displaced hardcopy by then.)

Is it voluntary? Or did they taxpayer funded?

If it's government funded, one billion means they are spending the entire lifetime disposable income (i.e. everything but basic food and housing) of three thousand people, just to set it up. What benefits can this research have that will pay off more than that?

I'll ask my electrician for a full size rack on wheels, but if he can't get one, the wall mount it is

Unless you need the full 42u, I'd definitely go for something smaller. A half-ish rack on wheels should be more than adequate, will be less imposing, and they're relatively cheap, too. We have a couple in the office at work because the few machines that aren't in one of the data centres don't need a full height permanent rack. I can't believe there isn't a suitable supplier in Luxembourg, given the number of financial institutions there. But if not, there should be plenty in Germany, right?

I agree with much of what you say. But:

Large queues are a problem, but they can be mitigated by adding more capacity (bandwidth). It doesn't matter how deep the queue can be if it's never used -- it doesn't matter how many packets can be queued if there's enough bandwidth to push every packet out as soon as it's put in the queue.

Unfortunately, TCP ramps up until there IS congestion. Raise the capacity of the congested link and it either becomes congested at the higher capacity or some other link becomes the bottleneck. You still have the problem somewhere. And costs make it prohibitive to build a backbone fast enough for ALL the last-mile links to run at full speed simultaneously (making the bottleneck be the rated speed of the customer drop.)

So AQM of some sort is a requirement to avoid the "buffer bloat" scenario in the WAN.

TCP attempts to divide traffic for different streams evenly among all the flows passing through it.

Well, no, it doesn't. ... the first stream ...g over the congested link will use the bulk of the bandwidth, ... The other streams won't be able to ramp up to match the first stream, as they will constantly encounter congestion, and the first stream won't back off enough to let other streams ramp up to match it.

I was under my impression that, because the congestion signals are pretty much randomly distributed over the traffic in proportion to its volume (either bandwidth or number of packets), the backoff is substantial and the ramp up is slow, competing TCP flows on a congested link (with similar packet sizes) quickly converge to a fair split of the link even if the starting state is a fat flow and one or more newbies. The initial hog gets hit more often than the little guys until they're about matched. (Of course "quickly" is several turnaround times, so this only applies to flows with substantial persistence, not to things like the short bursts characteristic of web page loads.)

But my focus has been implementing the current standards, not analyzing their performance and how they could be improved. So AFAIK I could be mistaken.

ISPs... have an incentive NOT to use AQM ... on the cable modem or DSL modem. [There] they have another incentive: maximizing speed-test results.

Good point. So if you have multiple machines at home you need AQM between them and the modem. (i.e. you need AQM in your own firewall, NAT machine, home router and/or WiFi access point(s), rather than just using a switch or the ISP's WiFi link to multiplex your machines.) ... the first thing I do when setting up any new shared network ... is put a Linux box in between the cable/DSL modem and the rest of the network. [Here's my AQM script.] ... You can do ... a similar thing ... with some ... SoHo Linux routers running DD-WRT and the like.

THANK you for that. (My wife recently started taking classes and the online tools she's using for homework break if we have substantial traffic on another machine - like me watching a YouTube clip. We'd assumed it was just congestion and were looking into a speed upgrade. But buffer bloat latency on the uplink seems a likely suspect. That script, or a derivative, is going into the next tweak of the firewall, to see if it solves the problem.)

Today, there is no incentive for an ISP to consider spending money on this. For their private customers, they sell QoS, which guarantees their customers a better queuing method. Extremely profitable. For consumers, it makes sense to simply continue investing in infrastructure.

You appear to be confused about the issue. This is not about capacity and oversubscription. This is about a pathology of queueing.

The packets leaving a router, once it has figured out where they go, are stored in a buffer, waiting their turn on the appropriate output interface. While there are a lot of details about the selection of which packet leaves when, you can ignore it and still understand this particular issue: Just assume they all wait in a single first-in-first-out queue and leave in the order they were processed.

If the buffer is full when a new packet is routed, there's nothing to do but drop it (or perhaps some other packet previously queued - but something has to go). If there are more packets to go than bandwidth to carry them, they can't all go.

TCP (the main protocol carrying high-volume data such as file transfers) attempts to fully utilize the bandwidth of the most congested hop on its path and divide it evenly among all the flows passing through it. It does this by speeding up until packets drop, then slowing down and ramping up again - and doing it in a way that is systematic so all the TCP links end up with a fair share. (Packet drop was the only congestion signal available when TCP was defined.)

So the result is that the traffic going out router interfaces tends to increase until packets occasionally drop. This keeps the pipes fully utilized. But if buffer overflow is the only way packets are dropped, it also keeps the buffers full.

A full buffer means a long line, and a long delay between the time a packet is routed and the time it leaves the router. Adding more memory to the output buffer just INCREASES the delay. So it HURTS rather than helping.

The current approach to fixing this is Van Jacobson's previous work: RED (Random Early Drop/Discard). In addition to dropping packets when the buffer gets full, an very occasional randomly-chosen packet is dropped when the queue is getting long. The queue depth is averaged - using a rule related to typical round-trip times - and the random dropping increases with the depth. The result is that the TCP sessions are signalled early enough that they back off in time to keep the queue short while still keeping the output pipe full.The random selection of packets to drop means TCP sessions are signalled in proportion to their bandwidth and all back off equally, preserving fairness. The individual flows don't have any more packets drop on the average - they just get signalled a little sooner. Running the buffers nearly empty rather than nearly full cuts round-trip time and leaves the bulk of the buffers available to forward - rather than drop - sudden bursts of traffic.

ISPs have a VERY LARGE incentive to do this. Nearly-full queues increase turnaround time of interactive sessions, creating the impression of slowness, and dropping bursty traffic creates the impression of flakeyness. This is very visible to customers and doing it poorly leaves the ISP at a serious competitive disadvantage to a competitor that does it well.

So ISPs require the manufacturers of their equipment to have this feature. Believe me, I know about this: Much of the last 1 1/2 years at my latest job involved implementing a hardware coprocessor to perform the Van Jacobson RED processing in a packet processor chip, to free the sea of RISC cores from doing this work in firmware and save their instructions for other work on the packets.

The first time I saw this was back about the mid '60s, when a bank got the idea to equalize wait time this way. It was called "Zip Line".

It's a pity that the non-paywall article doesn't say SQUAT about what the mechanism ACTUALLY IS.

(I wonder if that's deliberate, to get more people to pay up.)