The only television service that offers full ATSC bitrates (around 15 Mbps) is Verizon FiOS because they have so much raw capacity down that fiber. Everyone else is between 8 to 12 Mbps.
Normal subs don't require the person to be in water. This sub is a "wet sub" where the inside is filled with water. However, I'm assuming he will sleep dry at night above the sub.
He has to be submerged for more than a month. There's got to be some real nasty side effects to this. Furthermore, it's sort of like a zero G environment so there may be some negative impact there as well.
Take this claim from Cringely that this post links to. "And the upshot is that I could move to Japan and pay $14 per month for 100-megabit-per-second Internet service but I can't do that here and will probably never be able to"
That's nonsense when you look up the actual prices in Japan. http://flets.com/english/opt/index.html. If you're looking for regular 100 Mbps service in a single family home, they charge 5460 Yen which is $61.47 and that does NOT include the separate ISP charge. Cringely's quoted $14 is probably just the ISP charge and not the connect charge.
Yes it does, this is why MIMO devices are able to go well past the limit in practice and there are plenty of real-world examples. I've also asked Professor Dale Hatfield (http://itp.colorado.edu/people/faculty/dale-hatfield) about this and he has stated that each spatial stream has its own shannon's limit.
Shannon's limit states that you can't go faster than 1-7 bits/sec/Hz, but that applies to a single spatial stream. If you have 4 spatial streams with good multipath, then it is possible to go 4 times faster. This is why LTE 4xMIMO with a 20 MHz channel can go past 300 Mbps which is 15 bits/sec/Hz.
HSDPA 3G is the technology we have now that's 7.2 Mbps. It has a interface latency of 150 ms round trip.
HSPA+ is the technology coming out in 2009 that this article is talking about which has a downstream capacity of 44 Mbps, and I think they're trimming the latency down to about 90ms round trip.
LTE is the next gen technology launching in 2010 and it will go 85 Mbps downstream on 2xMIMO using 10 MHz of frequency. It can go 300+ Mbps using 20 MHz 4xMIMO. They're getting the air interface latency down to 20 ms round trip which is getting really good and it's only 10 ms higher latency than wired DSL.
It all depends on your application requirements. If you only care about VoIP and online gaming, you don't even need 100 Kbps and all you want is the lowest ping times. You only need the burst speed for web surfing and downloading new maps, etc.
"'There's another good reason to do this because it balances out the load between single-flow TCP applications. When a TCP end-point backs off to 50%, it's giving a new TCP flow a chance to take up the slack and speed up until the two TCP flows reach a state of equilibrium. UDP end points lack this behavior.'
You have this completely backwards. TCP endpoints can only detect congestion through packet loss on the connection. UDP endpoints are free to back off for *any* reason, including but not limited to packet loss."
Looks like you misread. I said routers drop packets (before total congestion), TCP endpoints detect and react by cutting speed in half which gives slower TCP streams a chance to rise to equilibrium.
"Because every TCP connection is basically independent, you cannot use information gained from one connection to backoff on another. With UDP you can.
A UDP application can backoff as aggressively as TCP, less aggressively, or more aggressively. Nobody yet knows how BT will rig its backoff algorithm."
Yes it can backoff; if the routers dropped UDP packets the same way they dropped TCP packets. But they don't, so there's your problem.
"The reason you drop TCP or UDP packets is not to produce a response from the end-points. It's because the link is congested and you simply can't carry all the traffic"
You do it for both reasons, but the FIRST reason you do it is to get the end-points to voluntarily backoff first before you reach a point of crisis. That's the whole point of Random Early Detection which is to get the clients to backoff before the network gets completely saturated in which case really nasty things happen. Routers drop packets before they reach 100% congestion not to trim the bandwidth; but to get end-points to back down.
There's another good reason to do this because it balances out the load between single-flow TCP applications. When a TCP end-point backs off to 50%, it's giving a new TCP flow a chance to take up the slack and speed up until the two TCP flows reach a state of equilibrium. UDP end points lack this behavior.
As for Richard Bennett's claim that UDP isn't generally dropped by routers, this is the reason he is concerned about this change in BitTorrent. This will force routers to start dropping UDP packets just like TCP packets and it will have a bad affect on other UDP applications that have a good reason to use UDP e.g., they're low/fixed bandwidth or they only send short/small bursts of data which means they benefit by bypassing the overhead of TCP. Bulk file transfer applications shouldn't be bypassing TCP for UDP and even if BitTorrent is well intentioned, such a large change could be risky for the Internet. That's the whole point Bennett is trying to make.
Yes, he has said that UDP is treated differently than TCP, and it makes sense to treat them differently. I know the man we have spoken by phone and in person. It makes no sense to drop UDP packets since it doesn't produce a response from the end-points.
No, routers do not treat UDP and TCP the same. Richard Bennett is a network architect and I trust his assessment of the situation more than I trust your's.
I can assure you I am not making it up. Routers and other network devices typically don't drop UDP packets because UDP end points don't respond like TCP end points which halve their bandwidth whenever a packet isn't delivered. It's also hasn't been necessary to drop UDP packets because traditional UDP applications are typically small bursts of data or low/fixed bandwidth applications like VoIP and online gaming. Now this is all about to change when you get a huge bulk transfer application like BitTorrent which accounts for a significant portion of the Internet's traffic.
The client application can't know about congestion in the core of the network, so it breaks control at the core of the Internet where there's less management. If you read the article fully, this would have been apparent.
Real-time applications use UDP because they have built-in bandwidth caps and they don't burst to the full capacity of the network like file transfer applications. It's dangerous to put P2P on UDP on a very large scale and it will require a massive change in the core of the Internet to deal with this new behavior.
Looks like it needs a hole in the floor so you can stick your feet out the bottom and help accelerate the car. If you look at the first video they have in link, they had to push it to go.
The amount of energy you can put in to compressed air is pretty lousy and as someone else already mentioned above, you'd lose a lot of heat energy and you have to deal with the freezing effect when you begin to release the air.
Governments get to tax but that means they have an obligation to help provide the infrastructure. Is the government going to contribute anything to that virtual world?
I use to be a senior IT admin/engineer for a good size company. Even our remote workers who used remote site syncronization backup only accounted for about 10 GB per month. Just because you have 200 GBs of data to backup does NOT mean you transfer that much data a month since all of these backup applications only replicate the data that has been changed.
If that's not enough for a particular business user, they can pay for a business class connection or pay the $1/GB overage charge or get a different provider if they think they can get cheaper volume.
Business people are low volume people and most of them would probably be under 2GB per month. It's only when you start downloading videos that you run in to these problems.
The FSB didn't prevent Core 2 from dominating the 1 to 2 socket market (with exception of some high performance computing applications) in performance. The FSB was even OK for 4 socket Tigerton and even the current 6-core Dunnington Core Microarchitecture products for transaction servers. Where the FSB failed to deliver for Intel's Core 2 was primarily the 4-socket market because it was starving the processor. Intel kept using brute force clock speed to make the FSB good enough (not great) to keep up with the Core 2, e.g. the Stoakley platform with fully buffered DDR2-800 support.
FSB was NOT good enough to keep up with the Nehalem and the move away from FSB architecture was absolutely required. So no, they should not have gotten rid of FSB sooner because the Core 2 was an absolute success these last two years. I think there was a project that would have married Quick Path to a Core microarchitecture chip but it was killed off.
So in hindsight, Intel's timing on the demise of FSB appears to be just right.
The 2 networks must be of equal value to each other, and peering to a large Tier 1 is essentially a partial transit because it's a large chunk of the Internet you're accessing. If one operator doesn't want to peer, they have every right to stop peering. You cannot hold a gun to people's heads and say "you will peer with anyone" regardless of whether they offer equal value or not.
Cogent misrepresented their capability to Sprint during the trial, then they lied to the media about the existence of a settlement free peering agreement. Sprint had warned Cogent to either pay for a connection to Sprint or route somewhere else to Sprint's network, Cogent refused to act. Your fundamental assumption that all peering arrangements MUST be free is just plain wrong.
So if I stopped paying for my web server's bandwidth, my fans should complain to their ISP that they're not giving me free bandwidth and that they should stop "double dipping"? Sorry buddy, you don't seem to understand how the Internet works.
Internet is a mixure of settlement and settlement-free peering arrangements. Every tier 1 provider that gets free peering has an obligation to maintain and upgrade the backbone of the Internet which is costly. We can't have tier 1 providers free loading because that means customers who aren't free loading have to pick up the slack. The best explanation of peering is here http://tech.slashdot.org/comments.pl?sid=1015917&cid=25608479.
No, Sprint was fearing for Cogent's customers and they feared Cogent would break the connection in a bad way by allowing the packets to go in to a black hole. That's exactly what they did and your argument is just plain nonsense. Sprint kept the free connection without a contract in good faith hoping to resolve the situation without affecting any customers.
These free loading companies really do offer cheaper service because they are stealing bandwidth. Slashkitty is essentially arguing that it's cheaper to buy a car from a car thief and technically he's right because I can probably buy a nice car for 1/4th the price if I buy it from a thug who just stole the car. What's actually happening is that he's just rationalizing immoral and illegal behavior and justifying it under the banner of the little guy getting something back from the evil corporations.
It's the same crazy logic with all the people in these threads arguing that any little network should be able to peer for free with any Tier 1. It's the crazy logic that if I rented a little rack space at a peering hotel for $200 a month, I should be able to tap in to all the tier 1 providers with my Gigabit Ethernet Interface and be equals with all the other tier 1 providers. What these people are really doing is that they're rationalizing theft.
Slashdot Mirror
The only television service that offers full ATSC bitrates (around 15 Mbps) is Verizon FiOS because they have so much raw capacity down that fiber. Everyone else is between 8 to 12 Mbps.
Normal subs don't require the person to be in water. This sub is a "wet sub" where the inside is filled with water. However, I'm assuming he will sleep dry at night above the sub.
He has to be submerged for more than a month. There's got to be some real nasty side effects to this. Furthermore, it's sort of like a zero G environment so there may be some negative impact there as well.
There should be some way to bump your post to the entry at the top. It puts everything in the proper context.
Why does anyone still believe Cringely and quote him? This is the guy that makes things up as he goes along. I mean he went around lying about the fact that he was a Stanford PhD and Professor http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/1998/11/11/DD94762.DTL.
Take this claim from Cringely that this post links to. "And the upshot is that I could move to Japan and pay $14 per month for 100-megabit-per-second Internet service but I can't do that here and will probably never be able to"
That's nonsense when you look up the actual prices in Japan. http://flets.com/english/opt/index.html. If you're looking for regular 100 Mbps service in a single family home, they charge 5460 Yen which is $61.47 and that does NOT include the separate ISP charge. Cringely's quoted $14 is probably just the ISP charge and not the connect charge.
Yes it does, this is why MIMO devices are able to go well past the limit in practice and there are plenty of real-world examples. I've also asked Professor Dale Hatfield (http://itp.colorado.edu/people/faculty/dale-hatfield) about this and he has stated that each spatial stream has its own shannon's limit.
Shannon's limit states that you can't go faster than 1-7 bits/sec/Hz, but that applies to a single spatial stream. If you have 4 spatial streams with good multipath, then it is possible to go 4 times faster. This is why LTE 4xMIMO with a 20 MHz channel can go past 300 Mbps which is 15 bits/sec/Hz.
HSDPA 3G is the technology we have now that's 7.2 Mbps. It has a interface latency of 150 ms round trip.
HSPA+ is the technology coming out in 2009 that this article is talking about which has a downstream capacity of 44 Mbps, and I think they're trimming the latency down to about 90ms round trip.
LTE is the next gen technology launching in 2010 and it will go 85 Mbps downstream on 2xMIMO using 10 MHz of frequency. It can go 300+ Mbps using 20 MHz 4xMIMO. They're getting the air interface latency down to 20 ms round trip which is getting really good and it's only 10 ms higher latency than wired DSL. It all depends on your application requirements. If you only care about VoIP and online gaming, you don't even need 100 Kbps and all you want is the lowest ping times. You only need the burst speed for web surfing and downloading new maps, etc.
"'There's another good reason to do this because it balances out the load between single-flow TCP applications. When a TCP end-point backs off to 50%, it's giving a new TCP flow a chance to take up the slack and speed up until the two TCP flows reach a state of equilibrium. UDP end points lack this behavior.'
You have this completely backwards. TCP endpoints can only detect congestion through packet loss on the connection. UDP endpoints are free to back off for *any* reason, including but not limited to packet loss."
Looks like you misread. I said routers drop packets (before total congestion), TCP endpoints detect and react by cutting speed in half which gives slower TCP streams a chance to rise to equilibrium.
"Because every TCP connection is basically independent, you cannot use information gained from one connection to backoff on another. With UDP you can. A UDP application can backoff as aggressively as TCP, less aggressively, or more aggressively. Nobody yet knows how BT will rig its backoff algorithm."
Yes it can backoff; if the routers dropped UDP packets the same way they dropped TCP packets. But they don't, so there's your problem.
"The reason you drop TCP or UDP packets is not to produce a response from the end-points. It's because the link is congested and you simply can't carry all the traffic"
You do it for both reasons, but the FIRST reason you do it is to get the end-points to voluntarily backoff first before you reach a point of crisis. That's the whole point of Random Early Detection which is to get the clients to backoff before the network gets completely saturated in which case really nasty things happen. Routers drop packets before they reach 100% congestion not to trim the bandwidth; but to get end-points to back down.
There's another good reason to do this because it balances out the load between single-flow TCP applications. When a TCP end-point backs off to 50%, it's giving a new TCP flow a chance to take up the slack and speed up until the two TCP flows reach a state of equilibrium. UDP end points lack this behavior.
As for Richard Bennett's claim that UDP isn't generally dropped by routers, this is the reason he is concerned about this change in BitTorrent. This will force routers to start dropping UDP packets just like TCP packets and it will have a bad affect on other UDP applications that have a good reason to use UDP e.g., they're low/fixed bandwidth or they only send short/small bursts of data which means they benefit by bypassing the overhead of TCP. Bulk file transfer applications shouldn't be bypassing TCP for UDP and even if BitTorrent is well intentioned, such a large change could be risky for the Internet. That's the whole point Bennett is trying to make.
Yes, he has said that UDP is treated differently than TCP, and it makes sense to treat them differently. I know the man we have spoken by phone and in person. It makes no sense to drop UDP packets since it doesn't produce a response from the end-points.
No, routers do not treat UDP and TCP the same. Richard Bennett is a network architect and I trust his assessment of the situation more than I trust your's.
I can assure you I am not making it up. Routers and other network devices typically don't drop UDP packets because UDP end points don't respond like TCP end points which halve their bandwidth whenever a packet isn't delivered. It's also hasn't been necessary to drop UDP packets because traditional UDP applications are typically small bursts of data or low/fixed bandwidth applications like VoIP and online gaming. Now this is all about to change when you get a huge bulk transfer application like BitTorrent which accounts for a significant portion of the Internet's traffic.
The client application can't know about congestion in the core of the network, so it breaks control at the core of the Internet where there's less management. If you read the article fully, this would have been apparent.
Real-time applications use UDP because they have built-in bandwidth caps and they don't burst to the full capacity of the network like file transfer applications. It's dangerous to put P2P on UDP on a very large scale and it will require a massive change in the core of the Internet to deal with this new behavior.
Looks like it needs a hole in the floor so you can stick your feet out the bottom and help accelerate the car. If you look at the first video they have in link, they had to push it to go.
The amount of energy you can put in to compressed air is pretty lousy and as someone else already mentioned above, you'd lose a lot of heat energy and you have to deal with the freezing effect when you begin to release the air.
Governments get to tax but that means they have an obligation to help provide the infrastructure. Is the government going to contribute anything to that virtual world?
I use to be a senior IT admin/engineer for a good size company. Even our remote workers who used remote site syncronization backup only accounted for about 10 GB per month. Just because you have 200 GBs of data to backup does NOT mean you transfer that much data a month since all of these backup applications only replicate the data that has been changed.
If that's not enough for a particular business user, they can pay for a business class connection or pay the $1/GB overage charge or get a different provider if they think they can get cheaper volume.
Business people are low volume people and most of them would probably be under 2GB per month. It's only when you start downloading videos that you run in to these problems.
The FSB didn't prevent Core 2 from dominating the 1 to 2 socket market (with exception of some high performance computing applications) in performance. The FSB was even OK for 4 socket Tigerton and even the current 6-core Dunnington Core Microarchitecture products for transaction servers. Where the FSB failed to deliver for Intel's Core 2 was primarily the 4-socket market because it was starving the processor. Intel kept using brute force clock speed to make the FSB good enough (not great) to keep up with the Core 2, e.g. the Stoakley platform with fully buffered DDR2-800 support.
FSB was NOT good enough to keep up with the Nehalem and the move away from FSB architecture was absolutely required. So no, they should not have gotten rid of FSB sooner because the Core 2 was an absolute success these last two years. I think there was a project that would have married Quick Path to a Core microarchitecture chip but it was killed off.
So in hindsight, Intel's timing on the demise of FSB appears to be just right.
The 2 networks must be of equal value to each other, and peering to a large Tier 1 is essentially a partial transit because it's a large chunk of the Internet you're accessing. If one operator doesn't want to peer, they have every right to stop peering. You cannot hold a gun to people's heads and say "you will peer with anyone" regardless of whether they offer equal value or not.
Cogent misrepresented their capability to Sprint during the trial, then they lied to the media about the existence of a settlement free peering agreement. Sprint had warned Cogent to either pay for a connection to Sprint or route somewhere else to Sprint's network, Cogent refused to act. Your fundamental assumption that all peering arrangements MUST be free is just plain wrong.
So if I stopped paying for my web server's bandwidth, my fans should complain to their ISP that they're not giving me free bandwidth and that they should stop "double dipping"? Sorry buddy, you don't seem to understand how the Internet works.
Internet is a mixure of settlement and settlement-free peering arrangements. Every tier 1 provider that gets free peering has an obligation to maintain and upgrade the backbone of the Internet which is costly. We can't have tier 1 providers free loading because that means customers who aren't free loading have to pick up the slack. The best explanation of peering is here http://tech.slashdot.org/comments.pl?sid=1015917&cid=25608479.
No, Sprint was fearing for Cogent's customers and they feared Cogent would break the connection in a bad way by allowing the packets to go in to a black hole. That's exactly what they did and your argument is just plain nonsense. Sprint kept the free connection without a contract in good faith hoping to resolve the situation without affecting any customers.
These free loading companies really do offer cheaper service because they are stealing bandwidth. Slashkitty is essentially arguing that it's cheaper to buy a car from a car thief and technically he's right because I can probably buy a nice car for 1/4th the price if I buy it from a thug who just stole the car. What's actually happening is that he's just rationalizing immoral and illegal behavior and justifying it under the banner of the little guy getting something back from the evil corporations.
It's the same crazy logic with all the people in these threads arguing that any little network should be able to peer for free with any Tier 1. It's the crazy logic that if I rented a little rack space at a peering hotel for $200 a month, I should be able to tap in to all the tier 1 providers with my Gigabit Ethernet Interface and be equals with all the other tier 1 providers. What these people are really doing is that they're rationalizing theft.