Recommend a Wireless Router For a Busy Family

[LSFi]

Hi everyone,

Seems like our WNDR3800 router running DD-WRT has officially bit the dust, so it's time to purchase a new one.

Our house set up is as follows:
3 storey house with 3 sub floors. I'm not really sure about square footage, but it's not a particularly large house, just stacked up tall.

Unfortunately, due to how our cable company installed the modem and how our house is designed, our router is permanently trapped in the first floor basement and it has been moved as high as it can on top of an entertainment unit near the ceiling. We are currently running a WNDR3800 that manages to reach everywhere in the house with a solid 2 bars at the furthest reaches.

We are a pretty bandwidth heavy house. Our cable line is running at 45Mb down/6 Mb up.

- VOIP House Phone
- one TV streaming Asian TV content that seems to be a huge pig for bandwidth up and down via wired connection
- Two FPS gamers playing on wired connection
- 1 Bandwidth intensive PC spending a lot of time uploading/downloading files to work servers
- Lots of LAN file transfers
- A couple of iOS devices and a laptop with AC

What we're looking for:
- Something with easy to learn QOS settings. This is the top priority. Lots of unhappy disagreements break out over somebody hammering the upstream (normally the Asian TV and the work PC to the detriment of the gamers and the house phone). I am pretty computer savvy and am willing to learn how to set up QoS, but I don't have time to learn a semester's worth of networking to get something working. My previous experiments with DD-WRT has gone so-so. Seems like it would work ok for a while, then something would inevitably go wrong. I would love a smarter and more adaptive solution if possible.
- Range in substandard conditions. Speeds would be a bonus, but we definitely need a router that can deal with penetrating several floors upwards
- Something readily available in Canada, price isn't as huge of a concern, but something available for purchase at Tiger Direct, NCIX, or Canada Computers will be necessary.

Routers we're currently considering:
Netgear R7000
Netgear R7500
Linksys WRT1900AC

Thanks in advance for your time and assistance!

 

[cloneman]

My first real post here.

If QoS is a priority, the only thing I can suggest is Tomato Shibby with my patented screenshot settings. Have yet to see anyone else put out a guide that is coherent for the recent builds. If you want downstream QoS to work, this means getting an older MIPS router like an RTN-66U. (newer arm routers do not YET support the "new" downstream QoS). if you insist on the newer ARM routers, you could "probably" do just fine with an upstream-only QoS. (and a downstream one that "kind of" works)

I'm not gonna bore you with further details as my advice could be potentially polarizing.

As such, my recommendation at the moment is to buy -2- routers, one RTN-66U with tomato Shibby as the router, (wifi disbled), and the best WiFi AP you can find to be used for WiFi Access only (stock firmware).

While you're at it, why not pay someone to fish an Ethernet cable up one floor to linkup to the 2nd router (the "AP only" router).

 

[LSFi]

How good are the upstream QoS with that set up? I think normally our downstream has enough bandwidth to keep everyone happy. It's usually when people start using the upstream when people start getting upset with each other. I'm not 100% sure how that Asian IPTV device works, but sometimes I wonder if it's bittorrent based considering how much upstream bandwidth it consumes to work properly.

I didn't think about that second router idea. I think I will have to use that in case the router I purchase doesn't have enough strength to make it up to the top floors as I already have an ethernet cable fished up to the living room.

 

[thiggins]

The other reason for a second router is to spread out the wireless load. Mobile devices can't access all the bandwidth that AC routers can provide due to their radio design. So you end up running out of bandwidth sooner than you'd think, especially with video streaming.

 

[htismaqe]

I second Tim's suggestion.

Given the type of house you have and the number of devices, your best bet is a central router and 1 or even 2 extra routers configured as access points.

I have a very large number of 802.11g devices. I have a Linksys WRT1900AC router for N/AC stuff and then two cheap Netgear WGR614 routers (configured as access points) to aggregate all of the G devices.

 

[cloneman]

How good are the upstream QoS with that set up?

It's probably enough. I'd wager most people do upload-only QoS anyway and don't have many problems.

