You probably now have a boot sector virus.

Remember those?

That's only true if every Internet user is also a netflix user. If that were the case, Netflix would be a lot more than 30% of the Internet's traffic.

Apples and Oranges...

I'm not denying the symptoms, all I'm saying is that the buffer causing the jitter is the window size, and it's not the network operator that chooses or configures that. The total 'buffers' between you and the receiver will never be fuller than your window size. The TCP window size is the maximum amount of data sent and not yet acknowledged by the receiver. When the window size is reached, you stop transmitting until you receive acks.

You can modulate the window size on an existing tcp/ip connection at the (endpoint) application level to control latency. I've done it and it works.

I read the article, and author admits himself: "(I’m not a full fledged TCP expert)."

I'm not saying there isn't a problem with latency, bandwidth and saturation. This 'bufferbloat' is just something he made up and then he attributes network behaviour findings to this. That doesn't mean that 'bufferbloat' is anything that exists and causes anything. When I say that, I don't deny the symptoms, I'm only saying that the symptoms are not caused by what is claimed.

There are no such buffers. The author just made up the word and never actually says which buffers he's referring to, he is only referring to a symptom and making the wrong conclusion.

The article can say whatever it wants, such buffers still don't exist.

There is no network 'operator' that configures this. In TCP/IP the only buffering that there is, is the window size, and the sending host sets that size.

I guess that people don't read the RFC's anymore, they just think that they know how the Internet communicated from nonsense and hearsay.

That site won't have a 1GB SNDBUF, so that won't happen. ('man 7 socket', then search for SO_SNDBUF).

It's amazing how many people, Gettys apparently unfortunately included (note: of course I did not rtfa before I posted this), don't know how TCP/IP really works.

There is no 'bufferbloat because RAM is getting cheaper'. What he is seeing is what happens when you want to saturate your link. It's sort of an Heisenberg of communication, if you want low latency and low (or no) packet loss on a connection, then the bandwidth can't exceed the available bandwidth, and for any instance that it does, you get either a buffered or a dropped packet.

Hmm... "proprietary encryption"?

http://www.interhack.net/people/cmcurtin/snake-oil-faq.html

If you are not seeing the solution, then that does not mean there isn't any.

How many apps on the Ubuntu desktop today do you think still use things that benefit from things such as server side font rendering. And which of those will actually switch from the X11 protocol to wayland, when wayland has backwards compatability for x11 client connections?

For example, the old apps will still be using the X11 client libraries with no difference in performance from today because it can be forwarded in exactly the same way. Gnome apps use gtk and cairo, 3d apps will use opengl, and all of that can be intercepted by a networking app, and in most cases it will actually be much more efficient to do that than intercepting at the x11 tcp protocol level.

It doesn't have to be limited to only local use. It's an api, which means somebody can make an implementation that forwards the api calls into some kind of rpc calls (or work on a higher level with all sorts of roundtrip and bandwidth optimization), allowing networked use. Even the drm api can be implemented as a virtual graphics device with a network backend, but that's probably not even necessary because from the architecture pictures I don't see a reason why the compositor wouldn't be able to support a network environment. It would need a local compositor and a remote compositor that know how to talk to each other (and with each some significant code to 'hide' the network), but it would be transparent to the local application. As long as the wayland protocol allows multiple wayland compositors to operate concurrently on a system (where the client apps run), and if it lets a wayland client choose the compositor to use (with some type of access protection in there), it should be possible to implement transparent networked displaying.

