Kitz Forum
Computers & Hardware => Networking => Topic started by: Weaver on July 30, 2018, 05:23:17 AM
-
When I do a backup-to-iCloud on one of my iPads, it saturates the upstream, not surprisingly, and the max latency shown in my CQM graphs (courtesy of the AA clueless server) goes literally off scale at over 500ms max, 100% of the time.
I wonder if I should try and reduce this latency a bit. Is such a thing even possible? I can’t control the behaviour of the backup, but that would be the way to prevent crazy latency. It would be nice if these services could all be set to use a certain amount of bandwidth, either an absolute value or a fraction of the total, or a fraction of the total free.
-
do you have any QoS enabled?
-
Not sure. There are QoS-related settings in force but I don't know if they have any effect because it is just handling PPP frames, it is just acting as a a modem, not as a router.
-
QoS would be on your router, not the modem.
you seem to have a classic case of buffer bloat.
-
Yes, unfortunately my router, a Firebrick does not speak QoS, which I think is a real shame.
Anything to be done that could mitigate it ?
-
other than somehow throttling the bandwidth on the offending service i'm not sure.
i know dropbox has throttle options, but i doubt apple will have been nice enough to offer such a function in their icloud client software.
-
Your Firebrick has no QoS? It's no wonder you're saturating your upstream.
Which model of the Firebrick do you have? They must have something similar to QoS!
-
Nope, I have the top of the range 'Fully loaded' software load. There are only two software options.
When I talked to RevK about this, he pointed out that there are no queues to manage in the Friebrick, it just ships packets off to the modems as quickly as you like so egress queues never build up. Active queue management would not therefore work, that was his point. While I understand that this is literally true, it is a situation only created by the fact that the Brick is choosing to push the packets out as fast as possible, pushing problem onto the modems and is sending stuff to them faster than they can take it, despite the fact that it knows or at least can know how fast a rate the oh the modems can handle. My brick is told what the speed of each line is, in the config file. With a design change it could be set to only send packets out at a timed rate, and then manage the queue behind with intelligent modern goodness. But that would be a fair rewrite and a lot of work, also adding the potential for bugs, so designers are often loathe to risk breaking something that is currently bug free.
Given that the Brick gets told what the speed of each link is, then you might wonder what it is doing with this information. It has a speed limiter object facility, which can be used generally anywhere to cause it to drop packets. But that might mean, I think, that once again queues do not build up, and you do not have the information there in a queue to let you prioritise amongst packets. The speed rates do, I fervently hope, give the Brick an idea of how to split the load over multiple lines so that the correct fraction goes to each line, since my lines are not the same upstream speed, one is about 15% faster upstream than the other two, for some reason.
I think it is worth doing the full thing though, as proper QoS is a really big deal for me. I mean both in terms of observing L2 and L3 QoS fields and possibly marking them by actually modifying the QoS fields, and also regarding the possibility of declaring ad-hoc rules to add QoS handling instructions to different types of traffic according to various categorisation strategies. Examples: things like prioritising all small packets, all DNS, all TCP ACKs. These traffic categories could then be assigned to queues possibly overriding the QoS markings or being placed into sub-queues at the next level below.
I wonder if any really fancy switches can do this kind of really good QoS categorisation and re-queuing? Again I would run into the problem of it simply not working if the switch just ships all packets to the Brick as fast you like. Anyway, if there is such a device, that would be a plan B if I fail yet again to persuade RevK.
-
if it was me then i'd be getting rid of the firebrick to be honest.
seems like it's designed to run the way "RevK" wants and not about how the end-user needs/wants it to work in the real world.
there are plenty of routers/switches that do QoS in various different ways.
the EdgeRouter X i currently use has QoS (ubuquti's version of it), and it certainly works in that it never allows buffer bloat to become an issue.
-
there are plenty of routers/switches that do QoS in various different ways.
With load sharing across multiple bonded lines?
-
With load sharing across multiple bonded lines?
are you suggesting there are none?
-
Nope, I have the top of the range . . .
As I now understand the situation, quoting from Watchfront/Firebrick --
1st Gen. Firebrick SoHo
2nd Gen. FB105
3rd Gen. FB2500
4th Gen. FB2700
5th Gen. FB2900
The 1st - 4th generation Firebricks have now been declared to be "legacy" devices. Only the 5th generation, FB2900, is a "current" device.
-
Looks like the FB105 has QoS.
Does your Firebrick have any type of upstream traffic prioritization?
-
I own a FB105 , a £9-99 eBay bargain, but only use it for "special tasks" i.e. MITM purposes. (Or perhaps that should be CITM, where the C is cat . . .)
I believe it does have QoS settings . . . if one can understand the documentation.
-
are you suggesting there are none?
Not at all. I just wanted confirmation that the "plenty of routers/switches that do QoS in various different ways" have multiple WAN ports and can do load sharing as that is essential for Weaver's set up.
Perhaps you could post some links to some you had in mind?
-
I own a FB105 , a £9-99 eBay bargain, but only use it for "special tasks" i.e. MITM purposes. (Or perhaps that should be CITM, where the C is cat . . .)
I believe it does have QoS settings . . . if one can understand the documentation.
Can it do QoS for multiple bonded lines?
-
you want something with CoDel.
i believe dd-wrt and pfsense can do that.
alternate solution is just stick a box inbetween the router and end-user that caps the bull bonded rate upstream.
-
The FB has shapers but they aren't really the same thing as proper QoS. Proper QoS can also be CPU intensive however. The way the FB does it, as far I'm aware, is like AAISP's website describes:
"We have options allowing users to set their line at a lower rate, e.g. 95% of BRAS. This is useful for things like VoIP as our shaper is smarter than BTs and allows small packets through more readily than large packets. Customers have tested VoIP on a 95% rate whilst running torrents and downloads and found it works well."
So while you can adjust the rate limit of the downstream from their control panel, you must rate limit the upstream from your side with an appropriate router such as the FB.
The closest thing the FB has, that I'm aware of, is when you have bonded lines you specify the upstream bandwidth of each line. I've set mine about a megabit lower than the actual average upstream sync rate (e.g. 11 megabits instead of 12 megabits). I don't have such issues with my two connections, on dslreports speed test with down and up having six streams I get a bufferbloat grade of A and a quality of A+.
However, for a much slower DSL connection then things could be a lot different and you might find you'll need a router between the FireBrick and your LAN devices which does fq_codel. A cheap EdgeRouter might be an option to consider, I used fq_codel on that (Smart Queue as they call it) when I was using my EdgeRouter.
-
What exactly is your setup, including model numbers?
-
However, for a much slower DSL connection then things could be a lot different and you might find you'll need a router between the FireBrick and your LAN devices which does fq_codel. A cheap EdgeRouter might be an option to consider, I used fq_codel on that (Smart Queue as they call it) when I was using my EdgeRouter.
the only snag with the edgerouter implementation is that you have to sacrifice a little of your overall bandwidth to compensate for it.
on a slow connection that might be a big hit on the attainable downstream.
-
you want something with CoDel.
i believe dd-wrt and pfsense can do that.
alternate solution is just stick a box inbetween the router and end-user that caps the bull bonded rate upstream.
Come on now, you mention fq_codel then dd-wrt and pfsense? The people who wrote it literally used openwrt as their test bed and to date the most complete implementation is there. The freebsd pfsense guys have kicked and screamed about adding it.
-
and your point is?
-
Just wanted to point out that the list of firmwares that support fq_codel and SQM should start with OpenWRT.
-
Just wanted to point out that the list of firmwares that support fq_codel and SQM should start with OpenWRT.
(https://media0.giphy.com/media/Rhhr8D5mKSX7O/giphy.gif)
-
Hilarious! :D