I haven't actually tried Tomato on the ARM routers, so this is just based on my experience using the MIPS ones. It's very effective at pushing important traffic to the top while allowing great speeds for everyone in the absence of prioritized traffic.

 

[RDI]

I recommend a new AC1200 by Netis. It comes with 4 pcs of 5dB High Gain Antennas. I can set up to 6 different groups running separately. It does both N-300 on 2.4GHz and N-900 (867Mbps) on the 5Ghz, Simultaneously. It is Gigabit on the wired part. Using their AC1200 PCI-E Adapter with 2pcs of 5db High Gain Antennas and both Standard and Low Profile Brackets, I was able to connect at N-867 on the 5 GHz Band. While the Wireless Router (AC1200) runs both bands Simultaneously. The AC1200 Adapters only run either the N-300 or the N-900. You can find more information here: http://pages.ebay.com/link/?nav=item.view&id=251722064241&alt=web

Sent from my SGH-I317 using Tapatalk

 

[htismaqe]

It's probably enough. I'd wager most people do upload-only QoS anyway and don't have many problems.

I haven't actually tried Tomato on the ARM routers, so this is just based on my experience using the MIPS ones. It's very effective at pushing important traffic to the top while allowing great speeds for everyone in the absence of prioritized traffic.

Download QoS is all but worthless anyway. QoS needs to be applied on egress links. For download QoS to be effective, it would have to be applied by the ISP on the PE egress link, not on the CE router in your home.

Unfortunately, it looks like a few of the more popular manufacturers are simplifying their QoS schemes so that setting true upload QoS is impossible.

 

[cloneman]

Download QoS is all but worthless anyway. QoS needs to be applied on egress links. For download QoS to be effective, it would have to be applied by the ISP on the PE egress link, not on the CE router in your home.

This is a misconception. There exist inbound queuing mechanisms that do actually work, and pretty well I might add. I don't know how long these have been around or how much acceptance they've gained, but they work really well on the latest versions of Tomato.

When you drop the heck out of low-priority content, the other end has no choice but to slow down. (And your response would be: by then its too late). No, it's not too late. Not if your router started dropping incoming packets before the point of saturation; anticipating the problem before it occurs.

Weather your ISP drops packets on your behalf by over-provisioning your connection and allowing only high priority content to pass through unencumbered, or you do it yourself by setting an artificial overprovisioing, it comes out to the same thing. Theoretically they can overprovision more than you can because their feeding transit links are bigger, but for my practical purposes I've seen doing it on my CPE to be more than sufficient.

I'm mostly talking in laymen's terms here, because that's my networking skill level. Nevertheless, I'm 100% sure that my information is accurate to a 90% level.

Technically someone at the other end could craft a protocol that keeps pushing you with faster and faster speeds no matter how many packets you drop. This is basically a denial of service attack, as far as I know. Even when using protocols that rely on a large number of connections, including UDP, VPN, whatever - it just seems to work (for me). I'd love to see an example of a protocol that misbehaves and keeps hammering you no matter how many packets you drop.

 

[stevech]

When you drop the heck out of low-priority content, the other end has no choice but to slow down.

May be true for TCP based streams. But not all UDP/RTP type streams (as may be used for video), have good (or any) flow control.

re last paragraph of prior posting. Bare UDP is the classic example of where one can fill the layer 2 channel capacity and grossly overrun the receiving application. Which leads, with UDP/RTP, to application-specific flow control. The really popular ones are known to bandwidth managers that do packet inspection to decide on QoS/queueing. A pioneer in this is/was PacketTrap??.com - I've forgotten. I don't know that consumer routers do much like this.

 

[htismaqe]

As stevech mentioned, if your traffic is not TCP-based (ie. almost all voice, most video, several other latency-sensitive protocols) the other end is completely oblivious to dropped packets because there is no flow control.

I don't want to get into a deep technical debate here but I design large enterprise MPLS networks for a living. There's a reason that QoS is applied on egress at every step in the network - PQ/LLQ on the CE, PQ/LLQ on the PE, WRED on the transit routers, etc.

 

[stevech]

