To get 802.11n's 300mbps signaling rate, you have to do two spatial streams (a.k.a. 2x2, or 2T2R), 40MHz channels, and a short (400ns) guard interval (short GI). The fact that you're seeing a 144mbps signaling rate indicates that you've got the 2x2 and short GI right, but you're only using 20MHz channels instead of 40MHz.
I know there are some products that refuse to do 40MHz channels in 2.4GHz because that takes up too much of the 2.4GHz ISM band's space, leaving no room for other uses of the band, such as Bluetooth (including your Wii Remotes). But reviewing the specs of your Cisco/Linksys E2000 and those Edimax products, it seems like they should all support 40MHz operation in 2.4GHz.
The IEEE 802.11n spec has a provision for 802.11n devices to signal that they are "40MHz intolerant", to try to get 40MHz-capable 802.11n gear in their area to limit themselves to 20MHz channels. For instance, a laptop with an 802.11n adaptor and a Bluetooth adaptor might signal this when it's using a 2.4GHz 802.11n AP that is 40MHz-capable. However, I'm not aware of any vendors that actually set or honor the 40MHz intolerant bit at this time.
My best guess is that you're hitting an interoperability bug. For some reason, your Edimax clients don't want to join your Cisco/Linksys E2000 using 40MHz channels even though your E2000 is configured for it.
802.11n talks of 40MHz operation in terms of two traditional 20MHz channels used together. The "control" channel is the main channel that both 20MHz and 40MHz-capable clients use, and the "extension" channel is the part that the 40MHz clients use. The extension channel can either be "above" or "below" the control channel, as long as it doesn't go outside the band. For example, if your control channel is 1, your extension channel has to "above", because anything below channel 1 would be below the lowest frequency allowed in the 2.4GHz ISM band. The extension channel has to be contiguous with the edge of the control channel, without overlapping. Because most of the 2.4GHz 802.11 channels overlap, channel 5 is the "above" channel for channel 1. There are varying notations for the control and extension channels. Often the control channel number is given, followed by a [+]1 or a -1 to show that the extension channel is above or below, respectively. So the situation I described as control channel on 1, extension channel on 5, might be shown as "1,1" or "1,+1" or even "1+".
In the US, Canada, and any other country that adopted US FCC-like regulations where we only have 11 2.4GHz channels, there are 14 valid control/extension channel layouts, but only 4 of them are commonly used, because it's a good idea to stick to the non-overlapping channels of 1, 6, and 11.
1,+1 ( 1 & 5) common
2,+1 ( 2 & 6)
3,+1 ( 3 & 7)
4,+1 ( 4 & 8)
5,+1 ( 5 & 9)
5,-1 ( 5 & 1)
6,+1 ( 6 & 10) common
6,-1 ( 6 & 2) common
7,+1 ( 7 & 11)
7,-1 ( 7 & 3)
8,-1 ( 8 & 4)
9,-1 ( 9 & 5)
10,-1 (10 & 6)
11,-1 (11 & 7) common
Europe, or any other region that follows the ETSI regulations, would add the following possibilities:
8,+1 ( 8 & 12)
9,+1 ( 9 & 13)
12,-1 (12 & 8)
13,-1 (13 & 9)
I suppose it's possible that your AP or your clients can't handle every possible valid combination of (control,extension). Or maybe you left your AP on channel auto-selection and it was accidentally auto-selecting an invalid combination like "11,+1". You might try manually setting your AP to "1,+1", as that's a pretty common arrangement, and see if your clients can handle that.
Another thing to check is your encryption type. Make sure you've got AES-CCMP (WPA2) enabled. The RC4 stream cipher engines included in early 802.11 chip hardware (used poorly by WEP, and less poorly by TKIP) generally can't keep up with 802.11n speeds. Because of this, the IEEE 802.11n spec requires that AES-CCMP be used for 802.11n connections. Unfortunately some vendors haven't done a good job of enforcing this in their setup UI, so they may have allowed you to choose 802.11n mode without requiring AES-CCMP to be enabled. It's unlikely, but within the realm of possibility, that your clients are seeing that the AP isn't set up for AES-CCMP, and so are limiting themselves to data rates they know their RC4 engines can handle.
"No security" is also valid, so if you're in a situation where you don't need your data-link layer to provide confidentiality, you can always go that way.
Overall, if it's not too late to return your new wireless gear for a full refund, I'd recommend you return it all and pick up a simultaneous dual-band AP (your Cisco/Linksys E2000 is only one band at a time), and dual-band wireless client cards (your Edimax cards are 2.4GHz-only). That way you can use fast 40MHz channels in the less-crowded 5GHz for your PCs, and leave your legacy devices to use a 20MHz channel in 2.4GHz, leaving enough free space in the 2.4GHz band that it doesn't screw up your Wii Remotes, other Bluetooth devices, and other devices using the 2.4GHz band. Some of the latest gear that has come out in the last few months supports 3 spatial streams (3x3), allowing for signaling rates up to 450mbps. Look up the Wi-Fi certificate for the devices you're thinking about purchasing, and make sure they're certified for "final" (not "draft") 802.11n, 2 or 3 spatial streams, 40MHz operation in 5 GHz, WMM, and all the rest. Here's a good example.
What you say your IT guy said sounds partially correct. All WIFI devices on the same channel share the same frequency and usage by one user can affect another. Ironically because they are set up with different credentials and parameters the bandwidth can't be used ideally - and of-course, data corruption can occur.
Now note I said "on the same channel". I'll talk about 2.4 gig here, the same principles apply to other frequencies. There are about (depending on your jurisdiction) 11 WIFI channels. Unfortunately they overlap which means there are only 3 - 4 "non-overlapping channels". If different access points use different non-overlapping channels they won't have an issue. Also, even if the channels overlap, if they are far enough away you will still get OK throughput. [ Some AP's automatically look for the best channel ].
There are some things you can do -
- Co-ordinate with other parties so as to make optimum use of the frequency.
- Use different gear - the 5 gig band has more capacity and (normally) fewer users. It
also has a shorter range.
- Look at 802.11n equipment with "MIMO" technology, or newer standards with newer versions of corridors/MIMO. This will help "pick out" your signal from the noise.
- Re-orientate your devices and try different frequencies.
- Drop support for older standards (802.11b and g) if you can. Each of these standards
lowers the amount of frequency available for everyone.
- Move !!!! (Into a Farraday cage to cut their signals out, or to another building).
- See if your IT and their IT can "play nice" and create 1 large shared network - that
way everyone gets more useable bandwidth - but there are security and cost issues
to contend with.
Looking at the part of your question "delay vs packet loss" - they are actually the same thing. Simplisticaly speaking ping tests are done using ICMP or UDP, which is "fire and forget". If a packet is lost or corrupted its thrown out. Websites and email etc generally use TCP which has a mechanism for resending lost packets, thus causing delay rather then packet loss - ie lost packets are retried.
Compounding it - if you look at a "lower level", you will probably find that packets are getting corrupted in-flight, ie 1's are interpreted as 0's or vice-versa - the radio is then throwing them away. While there is limited ability to retransmit, the time frame for doing so is short, and won't help you on a noisy connection. Similarly, if the devices are not all talking the same language (I believe 802.11n does some of this, could be wrong. Newer protocols almost certainly do) they can't reschedule their transmissions to fit together.
Best Answer
Many things could be checked:
lots of network usage from that host? (use: wireshark )
lots of CPU usage resulting in a drop of network packets? (use Sysinternals "Process Monitor")
MTU settings: you could have a sub-optimal setting. I'd just do bigger and bigger ping with the "don't fragment" bit set, and see where it starts to break, and figure out then the best MTU setting (which is not the same number as the ping size, because of the ip and tcp headers overhead. Read about it for details). But beware: don't change more than 1 thing, and heavily test each time. You could completely mess up your connection!
routes: you may have conflicting things, such as several default gateways, etc, possibly generating unwanted traffic (such as useless duplicated packets).