Maybe it will make the networked displaying more complex than a tcp connection from the X client library to the X server, but it's certainly not impossible. The X protocol isn't ideal for all networked use (anymore) either, because it's so sensitive to network latency and it doesn't help in any significant way to be bandwidth efficient, especially with the increasing amount of client-side rendering and 3d stuff that is happening these days (and not all X protocol features work on a remote connection (for example (and afaik): xrandr, dri, etc). Perhaps a good networked remote display protocol that optimizes and compresses all that when/where necessary will work equally as well (with as much complexity) in the wayland framework as it will in the xorg framework.

So perhaps in order to support modern displays and diverse networks, remote display has to get a little more complex than a simple remote X display anyway. I don't wayland is going to make that much different.

http://wayland.freedesktop.org/architecture.html

The salt doesn't clog an RO filter. Salty water is pumped into the filter, and two streams of water come out, one not salty and one more salty than the input. You dump the more salty water back into the ocean and that's how you get rid of the salt. It gets washed you continuously, actually it doesn't have to: The minerals remain dissolved. The filter will last at least months, probably years.

Sure, wells are a more permanent solution, but can you airdrop a water well, and is it producing drinkable water on the same day? I mean, this desalination system was designed to "can be cost-effectively assembled from standard parts and put into operation within hours using local human capital."

Try telling a group of desperate and thirsty people in a disaster zone to go digg a well to get their water. They need water first, then they can begin rebuilding their infrastructure.

The benefit of simple water producing systems such as this is not having to bring in all the bottled water and/or generator fuel every day from day one, freeing up the local infrastructure and logistics for other relief/rebuilding efforts.

How many people in disaster area's starved for water know how to dig/drill a water well, or operate the drilling equipment to do so without damaging themselves or the equipment? Ask your favourite well-driller if he'll let you airdrop him into a remote disaster zone to drill a water well today for $8k.

The article is pretty clear that the port numbers on the LSN can be re-used for different customers that are accessing different external IPs. The port can be used right away, in fact in parallel, as long as the external host is a different host. So the limit is (up to) 32k facebook or google browsers per external IP (32k because http 1.1 limits client connections per browser to 2), all other network usage will not encounter a limit before such usage will. And when people start having trouble getting to facebook or google, because of this, I'm sure they will be able to get more than a single IP for their services to improve it on their end.

That means that for the ISP, LSN should make a /8 as effective as a /23 or (significantly) better. That will help a lot with the ipv4 shortage.

DNS uses UDP and can acces to it be NATted just fine, you won't need a non-NATted IP to access DNS.

Your other complaints do not apply to everybody, and just like dynamic vs static ip's, I'm sure you will be able to get a 'normal' dynamic or static ip like you get today, for a nominal fee. I probably will end up paying for the privilege myself (either from the provider or through a VPN service), but I know most (or all) of my neighbours will not care.

And I won't even care about an addressable IP for an android/iphone.

That's nothing new compared to today, external RAM chips/modules already are accessed with a lot of latency while the majority of core memory accesses are to the on-chip caches. It just means that external RAM chips have to be even deeper into the cache/prefetch hierarchy (behind larger and/or more layers of cache), otherwise chip performance will suffer.

DRAMs latencies haven't really gone down much the last decade. afaik, a DRAM cell (on the chip) has a latency of something like 5ns or 10ns, pretty much the same (order of magnitude) as in the days of the original pentium and before... Modern RAMs (DDR3 etc) are not chips with a (significantly) lower DRAM cell latency, but chips with reduced other sources of latency and more sophisticated methods to hide the remaining latency, plus increased bandwidth and decreased power usage. The older rams ('EDO DRAM' etc and older) may have had longer external latencies of 50-100ns, because they had other sources of latency besides the DRAM cell latency. Newer DRAM chips are (for most accesses) much closer to the DRAM cell latency, but have already run into that wall.

http://en.wikipedia.org/wiki/Synchronous_dynamic_random_access_memory

http://en.wikipedia.org/wiki/Dynamic_random_access_memory

While it usually seems to work, it's not designed to do so, so Murphy will make sure that on the moment you most depend on it to work, it won't work and eat all your data, get you fired, steal your girlfriend/wife, break into your house, drink all your beer and steal your hdtv. Well, maybe not that dramatic, but wikipedia has the details.

Details: http://en.wikipedia.org/wiki/PS/2_connector#Hotplugging