Sigh? So you don't think it's a big deal that for example for a strcat() of two 100 bytes you now need to copy _both_ strings, because the length field at the beginning now takes up more space, requiring the first string to be moved? How is that efficient?
C doesn't _require_ you to use NUL terminated strings, you can do whatever you feel is cute. A 'char *' is nothing but a pointer, which you can use as a string, but you don't have to, nor the reverse. If you like prefixing a string with a length (vlc coded or not) in your code, you can feel free do to so... Or use C++ and use std::string, because many (all?) implementations of it store the size separately. And yes, std::string has a "max_size()"...
If you don't use NUL terminated octet strings, you just won't be able to easily use many C libraries, because the rest of the world uses NUL terminated strings. And the reason for that is not a 'mistake', the author is wrong.
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.
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.
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.
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.
That's a very valid question... Probably the person who wrote the related API spec thought that UTC was a good way to communicate time, since it doesn't have things such as time zones and daylight savings time to deal with... I think the idea behind UTC was for it to be a good time format to use for communication. How it deals with leap seconds makes that only true if all the software involved, or its time library is kept up-to-date for each new leap second that gets inserted.
Drift is not a solution. Drift means accepting you will have a clock that can be one second off. Accurate clocks means that two independent systems are each keeping time accurately enough to allow monitoring of events such that it is known which event occurred first, or how much time difference _exactly_ there was between the events, even if the events occurred on different systems thousands of miles apart.
It's not about education, it's about determinism. Leap seconds are _not_ deterministic like leap years, etc, are.
Leap seconds are not known more than _one_ in advance, at the most... For example, right now, nobody knows exactly when the next leap second will be. When one is inserted depends on where the planet 'hangs out' in space around the sun, and that has some characteristics that are either nondeterministic, or still unknown to us humans.
It is not possible to make a program the will correctly account for all leap seconds it will encounter in its life for the next five or ten years, because those leap seconds have not been determined yet.
For example: How many seconds are there between August 24, 2010, and September 1 2017? You don't know yet, because you don't know how many leap seconds will be inserted in that time period, so no programmer can make a program _right now_ that can give that answer correctly. Yet, there are many applications where such accurate time differences are needed. The solution, is in the clock.
Otherwise maybe what's going on is that the volume of space around the planet between those roughly 9km and 62km is so large compared to the amount of available helium that even while it's still there, the helium will be dispersed so much that it will be practically impossible to retrieve (I mean, the gas will be at very low pressure).
It's not easy but also not impossible, and it seems to be improving a bit over the last year or two. Bread from the bakery department doesn't always have hfcs, nor do many 'pepperidge farm' branded prepackaged breads. The latter used to be one of the very few options in my local supermarkets, but now there are some more brands that are also hfcs free. Some even loudly advertise it on their labels. I really prefer to make it at home with the bread machine, but to be honest I'm usually just too lazy or not thinking ahead enough to even pour the ingredients in the machine...
Even though I don't drink much soda anymore: I saw some hfcs free pepsi products in the store recently too, as some kind of special, and there is of course Jones Soda which doesn't have it. Also, the mixes from the sodastream company don't have hfcs, and their diet sodas use sucralose (splenda) instead of aspartame.
Note that in Europe, where obesity is a smaller problem, hfcs usage in food is also much smaller, if not virtually nonexistent, and most (non-diet) products are simply sweetened with sugar. It doesn't prove anything, but I see smoke, so I'm trying to reduce my exposure to it...
The difference is probably that in this case the speaker knows lip-reading is being used, specifically wants to be understood, and probably is getting live audio feedback about how well it's working.
"Disclaiemr: I have no idea what I'm talking about."
Agreed... Neither do I, but I have a hard time imagining that plastic wrap containing an updraft of air strong enough to drive a turbine that generates.... 100 friggin Megawatts of electricity from it...
Would plastic wrap contain such a tornado? Do you have such winds flowing through your greenhouse (the part of the bottom has all the same air flowing under it as what eventually goes up into the tower...)?
Oh, and would that lowest plastic panel on the bottom of the tower be strong enough to hold the weight of the 2396 foot of plastic panels above it? That antenna mast definitely won't be strong enough to hold that weight, let alone stay upright on a windy day.
"Because that's how it works. You start with some initial reserves. You mine them cheaply. When you start to run out of reserves, prices go up. The high prices cause exploration. New mines open up, and prices go down. Repeat ad infinitum."
Just like how it has been working so well for oil, copper, gold, pretty much anything else we dig up from the ground or a mountain?
Slashdot Mirror
Sigh? So you don't think it's a big deal that for example for a strcat() of two 100 bytes you now need to copy _both_ strings, because the length field at the beginning now takes up more space, requiring the first string to be moved? How is that efficient?
C doesn't _require_ you to use NUL terminated strings, you can do whatever you feel is cute. A 'char *' is nothing but a pointer, which you can use as a string, but you don't have to, nor the reverse. If you like prefixing a string with a length (vlc coded or not) in your code, you can feel free do to so... Or use C++ and use std::string, because many (all?) implementations of it store the size separately. And yes, std::string has a "max_size()"...
If you don't use NUL terminated octet strings, you just won't be able to easily use many C libraries, because the rest of the world uses NUL terminated strings. And the reason for that is not a 'mistake', the author is wrong.
Get a DVD with the video to bring home? Or a VHS tape? You don't need broadband to watch a video, you know.
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.
/8 as effective as a /23 or (significantly) better. That will help a lot with the ipv4 shortage.
That means that for the ISP, LSN should make a
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
That's a very valid question... Probably the person who wrote the related API spec thought that UTC was a good way to communicate time, since it doesn't have things such as time zones and daylight savings time to deal with... I think the idea behind UTC was for it to be a good time format to use for communication. How it deals with leap seconds makes that only true if all the software involved, or its time library is kept up-to-date for each new leap second that gets inserted.
Drift is not a solution. Drift means accepting you will have a clock that can be one second off. Accurate clocks means that two independent systems are each keeping time accurately enough to allow monitoring of events such that it is known which event occurred first, or how much time difference _exactly_ there was between the events, even if the events occurred on different systems thousands of miles apart.
It's not about education, it's about determinism. Leap seconds are _not_ deterministic like leap years, etc, are.
Leap seconds are not known more than _one_ in advance, at the most... For example, right now, nobody knows exactly when the next leap second will be. When one is inserted depends on where the planet 'hangs out' in space around the sun, and that has some characteristics that are either nondeterministic, or still unknown to us humans.
It is not possible to make a program the will correctly account for all leap seconds it will encounter in its life for the next five or ten years, because those leap seconds have not been determined yet.
For example: How many seconds are there between August 24, 2010, and September 1 2017? You don't know yet, because you don't know how many leap seconds will be inserted in that time period, so no programmer can make a program _right now_ that can give that answer correctly. Yet, there are many applications where such accurate time differences are needed. The solution, is in the clock.
http://www.timeanddate.com/time/leapseconds.html
Otherwise maybe what's going on is that the volume of space around the planet between those roughly 9km and 62km is so large compared to the amount of available helium that even while it's still there, the helium will be dispersed so much that it will be practically impossible to retrieve (I mean, the gas will be at very low pressure).
Can somebody do the math?
It's not easy but also not impossible, and it seems to be improving a bit over the last year or two. Bread from the bakery department doesn't always have hfcs, nor do many 'pepperidge farm' branded prepackaged breads. The latter used to be one of the very few options in my local supermarkets, but now there are some more brands that are also hfcs free. Some even loudly advertise it on their labels. I really prefer to make it at home with the bread machine, but to be honest I'm usually just too lazy or not thinking ahead enough to even pour the ingredients in the machine...
Even though I don't drink much soda anymore: I saw some hfcs free pepsi products in the store recently too, as some kind of special, and there is of course Jones Soda which doesn't have it. Also, the mixes from the sodastream company don't have hfcs, and their diet sodas use sucralose (splenda) instead of aspartame.
Note that in Europe, where obesity is a smaller problem, hfcs usage in food is also much smaller, if not virtually nonexistent, and most (non-diet) products are simply sweetened with sugar. It doesn't prove anything, but I see smoke, so I'm trying to reduce my exposure to it...
The difference is probably that in this case the speaker knows lip-reading is being used, specifically wants to be understood, and probably is getting live audio feedback about how well it's working.
Or Microsoft is behind this and they want full control of Novell...
Eh, the story is about Novell, and nobody has used the word Microsoft and Linux yet, and they usually go together with 'Novell'...
Oh, and the SCO vs Novell trial is still on the 'todo list' for the courts...
Who knows what is really going on here... People tend to think long and hard before offering to spend $2B of their own money...
"Disclaiemr: I have no idea what I'm talking about."
Agreed... Neither do I, but I have a hard time imagining that plastic wrap containing an updraft of air strong enough to drive a turbine that generates.... 100 friggin Megawatts of electricity from it...
Would plastic wrap contain such a tornado? Do you have such winds flowing through your greenhouse (the part of the bottom has all the same air flowing under it as what eventually goes up into the tower...)?
Oh, and would that lowest plastic panel on the bottom of the tower be strong enough to hold the weight of the 2396 foot of plastic panels above it? That antenna mast definitely won't be strong enough to hold that weight, let alone stay upright on a windy day.
"Because that's how it works. You start with some initial reserves. You mine them cheaply. When you start to run out of reserves, prices go up. The high
prices cause exploration. New mines open up, and prices go down. Repeat ad infinitum."
Just like how it has been working so well for oil, copper, gold, pretty much anything else we dig up from the ground or a mountain?
</sarcasm>