What's new

Is your Router/Mobile Device mature enough to switch between 2.4 & 5 GHz ?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

I'm not sure CPU/memory resources and bandwidth are exactly analogous. But at any rate, I get your point. I just don't completely agree.
 
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.
 
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.
 
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.
 
Last edited:
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.

http://www.smallnetbuilder.com/basi...751-snb-answer-guy-how-many-ssids-is-too-many

Might explain why this works...
 
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.

It might be a driver/software bug

Try to reset network in your phone and if it didn't work out try flashing a custom kernel with a new wifi driver
 
The S3 is a relatively old (in mobile device terms at least) device. I'm not surprised it has issues...
 
The S3 is a relatively old (in mobile device terms at least) device. I'm not surprised it has issues...

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.
 
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.
 
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?
 
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?

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).
 
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.
 
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.
 
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.
 
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.

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.
 
I sometimes get an AC device connect to 2.4.
It is an laptop running Win8.1 with an Intel 7260 adapter using the latest drivers.
I even set 'Prefer 5.2Ghz' in the device settings.
Not ideal really.
 
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.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top