The Fritz!Box 7490 is not yet supported by OpenWrt, and its SoC is underpowered anyway (~50 Mbit/s with SQM enabled).
The 7530 looks like a good choice to me, but you will pay for features you cannot use, such as the xDSL modem. No matter if your link is cable or xDSL, you will need a separate modem in any case.
Another option could be the Fritz!Box 4040 or other routers with an IPQ40xx SoC.
I suggest not to buy an overpowered router now, unless you plan to upgrade your bandwidth in the near future. This forum also has some benchmarks.
Well, that's the point. VoIP uses much less than its fair share and is prioritized automatically by fq_codel or cake, but the high bandwidth requirement of Video does not allow that. It could still work well without prioritization when enough bandwidth was available, and latency well controlled. On the other hand, prioritization cannot make up for a lack of bandwidth, and it carries the risk of starving other services if done wrong.
I wanted to know if there were any requirements these numbers stem from. In this case, I would have looked for a solution meeting these requirements that did not rely on such drastic limits.
But apparently, this is purely a policy decision.
I suggest to upgrade your 10 Mbit/s uplink rate if possible, and to reconsider your choice of 1 Mbit/s.
I suggest to build up the configuration in multiple steps.
- Set up SQM with cake on the wan inferface and check the result using the DSLreports speed test. If done right, it will decrease the network latency and result in equal bandwith sharing between network flows. Note there is also a second wiki page with SQM details. It is not strictly necessary, but the Per-Host Isolation could be quite useful in your busy network. The result will be equal bandwith sharing between hosts, which helps to fence in protocols with many flows, such as BitTorrent.
- Note the download and upload speeds configured for SQM. Calculate the shares according to your policy. Remove the cake instance from wan and add two cake instances, one to each lan interface (say,
br-lanandbr-lan2). Configure the bandwidth shares, but be sure to swap the Upload and Download values. Test again. The result should be like 1. but adhere to the desired bandwith split. Sharing of unused bandwith is not possible yet, and traffic between the two LANs is subject to the bandwidth limits, which may not be desired. - This will be an advanced configuration beyond the capability of sqm-scripts, and maybe beyond my own capability as well. It requires manual configuration - refer to the Linux Advanced Routing & Traffic Control HOWTO for details, and the
tcdocumentation. The HOWTO is a bit outdated, but could still help you get started.
Disable sqm-scripts. For each direction (up/down), set up one classfull qdisc (e.g. HTB, HFSC) which is shared by both LANs. For each LAN, add a class with the desired bandwidth limit, allowing bandwidth sharing. Add cake (without bandwidth limit) or fq_codel as the leaf qdiscs. Set up tc filters to assign traffic to the classes, perhaps based on the LAN IP addresses.
You may have noticed that I avoided mentioning particular interface names where the qdiscs are attached. The reason is that I am not sure which is best. Applied to the WAN interface like 1., it may not be possible to use the LAN IP addresses as the filter argument because of NAT. When applied on the LAN side like 2., traffic for both LANs must be somehow sent through a single interface, for which I don't have an easy solution either.
That's all I can say for now. Let me know if I should fill in more details somewhere.
If you want to go with step 3 (qdisc hierarchy), we could try to find other forum members who can improve my sketch of a solution.