In Illinois, a corporation of any size MUST be represented by a lawyer in small claims. You can not represent "yourself", because even with a small S-corp, YOU are a different legal entity than the company.
As a person who runs a network, somewhere... i won't tell you where.:)... we don't like p2p apps. It's not because they use 40-70% of the bandwidth, that's not the problem. The problem is that apps like skype, or gnutella, or (endless list) have supernodes, nodes that notice we have a fat network and elevate themselves to become servers for the rest of the p2p network.
Someone earlier used an analogy: 'Let us say I run a restaraunt and have been selling "all you can drink" coffee but I had been providing only thimble size cups.' Good start. Our problem isn't that you bring your own cup. Our problem is that you're sitting near an open window, and ordering a dozen coffees at once. Large ones. And handing them out to everyone walking along.
We don't mind providing the bandwidth to our legitimate users, that's why we're here. We have a problem paying for bandwidth to provide services for people who aren't our constituents or customers. We're especially troubled by that because we suddenly become the focus of all those 4 letter groups that we love to hate here, who come knocking on our doors because they seem to think we're "enabling" copyright theft or "serving" it. And our lawyers, like every other lawyer in the world, don't like these discussions because they don't KNOW that what we're doing will be a slam dunk in court and then they get cranky with us.
So we don't mind the concept of p2p. I assume you're doing things legally because you're all moral people, right?:) But stop giving away all my bandwidth to some dork in somalia, because I'm the one who has to explain why the business applications are running slow. And the people with the money don't seem to think "just buy more" is a good idea when our budget is tight.
Very nice technical article, although one thing you missed is that T1 describes the end point signally (24 time slots of x length, etc). DS1 describes the traditional carries-a-T1-on-4-wires that most people think of a T1 as. Small thing really.
But one thing I'm amazed that noone has noticed is that one reason a T1 (or T3, etc) circuit is so expensive: It's a tariffed (read: regulated!) circuit!
Your state utilities board or legislature sets maximum costs for each tariffed circuit, like a phone dial tone line, an alarm circuit, and T1. Therefore, they're high, because the telco petitions for the most expensive possible scenario since they can't modify that price. No reason to lose money anywhere even if you'd make it up on volume!
Newer technologies like DSL, metropolitan ethernet-over-sonnet, FIOS, etc... they're not tariffed. They're priced at whatever level will get them to sell.
Wear leveling will have the effect of keeping the writes evenly distributed across the flash. What it won't do is save you from reaching your max-write counts. While many flashes are good for 1000+ writes per block, writing a journal entry for each change is going to dramatically increase the speed you reach that number.
Further, I'd point out that you shouldn't be writing to the CF much except during the setup phase. The reason you want a journal is to recover from a failure before the disk is fully written to and synced; if you never write to the disk, what is a journal saving you from?
I personally have great experience with EXT2 on CF, so it's what I recommend.
Actually, rereading your original comment, I'm not sure my experiences actually are anything like yours.
While we update a couple files a few times a month, we're not writing a database to the cf over and over.
Still, we like the CF based solution-- if we have a hard ware failure, it's quick to swap out, and if the CF fails, we have archives of the file systems made automatically weekly so it's just a matter of untarring to a disk, re lilo'ing, and install.
I run about a dozen machines running pebble (and soon, voyage) which are both debian based CF distros, and we don't have much problem with them at all. They get powered on and off a lot, I do quite a few live updates of specific files, etc, no problems.
Is it possible you're not actually suffering FS corruption but instead having problems with CF that just isn't suited for the task? We started this project using kingston, which is good flash for cameras, but we ran into lots of dead sectors. We've been using Lexar since, with no issues at all (of the 13 machines, i think we've lost 1 sector in 2 years).
Let's not confuse "sometimes things don't work as expected" with "it never works! it's a disaster!!11!L".
I'm not the biggest cisco fan in the world, and given sufficient quantities of beer, i can tell dozens of stories of how cisco couldn't or wouldn't fix a particular problem. We even have a free router because it was easier to just give us a different router where the problem didn't happen than fix it on the platform we bought.
But keep this in mind: We have a free router because it fixed the problem. And for every "this is the stupidest support story ever", the bottom line is ALWAYS it was a p3 or p4 issue. Something annoying but we could live with it if my primary goal at work wasn't to solve or whine away every obstacle to the utopian network.
Every P1 or P2 issue i've ever reported, and my CCO account is long and has many notes about my character i'm not allowed to read:), every single one has been solved efficiently and with serious concern for the customer. P1s that lasted more than a few days came with every morning conference calls with my tac engineers giving me status.
Cisco provides good software (with bugs), good support (with bugs), and sells it using people (good grief, they're buggy). And we, the end users, are often buggy too, which needs to be kept in mind as well.
An open source router sounds nice for the times you're building a small business that has no money to buy something expensive (or a business reason to do so). I'm not going to waste my time bashing it, it's just that it doesn't fit into what I do.
When I run into a problem where a cam table is corrupted with a particular rediclously contrived but business critical data stream, I need it fixed and I need it fixed fast, and I'm not paid to decode and rewrite layer 2 forwarding to PCI-X interfaces. So for me? It's just not right.
And dude, don't get me started on running gigabit over cat 3...:)
An all wireless network for a 100+ person office may be buying a lot of trouble. For example, one user running a multicast app (think "ghost") means the whole network will become unavailable. One user with a 2.4Ghz phone or someone making popcorn in the corner kitchenette and you're going to have a lot of drop outs. One user with a PDA running B and your shared 22Mb/s (max) tput G network suddenly drops to 14Mb/s or less.
I'd definitely go with wired jacks with wireless available for convinience.
If you're dead set on this, though, you might actually be ok if you want to invest in a Meru network, though. One thing that's very nice about their product line is that their access points actually use CTS/RTS to control who's talking at once to guarantee bandwidth availability, so you might not be dead. But that's not a cheap solution. They are at this time unique in the wireless industry with this functionality. They're also the only vendor in the industry we've tested where having a B radio associated doesn't significantly drop tput (our testing showed that one B radio dropped G tput to about 20Mb/s).
Re:I've heard...
on
Router Wars
·
· Score: 3, Informative
As a few other people have already pointed out, Cisco's IOS supports every ROUTING protocol currently in use out there, assuming you purchased the correct load (not every load supports IS-IS, for example).
Any "fast" router runs almost exclusively in hardware, not in software. Writing hardware code IS hard, because you're trying to do a LOT of often conflicting things (forward packets, filter packets, qos packets). But anytime a CPU gets involved in a packet forward, you're running SLOW. Even OLD cisco routers leap from a measurement of lots of K packets per second to lots and lots of M packets per second just by hardware routing. One of the primary values of advanced Cisco certifications is learning what causes software forwarding-- nothing turns your expensive fast router into a super slow expensive router faster than leaving DCEF for fast switching!
Last, I'm sorry, but neither Linux nor *Bsd's QOS or filtering features are "better" than Cisco's. They are, for the most part, attempts to duplicate the features that are already present in hardware on most Cisco and other routers, or firewalls as appropriate. I am NOT saying that iptables or pf aren't worth anything; I'm just pointing out that you have a very odd view of the state of the art....from 8 years ago.
You DO get a lot more flexibility with iptables or pf at a much lower cost, though. You can do things with iptables on a via 600mhz cpu at 30-40Mb/s that you need $120k worth of combined routers and firewalls to do with more "dedicated" hardware. This isn't always a bad thing for the networking vendors, and it isn't always a good thing for the little PC. You're going to scale much higher on a "real" network after a certain point. You're going to get a lot more flexibility at a lower point with a FOSS router/fw, with the caveat that the scalability is much much harder for an enterprise network.
As with everything else, there is no One True Solution. Pick what works.
Unfortunately, you won't find any switch devices which will fragment packets based on link MTU.
By intentional design, fragmentation only happens on layer 3 devices like routers (or L3 switches, I guess). True layer 2 switches like a home gig-e switch will not do so.
The "fix", and the best practice, is to always keep the MTU the same inside each subnet. If you want a jumbo frame network, put a router in there between the mtu boundaries.
The reason this is done is that fragmentation is truly a layer 3 issue-- while there is a fragmentation field in the IP header (and many other L3 protocols), there is nothing of the sort in the ethernet frame header. A device would have to be smart enough to actually rewrite the packets at the L3 level and regenerate them in order to keep the layer2 checksums correct....and at that point, you have a router again.
it's blocked because it's *BAD*. I honestly could care less what you're uploading or downloading, so long as we don't get a legal letter from someone (then we have to respond).
Recent popular p2p apps have a serious problem: they general thousands of flows (source:destination connections) to and from your host, as people connect and disconnect. Modern appliance firewalls, rate limiters, and other pieces of networking hardware all are built arround tracking and mapping flows to permit lists, rate lists, or just routing table entries.
Rates of 400-1000 flows/second are not uncommon for the most popular apps, and these cause the firewalls, etc, to simply fall over and die, shutting down the network for everyone.
That's bad, and then we networking types have to block or limit a port, and then you get mad at us "network nazis". Keeping the wan up when it's hundreds of Mb/s is *hard*.
>The main reason to use fiber for risers is that then you have a better upgrade path for your backbone connections. In most cases that is the ONLY valid reason.
Not at all.
Fiber is the preferred connection between any two network closets for a host of reasons.
The first and foremost is electrical isolation. Larger network designs should always be concerned with electrical isolation; it is not at all uncommon to have a shorted out ethernet card/cable burn out a port on a switch. These days, with power over ethernet injecting thousands of extra watts of power into chassises, isolating between devices is *extremely* good sense.
Reusability of cable is a close second.
A third reason is actually long term cost of ownership-- while it costs significantly more to terminate a cable, the half life of a UTP cable is much shorter than that of wall-rated jacketed cable. Gel filled cable bundles tend to be much more resistant to kinks or other damange, and the jackets are much more resistant to corrosion.
Seems to be some interest, so here's a few comments:
802.3af is a nice little spec; it covers a number of different options. I'm not an electrical guy, so I can't spec the power, but it's low voltage, low wattage. You have to do this for all sorts of reasons, not the least of which is that if the voltage is high, you run into local municiple code issues!
Us networking types don't want to get taking over by IBEW.:)
The most common usage is power on pin 4,5,7 & 8: the pairs not used by ethernet. This is the type of power most commonly provided by in-line power addition devices, becuase you're "pretty sure" there's nothing on the other side on those wires (unless there's gige in use, of course). The spec says that this is the recommended type when a device injects power between the switch and end device.
A growing usage is to provide power on 1,2,3&6, which the detailed reader will note is also the pairs used for 10baseT and 100baseTX. The trick here is that, just like a switch/hub looks for a link pulse before it brings up link, it also looks for a specific tone to be looped back by the device before it provides power. No loopback tone, no power back, no dead ethernet card.
The biggest confusion with this technology, though, is pre-standard implementations. Cisco's existing Cisco Inline Power standard is very very close, but as usual, not exactly the same (it depends on CDP for some aspects to function, and you have to license CDP, so...).
Many use the unused pairs; this isn't so bad. Few things can be hurt by that. Cisco's 76xx IP phones can take it both ways, over the unused pairs or data pairs.
There IS a catch with those phones, though-- I'm told they reverse the pins for power compared to the spec, so an dongle is required in line for your IP phone so that it gets the right power from a TRUE 802.3af compliant provider. I'll ask arround-- a coworker has the dongle, but I'm not 100% sure which cisco product it's for (for those wondering, this is different than the power-injection device).
On the theoretical side: Maximum real-world throughput for G is about 12-18Mb/s or so. Maximum real-world throughput for A is about 26-30Mb/s or so, depending on what you're pushing. So your peak potential throughput would be something like 48Mb/s.
However, on a much more realistic plane, you're not going to be able to do this anyway-- there is only one chip that drives the radio, and the chip isn't designed for dual actiivation, let alone load balancing or anything "fun".
This access point isn't going to help you use both B and G on it's own..
Unfortunately, it is part of the standard that a G class access point will drop down to B if it sees any B style encoding.
You can work arround this by setting the configuration of (most) APs to completely IGNORE B, but that's not very friendly.
One solution, and the solution I recommend in the case where you REALLY want to have G out there, is to configure a "B" base station on one channel (1), and a G base station on another (6). Configure the G channel with a different SSID and hard-configure it not to drop down.
You now have a G only system available, and older B users are still capable of associating.
I would also point out that you must also hard code your adapter to run in only G-- it also will follow the standard and drop down.
Frankly, in my personal opinion, you're better off buying a combo A/B access point and also a combo A/B card. Both are significantly cheaper, and the A standard is also significantly FASTER in real-world performance (to the tune of 2-5x better REAL throughput compared to G.)
Slashdot Mirror
In Illinois, a corporation of any size MUST be represented by a lawyer in small claims. You can not represent "yourself", because even with a small S-corp, YOU are a different legal entity than the company.
As a person who runs a network, somewhere... i won't tell you where. :) ... we don't like p2p apps. It's not because they use 40-70% of the bandwidth, that's not the problem. The problem is that apps like skype, or gnutella, or (endless list) have supernodes, nodes that notice we have a fat network and elevate themselves to become servers for the rest of the p2p network.
:) But stop giving away all my bandwidth to some dork in somalia, because I'm the one who has to explain why the business applications are running slow. And the people with the money don't seem to think "just buy more" is a good idea when our budget is tight.
Someone earlier used an analogy: 'Let us say I run a restaraunt and have been selling "all you can drink" coffee but I had been providing only thimble size cups.' Good start. Our problem isn't that you bring your own cup. Our problem is that you're sitting near an open window, and ordering a dozen coffees at once. Large ones. And handing them out to everyone walking along.
We don't mind providing the bandwidth to our legitimate users, that's why we're here. We have a problem paying for bandwidth to provide services for people who aren't our constituents or customers. We're especially troubled by that because we suddenly become the focus of all those 4 letter groups that we love to hate here, who come knocking on our doors because they seem to think we're "enabling" copyright theft or "serving" it. And our lawyers, like every other lawyer in the world, don't like these discussions because they don't KNOW that what we're doing will be a slam dunk in court and then they get cranky with us.
So we don't mind the concept of p2p. I assume you're doing things legally because you're all moral people, right?
Very nice technical article, although one thing you missed is that T1 describes the end point signally (24 time slots of x length, etc). DS1 describes the traditional carries-a-T1-on-4-wires that most people think of a T1 as. Small thing really.
But one thing I'm amazed that noone has noticed is that one reason a T1 (or T3, etc) circuit is so expensive: It's a tariffed (read: regulated!) circuit!
Your state utilities board or legislature sets maximum costs for each tariffed circuit, like a phone dial tone line, an alarm circuit, and T1. Therefore, they're high, because the telco petitions for the most expensive possible scenario since they can't modify that price. No reason to lose money anywhere even if you'd make it up on volume!
Newer technologies like DSL, metropolitan ethernet-over-sonnet, FIOS, etc... they're not tariffed. They're priced at whatever level will get them to sell.
Wear leveling will have the effect of keeping the writes evenly distributed across the flash. What it won't do is save you from reaching your max-write counts. While many flashes are good for 1000+ writes per block, writing a journal entry for each change is going to dramatically increase the speed you reach that number.
Further, I'd point out that you shouldn't be writing to the CF much except during the setup phase. The reason you want a journal is to recover from a failure before the disk is fully written to and synced; if you never write to the disk, what is a journal saving you from?
I personally have great experience with EXT2 on CF, so it's what I recommend.
Actually, rereading your original comment, I'm not sure my experiences actually are anything like yours.
While we update a couple files a few times a month, we're not writing a database to the cf over and over.
Still, we like the CF based solution-- if we have a hard ware failure, it's quick to swap out, and if the CF fails, we have archives of the file systems made automatically weekly so it's just a matter of untarring to a disk, re lilo'ing, and install.
I run about a dozen machines running pebble (and soon, voyage) which are both debian based CF distros, and we don't have much problem with them at all. They get powered on and off a lot, I do quite a few live updates of specific files, etc, no problems.
Is it possible you're not actually suffering FS corruption but instead having problems with CF that just isn't suited for the task? We started this project using kingston, which is good flash for cameras, but we ran into lots of dead sectors. We've been using Lexar since, with no issues at all (of the 13 machines, i think we've lost 1 sector in 2 years).
Let's not confuse "sometimes things don't work as expected" with "it never works! it's a disaster!!11!L".
:), every single one has been solved efficiently and with serious concern for the customer. P1s that lasted more than a few days came with every morning conference calls with my tac engineers giving me status.
:)
I'm not the biggest cisco fan in the world, and given sufficient quantities of beer, i can tell dozens of stories of how cisco couldn't or wouldn't fix a particular problem. We even have a free router because it was easier to just give us a different router where the problem didn't happen than fix it on the platform we bought.
But keep this in mind: We have a free router because it fixed the problem. And for every "this is the stupidest support story ever", the bottom line is ALWAYS it was a p3 or p4 issue. Something annoying but we could live with it if my primary goal at work wasn't to solve or whine away every obstacle to the utopian network.
Every P1 or P2 issue i've ever reported, and my CCO account is long and has many notes about my character i'm not allowed to read
Cisco provides good software (with bugs), good support (with bugs), and sells it using people (good grief, they're buggy). And we, the end users, are often buggy too, which needs to be kept in mind as well.
An open source router sounds nice for the times you're building a small business that has no money to buy something expensive (or a business reason to do so). I'm not going to waste my time bashing it, it's just that it doesn't fit into what I do.
When I run into a problem where a cam table is corrupted with a particular rediclously contrived but business critical data stream, I need it fixed and I need it fixed fast, and I'm not paid to decode and rewrite layer 2 forwarding to PCI-X interfaces. So for me? It's just not right.
And dude, don't get me started on running gigabit over cat 3...
An all wireless network for a 100+ person office may be buying a lot of trouble. For example, one user running a multicast app (think "ghost") means the whole network will become unavailable. One user with a 2.4Ghz phone or someone making popcorn in the corner kitchenette and you're going to have a lot of drop outs. One user with a PDA running B and your shared 22Mb/s (max) tput G network suddenly drops to 14Mb/s or less.
I'd definitely go with wired jacks with wireless available for convinience.
If you're dead set on this, though, you might actually be ok if you want to invest in a Meru network, though. One thing that's very nice about their product line is that their access points actually use CTS/RTS to control who's talking at once to guarantee bandwidth availability, so you might not be dead. But that's not a cheap solution. They are at this time unique in the wireless industry with this functionality. They're also the only vendor in the industry we've tested where having a B radio associated doesn't significantly drop tput (our testing showed that one B radio dropped G tput to about 20Mb/s).
As a few other people have already pointed out, Cisco's IOS supports every ROUTING protocol currently in use out there, assuming you purchased the correct load (not every load supports IS-IS, for example).
Any "fast" router runs almost exclusively in hardware, not in software. Writing hardware code IS hard, because you're trying to do a LOT of often conflicting things (forward packets, filter packets, qos packets). But anytime a CPU gets involved in a packet forward, you're running SLOW. Even OLD cisco routers leap from a measurement of lots of K packets per second to lots and lots of M packets per second just by hardware routing. One of the primary values of advanced Cisco certifications is learning what causes software forwarding-- nothing turns your expensive fast router into a super slow expensive router faster than leaving DCEF for fast switching!
Last, I'm sorry, but neither Linux nor *Bsd's QOS or filtering features are "better" than Cisco's. They are, for the most part, attempts to duplicate the features that are already present in hardware on most Cisco and other routers, or firewalls as appropriate. I am NOT saying that iptables or pf aren't worth anything; I'm just pointing out that you have a very odd view of the state of the art....from 8 years ago.
You DO get a lot more flexibility with iptables or pf at a much lower cost, though. You can do things with iptables on a via 600mhz cpu at 30-40Mb/s that you need $120k worth of combined routers and firewalls to do with more "dedicated" hardware. This isn't always a bad thing for the networking vendors, and it isn't always a good thing for the little PC. You're going to scale much higher on a "real" network after a certain point. You're going to get a lot more flexibility at a lower point with a FOSS router/fw, with the caveat that the scalability is much much harder for an enterprise network.
As with everything else, there is no One True Solution. Pick what works.
mark
Unfortunately, you won't find any switch devices which will fragment packets based on link MTU.
By intentional design, fragmentation only happens on layer 3 devices like routers (or L3 switches, I guess). True layer 2 switches like a home gig-e switch will not do so.
The "fix", and the best practice, is to always keep the MTU the same inside each subnet. If you want a jumbo frame network, put a router in there between the mtu boundaries.
The reason this is done is that fragmentation is truly a layer 3 issue-- while there is a fragmentation field in the IP header (and many other L3 protocols), there is nothing of the sort in the ethernet frame header. A device would have to be smart enough to actually rewrite the packets at the L3 level and regenerate them in order to keep the layer2 checksums correct....and at that point, you have a router again.
mark
it's blocked because it's *BAD*. I honestly could care less what you're uploading or downloading, so long as we don't get a legal letter from someone (then we have to respond).
Recent popular p2p apps have a serious problem: they general thousands of flows (source:destination connections) to and from your host, as people connect and disconnect. Modern appliance firewalls, rate limiters, and other pieces of networking hardware all are built arround tracking and mapping flows to permit lists, rate lists, or just routing table entries.
Rates of 400-1000 flows/second are not uncommon for the most popular apps, and these cause the firewalls, etc, to simply fall over and die, shutting down the network for everyone.
That's bad, and then we networking types have to block or limit a port, and then you get mad at us "network nazis". Keeping the wan up when it's hundreds of Mb/s is *hard*.
>The main reason to use fiber for risers is that then you have a better upgrade path for your backbone connections. In most cases that is the ONLY valid reason.
Not at all.
Fiber is the preferred connection between any two network closets for a host of reasons.
The first and foremost is electrical isolation. Larger network designs should always be concerned with electrical isolation; it is not at all uncommon to have a shorted out ethernet card/cable burn out a port on a switch. These days, with power over ethernet injecting thousands of extra watts of power into chassises, isolating between devices is *extremely* good sense.
Reusability of cable is a close second.
A third reason is actually long term cost of ownership-- while it costs significantly more to terminate a cable, the half life of a UTP cable is much shorter than that of wall-rated jacketed cable. Gel filled cable bundles tend to be much more resistant to kinks or other damange, and the jackets are much more resistant to corrosion.
It's already in use-- powers access points & ip phones. Sure, they're small devices, but an AP can transmit at up to 100mw!
Seems to be some interest, so here's a few comments:
:)
802.3af is a nice little spec; it covers a number of different options. I'm not an electrical guy, so I can't spec the power, but it's low voltage, low wattage. You have to do this for all sorts of reasons, not the least of which is that if the voltage is high, you run into local municiple code issues!
Us networking types don't want to get taking over by IBEW.
The most common usage is power on pin 4,5,7 & 8: the pairs not used by ethernet. This is the type of power most commonly provided by in-line power addition devices, becuase you're "pretty sure" there's nothing on the other side on those wires (unless there's gige in use, of course). The spec says that this is the recommended type when a device injects power between the switch and end device.
A growing usage is to provide power on 1,2,3&6, which the detailed reader will note is also the pairs used for 10baseT and 100baseTX. The trick here is that, just like a switch/hub looks for a link pulse before it brings up link, it also looks for a specific tone to be looped back by the device before it provides power. No loopback tone, no power back, no dead ethernet card.
The biggest confusion with this technology, though, is pre-standard implementations. Cisco's existing Cisco Inline Power standard is very very close, but as usual, not exactly the same (it depends on CDP for some aspects to function, and you have to license CDP, so...).
Many use the unused pairs; this isn't so bad. Few things can be hurt by that.
Cisco's 76xx IP phones can take it both ways, over the unused pairs or data pairs.
There IS a catch with those phones, though-- I'm told they reverse the pins for power compared to the spec, so an dongle is required in line for your IP phone so that it gets the right power from a TRUE 802.3af compliant provider. I'll ask arround-- a coworker has the dongle, but I'm not 100% sure which cisco product it's for (for those wondering, this is different than the power-injection device).
Unfortunately, no.
On the theoretical side: Maximum real-world throughput for G is about 12-18Mb/s or so. Maximum real-world throughput for A is about 26-30Mb/s or so, depending on what you're pushing. So your peak potential throughput would be something like 48Mb/s.
However, on a much more realistic plane, you're not going to be able to do this anyway-- there is only one chip that drives the radio, and the chip isn't designed for dual actiivation, let alone load balancing or anything "fun".
This access point isn't going to help you use both B and G on it's own..
Unfortunately, it is part of the standard that a G class access point will drop down to B if it sees any B style encoding.
You can work arround this by setting the configuration of (most) APs to completely IGNORE B, but that's not very friendly.
One solution, and the solution I recommend in the case where you REALLY want to have G out there, is to configure a "B" base station on one channel (1), and a G base station on another (6). Configure the G channel with a different SSID and hard-configure it not to drop down.
You now have a G only system available, and older B users are still capable of associating.
I would also point out that you must also hard code your adapter to run in only G-- it also will follow the standard and drop down.
Frankly, in my personal opinion, you're better off buying a combo A/B access point and also a combo A/B card. Both are significantly cheaper, and the A standard is also significantly FASTER in real-world performance (to the tune of 2-5x better REAL throughput compared to G.)
Good luck!