If you look at the radiation pattern for Wi-Fi (or any spread spectrum) it has signal concentrated over a range, but there are harmonics and side lobes and out of band leakage -- it has to be within certain tolerances, but it's allowable. So if you're centered on channels 5 and 6, there will be slop into 1 and 11, but most devices are designed to have the smallest amount of slop.
I didn't use this information in the article. My Seattle Times column is called Practical Mac, and so I focus on utility not the business case. I checked back on my notes from the briefing, and I'm sure what they told me was very similar to other reporters.
I write a regular newspaper column about the Mac for The Seattle Times, and had a briefing with an Apple iTunes product manager back in mid-October. I asked whether there would be an affiliate model with iTunes in which referring visitors to specific albums or songs would generate a commission.
The product manager said very clearly, on the record, as he and other Apple people have over the last several weeks, that the margin is razor thin with iTunes, and that they're running the service in order to sell iPods and encourage people to use Macs. They believe that the artists make money on the deal (how much is another issue), and that because they're selling so much related hardware, that's their real business.
So there's no real story here. Apple hasn't been hiding the fact. I mean, this is a low-margin business anyway. Say Apple was charging $1.09 per song and netting 10 cents each. If they sold 10,000,000 songs per month that would be an extra $1 million. Big woop. So it's better for them to keep margins low and sell their very high-margin hardware.
I can't tell you the number of friends who went out and bought new PowerBooks and iPods recently -- the iTunes store just flipped them out and they gave up their old PC laptop. The music will give Apple a larger hardware marketshare.
Sure, but do you see the problem here on the UI side? That's what my post and Robert's paper is about. The UI implementation of WPA for consumers encourages and allows poor password selection. It doesn't have to.
You're missing the point here: you're sophisticated and understand that poor password choice produces high risk.
Since WPA is susceptible to dictionary attacks, wouldn't you build an interface that would reject poor passwords? Or would you advertise WPA as a way to enter simple passwords? You're smart: you'd build an interface that had crack behind it and a good dictionary, or at least required 20 digits and some punctuation.
Since the marketing folks and interface designers are encouraging the use of simple passwords, this dramatically increases the risk to consumers that their networks aren't truly secure.
Anything out of context sounds stupid, dude. In this case, WPA has been advertised as a very secure method of wireless encryption at the link layer that replaces a flawed an cracked method.
WPA, in fact, relies on properly chosen passwords, which is a non-obvious problem given the hashing involved.
You've hit all the nails on the head -- great insight on this topic. The bottom line is that for certain kinds of books, the utility is having the entire book available for easy and high-quality perusal. The hassle factor is too high to produce a samizdat electronic version.
But as the author of several computer books, I have some concerns that when it gets too easy for searchers to find a large chunk of contextual results, they won't buy the book.
This should also tell us of the marginal utility of books: I'll be realistic. If reading one page or two pages of my book fulfills a reader's need for information, then I'm overcharging them for the entire book because I need a higher-than-marginal return to do the vast amount of research necessary to write the thing.
I exchanged email with the CIO at Case Western, and he said they're using both VLANs to segregate traffic and packet shapers to prevent abuse. They've also certainly got a variety of other mechanisms in place to prevent this kind of nonsense.
If you restrict inbound ports, filter traffic, shape packets, and don't offer services besides a pipe, you can certainly deal with anonymous community users.
Great idea -- there's a company called Engim that has a very cool set of chips that allow you to run 3 or more channels of Wi-F at the same time: you can choose to run some using a, b, or g, depending on the configuration.
So you could have one AP with "a" on one of the 8 indoor "a" channel, "b" on a non-overlapping 2.4 GHz channel, and "g" on another one. You could offer "g" twice and "b" once. And so on.
That's not the point here: the point is that no one has actually provided the math to know what the upper potential limit is. Matthew now has.
We all now that throughput doesn't equal raw speed. But saying that 100 Mbps != 100 Mbps doesn't add much to the understanding of building networks, does it?
When I said "armchair speculation," I was referring to the mass of articles that come out that talk about Wi-Fi speeds without actually looking at how the technology works.
Matthew has now provided a baseline. Someone could now perform real-world benchmarks against these theoretical maximums which are built into the standard.
Matthew's numbers provide optimal performance guidelines for network planning. Real performance will, of course, be even lower.
Actually, if Broadcom's 802.11g chips use software-defined radio (SDR), which I believe but am not sure that they do, the FCC won't allow them to offer open access to the hardware because it can then be "redefined" to use spectrum that's not allowed.
This is tricky: you can't say, who cares?, because Broadcom has to as they're the one that will be fined and have their equipment recalled.
You can read about Sam Leffler's work with Atheros that allowed him to create a proprietary hardware abstraction layer and then an API to it. This let Atheros provide (indirectly) Linux, FreeBSD, etc., support without violating FCC rules. It gave them an arm's length distance, while licensing just to Sam the hardware details. The HAL has to stay a black box, Sam said at a BAWUG (Bay Area Wireless User's Group meeting) in April.
Sam's drivers are now part of the FreeBSD tree. So someone needs to be able to cultivate a relationship with Broadcom or convince Broadcom to write a HAL themselves.
The BEFW11S4 is based on a different chipset: the Intersil Prism stuff, not Broadcom's 802.11g chips. I'm not sure about the internals, but I doubt the software on the one will run the other as they're entirely different underlying components. (I don't know about processor, etc., but I believe Broadcom created a reference design, like Intersil, so it's likely to be 100 percent different.)
You're so entirely wrong. Many universities and corporations are banning the CONCEPT of peer-to-peer networking, or any kind of collaborative filesharing.
You're not following the news to make the statements you're making.
If you use BT and you wind up with illegal content on your machine, even in parts, you're certainly subject to fines and arrest, just as with Kazaa, et al.
What you're saying isn't unreasonable, it's just not how companies and institutions and government is coping with file sharing at the moment.
I keep saying this, after my own bandwidth blowout, but BitTorrent isn't generally appropriate. It's a great idea and I have no critique on the implementation, but many people are in situations where running a program like BitTorrent could get them arrested, fired, fined, or expelled.
BitTorrent is a P2P-style app, even though it can have a specific aim in mind that's not illegal filesharing, and the vast majority of people actually are under an AUP (acceptable use policy) or EULA or whatever that prevents them from acting as a host -- even a distributed one.
If you're a college student and you ran BitTorrent, I'd expect you'd have your privileges revoked REGARDLESS of the material that was on your system.
This is not a good state of affairs, nor do I think it's the right state of affairs. But it's reality.
When you suggest BitTorrent, you might also be inflicting a lot of ancillary social problems along with the technical solution.
These are excellent elaborations -- let clarify that I mean that for Bluetooth to be successful, it needs to be universally as simple as your experience, and to have utility that doesn't require massive deployment of resources. Wi-Fi is pretty simple to use, and it's more useful, the more nodes, even though it's very useful with just two nodes.
I have a T68i phone, and what you describe as "telling the two to connect" requires diving down into the T68i menu through several screens (all easy enough, but still, those are steps) and then choosing Discoverable. You have to know that when you enter the passphrase to pair the T68i, that the passphrase uses one of three input methods on the phone -- you don't get access to the rotation of text characteres by continuously pressing the same key, for instance, but use a less-common T68i method for entering, so i rely on numbers.
Under Windows, even with a single adapter, you have to setup and choose several options to get the phone to hook up. It mostly works. But the problem is that when you start writing down instructions for someone to pair and use the devices, you easily get into 30 or 40 steps even for the T68i and a Windows or Mac computer -- even if those steps are choose Menu A. Choose Menu B. Click OK. Go to the other computer. I may have too many discrete items on my steps' list.
I wrote a rebuttal to Frankston on my Wi-Fi web log a few days ago (archive link):
Legendary computer guru Bob Frankston says Bluetooth failed: I'd argue that it still could be saved. Bluetooth required many different pieces to be useful, some of which needed massive investment and retooling. For instance, Microsoft only offers limited Bluetooth features (dial-up networking, cable replacement, input device), so Windows users who try to use Bluetooth may require special drivers for individual devices, and have a horrible experience compared to Mac users. Apple has integrated and sophisticated Bluetooth support since Mac OS X 10.2 last August (it just got updated today, too). Apple doesn't yet support printing.
Wi-Fi got the kickstart in that two Wi-Fi devices (an access point and a client) make Wi-Fi worthwhile. Add a second, a third, a 10th client, and it becomes indispensible. Put it in a public place, and you've got a new industry. Microsoft gave Wi-Fi full support in Windows XP; Apple way back in 1999 in Mac OS 8.
Wi-Fi's utility grows as more distinct locations are added -- even if it's just your home, favorite coffeeshop, work. Bluetooth requires many devices, all of which can talk to each other, and OS support, to be minimally useful and doesn't benefit from widespread deployment.
Setting up Wi-Fi can sometimes be complicated, but generally a default DHCP client configuration get you most of the way there, and then you login if it's an account-based service. Bluetooth's configuration can have 30 or 40 steps just to get all the devices talking and in the right mode.
Bluetooth is showing up prebuilt into tens of millions of computing units this year: handhelds, laptops, other devices. The tipping point has arrived, and it will either finally catch fire -- probably only if GPRS service becomes affordable -- or burn out.
Bluetooth's big advantages over Wi-Fi were supposed to be cost for the chips, power consumption, and ease of ad hoc setup. None of those except power appear to be true yet!
Comments completely misunderstand throughput
on
802.11g Slows Down
·
· Score: 3, Interesting
The encoding is at 54 Mbps: number of symbols per second, right? The throughput is the actual data rate that contains information exclusive of error correction and framing.
802.11g has produced 10 to 25 Mbps of throughput since they started working with 54 Mbps encodings.
This is a total misunderstanding, unfortunately, of both the article (which states the problem almost correctly) and its consequences.
Read any good article about 802.11g since it started shipping in draft form, and you'll see that a net throughput of 25 Mbps or less (much less in mixed b/g environments) was always what was produced.
There are two huge advantages by using generated power instead of individual engines:
1. Centrally generated power, even in small cells, can more efficiently control pollution and achieve economies of scale. This isn't always the case, but it's often so. Point-source pollution is more readily captured and remediated.
2. Improvements in generation and reduction in pollution from generation can happen relatively rapidly, over years or a decade, where cars can stay on the road for several decade. I saw figures a few years ago in which a small percentage of cars on the road did, in fact, generate the majority of pollution because most of those cars were old smoke spewers.
You're definitely right that you have to track the entire energy and pollution and materials cost of everything to understand its gestalt effects. There was a study a few years ago comparing disposable and reusable diapers, and the results were interesting. If you don't think that throwing things away is a problem -- that is, if you believe that landfills have plenty of space -- disposables came out way ahead in energy and materials. If you want a fully closed system, then cotton diapers are better, but they do use an awful lot of infrastructure: water, detergent, gasoline to transport them (for services).
I discovered that because my reverse DNS lookup (in-addr.arpa listings) contained "dsl" as part of them, even though I had a business DSL account, I was having mail from my mail server blocked because of this idiocy: I supposedly had "dynamic" addresses, even though I was a static-assigned business.
Fortunately -- at least for the moment -- the solution was to have my very excellent ISP, Speakeasy, remap my/26 Class C's addresses to "real" lookups on my own domain, like f.domain.com, g.domain.com, etc.
a) it wasn't free, it was part of the cost of the thing he was attending and was promised by the value assigned to it. He paid to attend
b) Microsoft is in the position of suing people without proper licenses. If this guy worked in a corporation, if an auditing committee came through and found the disc, he would be reprimanded and/or fired. He's at a university: he could be fined, sanctioned, or expelled.
I signed up for Habeas more because I wanted to help essentially fund their ability to sue spammers. I figured it would be a very short period of time before someone violated their trademark and copyright.
If Habeas takes off, then everyone's headers will have Habeas lines in them, making SpamAssassin even more useful. If their spam suit succeeds, then spammers will be too freaked out about judgements to include Habeas headers.
Of course, it won't solve spam, but anything that reduces volume and immunizes email -- spam can't necessary mutate against Habeas's particular immunity -- has a positive benefit.
SpamAssassin now filters out about 95 percent of the spam I used to get. Since installing it in January, I believe I have saved myself several hours of deleting and filtering email, reduced my download time for email when I'm on the road (even headers), and made my email box so delightfully clean.
And I have received not a single call or follow-up from someone whose email wasn't received that should have been. That is, no false positives at a level that I filter to/dev/null.
Slashdot Mirror
If you look at the radiation pattern for Wi-Fi (or any spread spectrum) it has signal concentrated over a range, but there are harmonics and side lobes and out of band leakage -- it has to be within certain tolerances, but it's allowable. So if you're centered on channels 5 and 6, there will be slop into 1 and 11, but most devices are designed to have the smallest amount of slop.
I didn't use this information in the article. My Seattle Times column is called Practical Mac, and so I focus on utility not the business case. I checked back on my notes from the briefing, and I'm sure what they told me was very similar to other reporters.
I write a regular newspaper column about the Mac for The Seattle Times, and had a briefing with an Apple iTunes product manager back in mid-October. I asked whether there would be an affiliate model with iTunes in which referring visitors to specific albums or songs would generate a commission.
The product manager said very clearly, on the record, as he and other Apple people have over the last several weeks, that the margin is razor thin with iTunes, and that they're running the service in order to sell iPods and encourage people to use Macs. They believe that the artists make money on the deal (how much is another issue), and that because they're selling so much related hardware, that's their real business.
So there's no real story here. Apple hasn't been hiding the fact. I mean, this is a low-margin business anyway. Say Apple was charging $1.09 per song and netting 10 cents each. If they sold 10,000,000 songs per month that would be an extra $1 million. Big woop. So it's better for them to keep margins low and sell their very high-margin hardware.
I can't tell you the number of friends who went out and bought new PowerBooks and iPods recently -- the iTunes store just flipped them out and they gave up their old PC laptop. The music will give Apple a larger hardware marketshare.
Sure, but do you see the problem here on the UI side? That's what my post and Robert's paper is about. The UI implementation of WPA for consumers encourages and allows poor password selection. It doesn't have to.
You're missing the point here: you're sophisticated and understand that poor password choice produces high risk.
Since WPA is susceptible to dictionary attacks, wouldn't you build an interface that would reject poor passwords? Or would you advertise WPA as a way to enter simple passwords? You're smart: you'd build an interface that had crack behind it and a good dictionary, or at least required 20 digits and some punctuation.
Since the marketing folks and interface designers are encouraging the use of simple passwords, this dramatically increases the risk to consumers that their networks aren't truly secure.
Anything out of context sounds stupid, dude. In this case, WPA has been advertised as a very secure method of wireless encryption at the link layer that replaces a flawed an cracked method.
WPA, in fact, relies on properly chosen passwords, which is a non-obvious problem given the hashing involved.
You've hit all the nails on the head -- great insight on this topic. The bottom line is that for certain kinds of books, the utility is having the entire book available for easy and high-quality perusal. The hassle factor is too high to produce a samizdat electronic version.
But as the author of several computer books, I have some concerns that when it gets too easy for searchers to find a large chunk of contextual results, they won't buy the book.
This should also tell us of the marginal utility of books: I'll be realistic. If reading one page or two pages of my book fulfills a reader's need for information, then I'm overcharging them for the entire book because I need a higher-than-marginal return to do the vast amount of research necessary to write the thing.
So it's not clear cut from any angle.
I exchanged email with the CIO at Case Western, and he said they're using both VLANs to segregate traffic and packet shapers to prevent abuse. They've also certainly got a variety of other mechanisms in place to prevent this kind of nonsense.
If you restrict inbound ports, filter traffic, shape packets, and don't offer services besides a pipe, you can certainly deal with anonymous community users.
Case is offering free access to people who aren't associated with Case. That's why.
Great idea -- there's a company called Engim that has a very cool set of chips that allow you to run 3 or more channels of Wi-F at the same time: you can choose to run some using a, b, or g, depending on the configuration.
So you could have one AP with "a" on one of the 8 indoor "a" channel, "b" on a non-overlapping 2.4 GHz channel, and "g" on another one. You could offer "g" twice and "b" once. And so on.
That's not the point here: the point is that no one has actually provided the math to know what the upper potential limit is. Matthew now has.
We all now that throughput doesn't equal raw speed. But saying that 100 Mbps != 100 Mbps doesn't add much to the understanding of building networks, does it?
When I said "armchair speculation," I was referring to the mass of articles that come out that talk about Wi-Fi speeds without actually looking at how the technology works.
Matthew has now provided a baseline. Someone could now perform real-world benchmarks against these theoretical maximums which are built into the standard.
Matthew's numbers provide optimal performance guidelines for network planning. Real performance will, of course, be even lower.
Actually, if Broadcom's 802.11g chips use software-defined radio (SDR), which I believe but am not sure that they do, the FCC won't allow them to offer open access to the hardware because it can then be "redefined" to use spectrum that's not allowed.
This is tricky: you can't say, who cares?, because Broadcom has to as they're the one that will be fined and have their equipment recalled.
You can read about Sam Leffler's work with Atheros that allowed him to create a proprietary hardware abstraction layer and then an API to it. This let Atheros provide (indirectly) Linux, FreeBSD, etc., support without violating FCC rules. It gave them an arm's length distance, while licensing just to Sam the hardware details. The HAL has to stay a black box, Sam said at a BAWUG (Bay Area Wireless User's Group meeting) in April.
Sam's drivers are now part of the FreeBSD tree. So someone needs to be able to cultivate a relationship with Broadcom or convince Broadcom to write a HAL themselves.
The BEFW11S4 is based on a different chipset: the Intersil Prism stuff, not Broadcom's 802.11g chips. I'm not sure about the internals, but I doubt the software on the one will run the other as they're entirely different underlying components. (I don't know about processor, etc., but I believe Broadcom created a reference design, like Intersil, so it's likely to be 100 percent different.)
You're so entirely wrong. Many universities and corporations are banning the CONCEPT of peer-to-peer networking, or any kind of collaborative filesharing.
You're not following the news to make the statements you're making.
If you use BT and you wind up with illegal content on your machine, even in parts, you're certainly subject to fines and arrest, just as with Kazaa, et al.
What you're saying isn't unreasonable, it's just not how companies and institutions and government is coping with file sharing at the moment.
I keep saying this, after my own bandwidth blowout, but BitTorrent isn't generally appropriate. It's a great idea and I have no critique on the implementation, but many people are in situations where running a program like BitTorrent could get them arrested, fired, fined, or expelled.
BitTorrent is a P2P-style app, even though it can have a specific aim in mind that's not illegal filesharing, and the vast majority of people actually are under an AUP (acceptable use policy) or EULA or whatever that prevents them from acting as a host -- even a distributed one.
If you're a college student and you ran BitTorrent, I'd expect you'd have your privileges revoked REGARDLESS of the material that was on your system.
This is not a good state of affairs, nor do I think it's the right state of affairs. But it's reality.
When you suggest BitTorrent, you might also be inflicting a lot of ancillary social problems along with the technical solution.
These are excellent elaborations -- let clarify that I mean that for Bluetooth to be successful, it needs to be universally as simple as your experience, and to have utility that doesn't require massive deployment of resources. Wi-Fi is pretty simple to use, and it's more useful, the more nodes, even though it's very useful with just two nodes.
I have a T68i phone, and what you describe as "telling the two to connect" requires diving down into the T68i menu through several screens (all easy enough, but still, those are steps) and then choosing Discoverable. You have to know that when you enter the passphrase to pair the T68i, that the passphrase uses one of three input methods on the phone -- you don't get access to the rotation of text characteres by continuously pressing the same key, for instance, but use a less-common T68i method for entering, so i rely on numbers.
Under Windows, even with a single adapter, you have to setup and choose several options to get the phone to hook up. It mostly works. But the problem is that when you start writing down instructions for someone to pair and use the devices, you easily get into 30 or 40 steps even for the T68i and a Windows or Mac computer -- even if those steps are choose Menu A. Choose Menu B. Click OK. Go to the other computer. I may have too many discrete items on my steps' list.
I wrote a rebuttal to Frankston on my Wi-Fi web log a few days ago (archive link):
Legendary computer guru Bob Frankston says Bluetooth failed: I'd argue that it still could be saved. Bluetooth required many different pieces to be useful, some of which needed massive investment and retooling. For instance, Microsoft only offers limited Bluetooth features (dial-up networking, cable replacement, input device), so Windows users who try to use Bluetooth may require special drivers for individual devices, and have a horrible experience compared to Mac users. Apple has integrated and sophisticated Bluetooth support since Mac OS X 10.2 last August (it just got updated today, too). Apple doesn't yet support printing.
Wi-Fi got the kickstart in that two Wi-Fi devices (an access point and a client) make Wi-Fi worthwhile. Add a second, a third, a 10th client, and it becomes indispensible. Put it in a public place, and you've got a new industry. Microsoft gave Wi-Fi full support in Windows XP; Apple way back in 1999 in Mac OS 8.
Wi-Fi's utility grows as more distinct locations are added -- even if it's just your home, favorite coffeeshop, work. Bluetooth requires many devices, all of which can talk to each other, and OS support, to be minimally useful and doesn't benefit from widespread deployment.
Setting up Wi-Fi can sometimes be complicated, but generally a default DHCP client configuration get you most of the way there, and then you login if it's an account-based service. Bluetooth's configuration can have 30 or 40 steps just to get all the devices talking and in the right mode.
Bluetooth is showing up prebuilt into tens of millions of computing units this year: handhelds, laptops, other devices. The tipping point has arrived, and it will either finally catch fire -- probably only if GPRS service becomes affordable -- or burn out.
Bluetooth's big advantages over Wi-Fi were supposed to be cost for the chips, power consumption, and ease of ad hoc setup. None of those except power appear to be true yet!
That's free as in free association, not free as in free to be you and me, as he never said.
To quote Ripping Yarns, 1:1 isn't a model.
The encoding is at 54 Mbps: number of symbols per second, right? The throughput is the actual data rate that contains information exclusive of error correction and framing.
802.11g has produced 10 to 25 Mbps of throughput since they started working with 54 Mbps encodings.
This is a total misunderstanding, unfortunately, of both the article (which states the problem almost correctly) and its consequences.
Read any good article about 802.11g since it started shipping in draft form, and you'll see that a net throughput of 25 Mbps or less (much less in mixed b/g environments) was always what was produced.
There are two huge advantages by using generated power instead of individual engines:
1. Centrally generated power, even in small cells, can more efficiently control pollution and achieve economies of scale. This isn't always the case, but it's often so. Point-source pollution is more readily captured and remediated.
2. Improvements in generation and reduction in pollution from generation can happen relatively rapidly, over years or a decade, where cars can stay on the road for several decade. I saw figures a few years ago in which a small percentage of cars on the road did, in fact, generate the majority of pollution because most of those cars were old smoke spewers.
You're definitely right that you have to track the entire energy and pollution and materials cost of everything to understand its gestalt effects. There was a study a few years ago comparing disposable and reusable diapers, and the results were interesting. If you don't think that throwing things away is a problem -- that is, if you believe that landfills have plenty of space -- disposables came out way ahead in energy and materials. If you want a fully closed system, then cotton diapers are better, but they do use an awful lot of infrastructure: water, detergent, gasoline to transport them (for services).
I discovered that because my reverse DNS lookup (in-addr.arpa listings) contained "dsl" as part of them, even though I had a business DSL account, I was having mail from my mail server blocked because of this idiocy: I supposedly had "dynamic" addresses, even though I was a static-assigned business.
/26 Class C's addresses to "real" lookups on my own domain, like f.domain.com, g.domain.com, etc.
Fortunately -- at least for the moment -- the solution was to have my very excellent ISP, Speakeasy, remap my
This fixed that problem.
a) it wasn't free, it was part of the cost of the thing he was attending and was promised by the value assigned to it. He paid to attend
b) Microsoft is in the position of suing people without proper licenses. If this guy worked in a corporation, if an auditing committee came through and found the disc, he would be reprimanded and/or fired. He's at a university: he could be fined, sanctioned, or expelled.
These are real issues.
I signed up for Habeas more because I wanted to help essentially fund their ability to sue spammers. I figured it would be a very short period of time before someone violated their trademark and copyright.
/dev/null.
If Habeas takes off, then everyone's headers will have Habeas lines in them, making SpamAssassin even more useful. If their spam suit succeeds, then spammers will be too freaked out about judgements to include Habeas headers.
Of course, it won't solve spam, but anything that reduces volume and immunizes email -- spam can't necessary mutate against Habeas's particular immunity -- has a positive benefit.
SpamAssassin now filters out about 95 percent of the spam I used to get. Since installing it in January, I believe I have saved myself several hours of deleting and filtering email, reduced my download time for email when I'm on the road (even headers), and made my email box so delightfully clean.
And I have received not a single call or follow-up from someone whose email wasn't received that should have been. That is, no false positives at a level that I filter to