First I add that some of these replies need clarification.
There are two kinds of overlap, one is channel overlap where the frequencies overlap, and the second being signal overlap.
You MUST have signal overlap for all devices to have coverage in all areas, or even most devices in most areas.
Secondly, there are various schools of thought for frequency overlap and some manufacturers even suggest putting all APs on a common channel. In the case of roaming IP phones this case becomes even stronger as a phone may hop across APs while in a call. This of course depends much on the hardwae of the phones and antenna placement and design.
Let us assume that we had a large open area that we wanted wifi coverage in. Now lets take a pole and place it in the middle of the area. Now we place 4 directional 90 degree antennas on the pole, each 90 degrees from the other . In this situation one may make a strong case for having all APs on the same channel to facilitate roaming. In theory there is little signal overlap but all frequencies overlap.
Now we have an open area with walls on four sides. and place an AP on each of the four walls. The signals WILL overlap from each of the 90 degree antennas , so we may want to consider using separate non overlapping channels on each AP , however there are only 3 non overlapping channels. 1, 6 , and 11. So instead we do the best we can in North America this might be 1, 4, 7, and 11 , each AP having SOME necessary frequency overlap. Of course in a perfect world this might be better accomplished with three APS in a triangular configuration.
In my home I have toyed with APs on Same channel and separate channels and in the end I see little coverage difference., I do see however that some devices such as wireless IP phones can more easily hop to another AP while in a phone call. I see that in most areas I do not have more than 2 overlapping signals and each on channel 4 at present. As I sit here I can launch wifi seeker on my android and see either of the 2 available APs and even connect to either. This of course is easier to test with separate SSIDs but more practical to use common SSIDs fopr everyday use.
A trick to determine the vendor of an unmarked (or physically inaccessible) AP is to learn its BSSID (which is basically the MAC address of the AP's 802.11 wireless NIC). The first half (the first 3 bytes == 6 hex digits) of a typical MAC address in an IEEE OUI (Organizationally Unique Identifier). You can look up the OUI to company mapping on the IEEE website.
An easy way to find the BSSID of any AP you can associate to is to option-click the AirPort menu extra (the AirPort icon menu in the menubar) while associated. You'll see several extra pieces of diagnostic information in grey, including the BSSID. So if the BSSID show up as, say, "0:1f:f3:12:34:56", the OUI is "00:1f:f3". The IEEE lookup on the page linked above doesn't like colons, so either remove them like "001ff3" or replace them with hyphens like "00-1f-f3". Note that Mac OS X often drops the the leading zero in any given byte in a MAC address, so if any byte of the MAC address only has one digit, you'll have to put the leading zero back in before searching for it on the IEEE OUI lookup.
Some times an OUI lookup fails to conclusively identify the manufacturer of an AP. For example, if the 2's place bit of the first byte of the MAC address is set, that's the "local" bit, which means that the MAC address is "locally administered", which means it's not a real guaranteed-globally-unique MAC address, but one that was "made up", perhaps by the network administrator who configured the AP. Other times, the OUI lookup will tell you who made the wireless NIC card of the AP, or who made the chipset on the card, but not who made the AP itself.
If the OUI lookup approach doesn't work for you, take a picture of the AP and post it. Maybe someone here will recognize it. Also, what cables can you see going into the APs? Do you see one or more coax cables but no Ethernet cable? Then the box you're looking at is probably just an external antenna, and the real AP is out of view, perhaps above the drop-ceiling. You could also be looking at some other piece of building infrastructure, like an industrial-style smoke detector, heat detector, a motion sensor for automatic lights, or an antenna for some completely unrelated wireless technology (like an indoor cell signal repeater). Just because your Wi-Fi signal strength is good near that box doesn't mean that box is your actual AP. I learned that lesson the hard way -- I misidentified a mostly-unmarked white antenna enclosure as being the AP in a building because my Wi-Fi signal strength was strong near it, and didn't realize that it was an antenna for an indoor cell signal repeater, and the real AP happened to be hidden above the drop ceiling two meters farther down the hall.
If your APs turn out to be Cisco boxes running in lightweight mode, beware of these Cisco bugs:
CSCsy73154—The access point does not forward the DHCP offer to the client.
...which is sometimes called:
CSCsz22901—The access point does not forward the DHCP offer to the client, so the client fails to get an IP address.
My site was running Cisco APs in lightweight mode (specifically 1252s in B/G/N + A/N HT20 mode, but I don't know that it matters), in conjunction with various models of Cisco Wireless LAN Controllers (WLCs) and Wireless Service Modules (WiSMs).
Even without any security enabled on a certain network, some Mac clients would sometimes fail to get DHCP leases. 802.11 monitor-mode packet traces, in conjunction with wired Ethernet packet traces between the APs and the controllers (showing the unencrypted LWAPP session) showed that the clients were successfully associating and sending their DHCP Discover packets, and the DHCP server was replying with a DHCP Offer, and the WLC/WiSM was forwarding that DHCP Offer to the Cisco AP, but the Cisco AP was never forwarding that DHCP Offer along to the client.
These issues were fixed in the following Cisco WLC/WiSM software releases from the summer of 2009:
4.2.207.0 (not to be confused with 4.2.205.0 which does NOT have the fix)
5.2.193.0
6.0.x.x -- I believe any public 6.x release has the fix.
If your site is running a 5.0.x.x or 5.1.x.x release on your Cisco WLCs/WiSMs, you'll need to evaluate upgrading to 5.2 or 6.0, because I think if Cisco was ever going to fix this for those build series, they would have done so by now.
Best Answer
If a satellite link is somewhere in the picture, even bad wifi links come no where near the 550-600ms due to the satelite hop. So what if you add 10-50ms with some repeaters.
I dont have much experience with low end "wifi" but stuff like mikrotik we can do 2-4 hops, each 8km and the latency stays 10-20ms with low load. But that is a good one. On our bad ones (alvarion old stuff) with several hops is can be 100ms over 16km when loaded. But i have seen people connect offices with wifi links and dont notice a difference browsing. You might have more jitter with VoIP.
equipment that uses frequency hopping as opposed to Direct Sequence has higher latency. I dont think FH is used much anymore.
If loads are high latency goes up.
Some DSL modems will work back to back, might be an option for you. wires are easier to troubleshoot in congested areas.