As stevech mentioned, if your traffic is not TCP-based (ie. almost all voice, most video, several other latency-sensitive protocols) the other end is completely oblivious to dropped packets because there is no flow control.

In what I wrote above, I say there IS flow control for non-TCP streams, but only for a few of the most popular proprietary services. The RTP protocol uses UDP and has a defined method for flow control. So do a few very popular content providers' streaming protocols.
But most consumer routers don't do packet inspection of UDP/RTP flows and thus can't do QoS with these.

 

[htismaqe]

In what I wrote above, I say there IS flow control for non-TCP streams, but only for a few of the most popular proprietary services. The RTP protocol uses UDP and has a defined method for flow control. So do a few very popular content providers' streaming protocols.
But most consumer routers don't do packet inspection of UDP/RTP flows and thus can't do QoS with these.

If the flow control is not happening at Layer 4 and is instead written into the protocol, making it so the router can't see it or act upon it, there's no flow control taking place. What am I missing here?

It all comes back to the fact that downstream QoS, as implemented by almost all consumer router vendors is pixie dust and snake oil. It doesn't actually do anything. In fact, very few enterprise networks depend on, or even utilize, ingress QoS. That's not an arbitrary decision, there's good, functional reasons for it.

 

[cloneman]

again, I'd love to see an example of an application, even UDP, that will keep pushing packets even when you drop a bunch of them. If your router's QoS decides that certain traffic is particularly undesirable, it will drop, 10%, 20%, 30%, 80% , 99% of its traffic. (not talking about stock firmware or DD-WRT here. I'm only referring to proper ingress implementations. I've yet to see anything other than recent tomato shibby/toastman builds do this.)

What application would keep pushing more bits when a large chunk of the packets are being dropped? It's _possible_. Does it actually happen?

- uTorrent has its own congestion mechanism that they built to use UDP.

- A UDP video stream or skype call will certainly die and the app will decide to drop the connection.

- underlying applications encapsulated in a UDP VPN will probably shirt a brick seeing their traffic so delayed and decide to give up.

 

[htismaqe]

again, I'd love to see an example of an application, even UDP, that will keep pushing packets even when you drop a bunch of them.

TFTP.

If your router's QoS decides that certain traffic is particularly undesirable, it will drop, 10%, 20%, 30%, 80% , 99% of its traffic. (not talking about stock firmware or DD-WRT here. I'm only referring to proper ingress implementations. I've yet to see anything other than recent tomato shibby/toastman builds do this.)

What application would keep pushing more bits when a large chunk of the packets are being dropped? It's _possible_. Does it actually happen?

- uTorrent has its own congestion mechanism that they built to use UDP.

- A UDP video stream or skype call will certainly die and the app will decide to drop the connection.

- underlying applications encapsulated in a UDP VPN will probably shirt a brick seeing their traffic so delayed and decide to give up.

You're talking about special, application-based mechanisms, which is precisely what stevech was talking about. If your router isn't application-aware, it isn't participating.

And dropping a call, isn't "quality of service" by the way. You can get that type of behavior without any QoS at all.

 

[System Error Message]

to control downstream you have to control the upstream that requests the download. you can use a router with 3rd party firmware or a non consumer one. The one i use lets me do amazing stuff with bandwidth prioritisation and control.
A few facts though about bandwidth usage
1) Online TV uses 10-15Mb/s for 1080P content (measured)
2) FPS Games use less than 512Kb/s and are latency sensitive and require really low latency upload (hence you should never play FPS on wireless) (measured)
3) LAN transfers only interfere if someone tries to play a game on wireless while the LAN transfer is spamming connections on the same wifi. This only happens if you are trying to benchmark or stress test your wifi AP.

When it comes to QoS you first give priority to games, than work based applications, than web browsing, than online TV and than only downloading and torrents.

Dropping ingress traffic isnt a solution because that traffic that was dropped used up your allocated bandwidth. Best to control the ingress via the request made in egress by holding packets or delaying them. For example to browse a web page it first has to make a request to the webserver. This is why i apply my qos to both upload and downloads using the same rules.