Is your Router/Mobile Device mature enough to switch between 2.4 & 5 GHz ?
- Thread starter IAAI
- Start date
htismaqe
Very Senior Member
I think it's also worthwhile to note that you (and other here actually) are speaking from professional experience. Correct me if I'm wrong but it appears that you do network consulting of some sort in the small/medium business space.
In this sense, you have A LOT better frame of reference than I do. I can really only draw on my experience here at home. My "work customers" are large enterprises with multimillion-dollar IT budgets. They obviously don't employ much, if any, of the technology we like to discuss here.
In this sense, you have A LOT better frame of reference than I do. I can really only draw on my experience here at home. My "work customers" are large enterprises with multimillion-dollar IT budgets. They obviously don't employ much, if any, of the technology we like to discuss here.
No harm, no foul. Frankly, I enjoy a good, healthy debate.
I can totally see where you are coming from living in a smaller, confined area, I'm assuming with quite a few neighbors.
By contrast, I live on an acre-and-a-half with a 2500-square foot house and outdoor living spaces. Closest neighbor is over a mile away. Without the ability to roam, I would have to manually switch mobile devices like my iPhone when I'm out on the back deck or out by the fire pit. I can cover those areas with 2.4Ghz because I have zero competition for channels.
yep, my 2.4 is really crowded, tons of neighbors, so we got opposite situations hence the different preference
I have been running 5GHz for a few months now since my 2.4 GHz is too crowded. I switched over to 5GHz exclusively and turned off 2.4GHz. I had to add more APs to cover the smaller 5GHz coverage and less penetration. It preforms much better than any 2.4 GHz network I have had in the past. I use one SSID and my wife can Facetime from outside to inside while moving and not lose a connection while changing APs. Now that I have invested in 5GHz I don't think I will ever go back to 2.4GHz, things are just better. This is all based on running in my home enviroment without limiting bandwidth.
I use 3 Cisco APs with Apple devices and Windows devices.
I use 3 Cisco APs with Apple devices and Windows devices.
After reading all this stuff, I have decided to ditch my 3 discrete SSIDs and try a common SSID.
This also has the advantage of seamless transition to Smart Connect when it has matured.
EDIT: ok it's done. No real problems so far.
My Samsung S3 seems to prefer 2.4 even thought it's in the same room as the router. Everything else seems to be behaving as expected.
Thank for all the discussion and info.
This also has the advantage of seamless transition to Smart Connect when it has matured.
EDIT: ok it's done. No real problems so far.
My Samsung S3 seems to prefer 2.4 even thought it's in the same room as the router. Everything else seems to be behaving as expected.
Thank for all the discussion and info.
Last edited:
sfx2000
Part of the Furniture
http://www.smallnetbuilder.com/basi...751-snb-answer-guy-how-many-ssids-is-too-many
Might explain why this works...
Indeed it is old, i'm not too concerned.
Strangely enough my son's S3 Mini prefers to hang about on 5G-2.
Overall i'm pleased with the results of the change over.
I this morning was doing some experimentation, I still have discrete ssid's but I had to move my 5ghz to channel 40 (from 100) which annoyed me because lollipop 5.1 now blocks configuring the wifi region and doesnt allow the high channels (as it should do), but anyway I moved my 5ghz to channel 40. I configured the 5ghz ssid on my oneplusone phone, and also left the 2.4ghz saved so it has both ssid's remembered and will pick which one to use.
There is two things I observed.
1 - it was picking 2.4ghz about 33% of the time when I didnt specify which ssid to connect to, this is with the router about 2m from me with 5 bars on both networks).
2 - when I changed a setting on my router, which meant the wireless temporarily dropped, the oneplusone stayed connected but all my other devices including my s5 and galaxy ace would drop and reconnect, this means I think my oneplusone would have issues with wifi roaming etc. as it seems to not detect wifi disconnections, as a test I reduced the channel width to 20mhz and manually reconnected it, it had a lower speed as did all my 5ghz devices, I then increased to 40mhz, all the wifi devices except the oneplusone reconnected at a higher speed, and repeated for 80mhz, so after enabling 80mhz everything had reconnected automatically at full speed but the oneplusone phone was still at the 20mhz speed, it hadnt detected any of the outages.
So all this defenitly does seem device dependent.
Also I then did some tuning on my beacon timing, I increased both timings for 2.4 and 5ghz, but they now dont have the same timings, I set 2.4 to 500ms, and 5 to 200ms, and now the oneplusone seems to always pick the 5ghz network. I adjusted dtim timings to compensate so a dtim packet is sent on every beacon on 2.4 and every 2 beacons on 5, hopefully I dont break anything, if I do I will adjust beacon timings so they are multiples of 150 so I can maintain a 300ms dtim.
There is two things I observed.
1 - it was picking 2.4ghz about 33% of the time when I didnt specify which ssid to connect to, this is with the router about 2m from me with 5 bars on both networks).
2 - when I changed a setting on my router, which meant the wireless temporarily dropped, the oneplusone stayed connected but all my other devices including my s5 and galaxy ace would drop and reconnect, this means I think my oneplusone would have issues with wifi roaming etc. as it seems to not detect wifi disconnections, as a test I reduced the channel width to 20mhz and manually reconnected it, it had a lower speed as did all my 5ghz devices, I then increased to 40mhz, all the wifi devices except the oneplusone reconnected at a higher speed, and repeated for 80mhz, so after enabling 80mhz everything had reconnected automatically at full speed but the oneplusone phone was still at the 20mhz speed, it hadnt detected any of the outages.
So all this defenitly does seem device dependent.
Also I then did some tuning on my beacon timing, I increased both timings for 2.4 and 5ghz, but they now dont have the same timings, I set 2.4 to 500ms, and 5 to 200ms, and now the oneplusone seems to always pick the 5ghz network. I adjusted dtim timings to compensate so a dtim packet is sent on every beacon on 2.4 and every 2 beacons on 5, hopefully I dont break anything, if I do I will adjust beacon timings so they are multiples of 150 so I can maintain a 300ms dtim.
To reiterate: lots of SSIDs detected on the same channel as yours, does not mean that channel is a bad choice.
the question is channel utilization - how busy is the channel, say, in the evening busy hours.
But beware too, that if you are on channel 6, your neighbors on channels 3 to 8 spread their signal to include your channel (and vice-versa). 802.11 is (normally, in 2.4GHz), 20MHz wide but the channel numbers that some dolt chose are spaced more closely.
Common WiFi SSID analyzers do NOT show you channel utilization (0-to-100% over some time period. But it's what matters.
the question is channel utilization - how busy is the channel, say, in the evening busy hours.
But beware too, that if you are on channel 6, your neighbors on channels 3 to 8 spread their signal to include your channel (and vice-versa). 802.11 is (normally, in 2.4GHz), 20MHz wide but the channel numbers that some dolt chose are spaced more closely.
Common WiFi SSID analyzers do NOT show you channel utilization (0-to-100% over some time period. But it's what matters.
Can you really have 0% channel utilization when other peoples' wireless devices are on the same or close channel. Wouldn't there be a certain amount of overhead to keep the wireless devices alive? Would more wireless devices on a network have a higher base overhead?
azazel1024
Very Senior Member
Overhead is extremely limited. If there was pronounced traffic "idle" then you'd chew through battery life. If a client is within range of an STA, the traffic is extremely low. The beaconing traffic (which is around 2% channel utilization at default bit rate and frequency) takes up a lot more than client devices that are idle do.
Of course they might NOT be completely idle, doing things like checking email, app updates, etc. However, that is still probably pretty low and only accounts for a handful of percent channel utilization at most even for a lot of clients.
I've tried doing wireless testing with all (well, all relevant) wireless clients ON, but not in active use versus them being off, on the same band and the same access point in my house. The difference in performance on both upload and download were well within the margin of error for testing (less than 2% difference). So I don't bother turning other clients off during testing.
The 802.11 beacon broadcast does run with or without user traffic. But a beacon is typically set to send 10 times a second and a beacon's duration is a tiny few microseconds. I've never done the math, but the previous poster says it is 2% of available time in an otherwise empty channel. In an extreme case of AP/router density, the number of beacons can affect throughput. But not the norm.
The IEEE standard way beacons are used is to tell battery powered devices that data is waiting. A battery powered device should sync to the beacon interval and sleep for one or more beacon-durations. There are other proprietary and rarely used IEEE standards for what is within beacon (payload).
The IEEE standard way beacons are used is to tell battery powered devices that data is waiting. A battery powered device should sync to the beacon interval and sleep for one or more beacon-durations. There are other proprietary and rarely used IEEE standards for what is within beacon (payload).
yeah more regular beacons as I understand it are better if latency is important e.g. such as voip. If its just things like web browsing, streaming, less regular beacons should be ok. I think its not beacons that wake up a sleeping wifi device tho, thats the dtim headers that will do a wakeup, not 100% sure tho.
My changes are experimental, I made them aware I might break something and would have to undo the changes. So far tho I have not seen ill affects.
If you think of interrupt moderation a feature on intel nic adaptors, it bunches up packets in batches to reduce software interrupts, I believe the beacon system is a similar thing for wireless.
The default dtim interval on asus routers is 300ms, I did adjust those values to try and keep it close to 300ms as possible after I made the change, my new dtim interval for 2.4 is 500ms, and is 400ms for 5ghz.
My changes are experimental, I made them aware I might break something and would have to undo the changes. So far tho I have not seen ill affects.
If you think of interrupt moderation a feature on intel nic adaptors, it bunches up packets in batches to reduce software interrupts, I believe the beacon system is a similar thing for wireless.
The default dtim interval on asus routers is 300ms, I did adjust those values to try and keep it close to 300ms as possible after I made the change, my new dtim interval for 2.4 is 500ms, and is 400ms for 5ghz.
The battery powered device is programmed to wake itself up periodically. A smart client knows when the sleep should end, to catch a beacon with DTIM info. DTIM is one kind of payload data that can be in a beacon's message. IEEE 802.11 defines beacon formats, and suggests regular intervals - IEEE's default is 0.1 second. The client device can sleep as it wishes, or not sleep. Or sleep after x seconds of user inactivity. This is vendor-specific power management strategy.
Desktop mains powered devices, and perhaps handhelds that are plugged in to chargers, don't normally use DTIM and sleeping.
On my ASUS router, for both bands, the beacon interval is 0.1 second. I've not seen a vendor choose 0.3 seconds.
I have seen WiFi APs and routers intended for heavy VoIP with battery devices such as Vocera, use a shorter interval - for the sake of the VoIP stream buffer.
Desktop mains powered devices, and perhaps handhelds that are plugged in to chargers, don't normally use DTIM and sleeping.
On my ASUS router, for both bands, the beacon interval is 0.1 second. I've not seen a vendor choose 0.3 seconds.
I have seen WiFi APs and routers intended for heavy VoIP with battery devices such as Vocera, use a shorter interval - for the sake of the VoIP stream buffer.
azazel1024
Very Senior Member
Generally, from what I understand of it, Stevech is correct. The client (a mobile client) is not waking to listen to every beacon. Within the beacon is the interval and DTIM format. The client will then pick how often to listen for a beacon that tells it A) it is still present on the network and does not need to look for a new one and B) if there might be any data waiting for it.
I am not super familiar with it, but I suspect it'll only wake-up maybe every 1 in some large number of beacons (like 1 in 10, 1 in 20, etc.) to try to listen for one of the beacons that has DTIM info.
Short beacons can improve latency for sleeping devices, but it also means higher battery drain, to some limited degree. A wifi chipset coming up from slumber to a low enough power level to ONLY receive a few millisecond long beacon and then go back to sleep doesn't take much power. It would only be if you set beacon intervals and DTIM short enough that the wifi chipset pretty much wouldn't be able to slumber that you'd run in to power consumption issues. The difference between 10-20mw of power consumption for 10-20ms every 1-3 seconds and the same every half a second, or every 10 seconds isn't really that great compared to overall background power consumption, even with the device in sleep mode.
However, obviously every erg you can save is a good thing.
One thing it will do with long beacon intervals is reduce roaming ability as the client has to listen for a beacon to determine a new STA to roam to. A client isn't necessarily going to HEAR every beacon frame, because it is scanning across channels and bands. So the more frequent beacons, the more likely the client is to actually hear a beacon from an STA and be able to judge if it can or should roam to it.
Set really low beaconing rates and it'll promote sticky clients. Shorter beacons aren't necessarily going to promote roaming (shorter than default I mean) as clients are typically going to expect "standard" beacon rates when scanning for SSIDs. It "pause and scan" on each channel through the bands long enough to be reasonably sure it picked up all beacons. But if you are beaconing at a half second rate, it is likely it might take several scans before it picks up the STA.
I am not super familiar with it, but I suspect it'll only wake-up maybe every 1 in some large number of beacons (like 1 in 10, 1 in 20, etc.) to try to listen for one of the beacons that has DTIM info.
Short beacons can improve latency for sleeping devices, but it also means higher battery drain, to some limited degree. A wifi chipset coming up from slumber to a low enough power level to ONLY receive a few millisecond long beacon and then go back to sleep doesn't take much power. It would only be if you set beacon intervals and DTIM short enough that the wifi chipset pretty much wouldn't be able to slumber that you'd run in to power consumption issues. The difference between 10-20mw of power consumption for 10-20ms every 1-3 seconds and the same every half a second, or every 10 seconds isn't really that great compared to overall background power consumption, even with the device in sleep mode.
However, obviously every erg you can save is a good thing.
One thing it will do with long beacon intervals is reduce roaming ability as the client has to listen for a beacon to determine a new STA to roam to. A client isn't necessarily going to HEAR every beacon frame, because it is scanning across channels and bands. So the more frequent beacons, the more likely the client is to actually hear a beacon from an STA and be able to judge if it can or should roam to it.
Set really low beaconing rates and it'll promote sticky clients. Shorter beacons aren't necessarily going to promote roaming (shorter than default I mean) as clients are typically going to expect "standard" beacon rates when scanning for SSIDs. It "pause and scan" on each channel through the bands long enough to be reasonably sure it picked up all beacons. But if you are beaconing at a half second rate, it is likely it might take several scans before it picks up the STA.
I said the 300ms is for dtim not beacons.
Also there is no noticeble lag when i enable wifi on my phones. Certianly not multiple seconds.
Yeah, the default is to transmit DTIM with every beacon, and the default beacon interval is 0.1 sec. Ideally, DTIM > 1 (beacon interval), the battery powered clients detect that DTIM setting at the AP and sleep longer.
Similar threads
Similar threads
Similar threads
-
-
Do changing antennas ona router or broadcaster matter? Here is the proof
- Started by Metroguy
- Replies: 2
-
-
New ISP router - has no Guest function - looking for suggestions
- Started by layw
- Replies: 10
-
AT&T BGW320 Gateway + Asus or Netgear Router results in unexpected geo-block from various websites.
- Started by Geoblocked24
- Replies: 17
-
-
-
-
Technicolor DGA 0122 router as EasyMesh node
- Started by Jonathan Dixon
- Replies: 3