I'm a Debian user and have already configured a router TL-R470T+ to connect with 2 providers (by PPPoE and dynamic link). And I'm using the TL-WR841ND V10 router only as an access point.
Now I'm in doubt as to how I will set the Upstream and Downstream Bandwidth for each ISP if every time I do a test (for example on www.speedtest.net) I find a different speed that can vary from 2 to 20 Mbps?
Hi Dan, Yes, you are right, it is not a specific Debian issue. But I don't know where to ask for help. I'm having trouble finding reliable answers to configure this router. There are many videos on Youtube but with contradictory information. I searched on the TP-link website and posted a question on the forum but I didn't have an answer. I did what you suggested, but throughout the day the speed varies. So my question is, what a speed value mean if it varies throughout the day? Thank you for your attention. Markos
I think you're getting into fundamentals of how your internet is provided. I'm not a networking engineer, so some of the detail of the following might be off, but this is how I understand it to work. The most popular broadband around at the moment is ADSL. This is, in VERY broad strokes, an extension of the older analogue modem technology. But, instead of the data being modulated into audible sound, it's modulated into ultrasonic sound. Instead of dialling into a server halfway across the country, with ADSL the sound only needs to carry as far as your local telephone exchange. Blocks of frequency, all above human hearing, are used and the total frequency range (and therefore data bandwidth) is MUCH higher than before. (Incidentally, because ADSL is fully above human hearing, this is why we can use a "microfilter" to split the data and voice frequencies, meaning you can use your phone without disrupting the internet).
Now, here is the first reason why the speed can vary throughout the day. ADSL is, fundamentally, trying to push wires which were only rated for voice frequencies beyond their limits. Sure, all data transmission technologies have an analogue medium, but Cat5e Ethernet cable is designed to fully handle the frequencies being passed across it. The copper phone lines to your telephone exchange might be half buried in water, they might run alongside a train track, they might follow the twisty route of a suburban road, rather than taking the most direct route. The upshot of this is that the amount of noise on your line probably isn't constant. Your ADSL modem will be constantly monitoring the signal-to-noise ratio of the various blocks of frequency, and the two ends will negotiate which to use. To put it simply, bad weather can reduce your bandwidth.
Another issue that might affect your speed is "contention". Contention is a more broadly-applicable issue. You see it on ADSL broadband, but you see it more commonly on Cable broadband. Contention basically means that some part of the connection between your house and the ISP's central servers is oversold. Taking the ADSL system as an example, let's put ourselves in the shoes of a fledgling ISP. We are provisioning a neighbourhood for ADSL. Let's say that, theoretically, ADSL can go up to 50Mbps per line and that there are 100 houses being served by this one exchange. That means we need a 5Gbps link between the exchange and our servers, right? But they're SO expensive! And, no-one's actually bought ADSL yet, let alone the "Top Speed" package. If we buy the 1Gbps link, we can save massively. So, people start buying ADSL and they're getting 10Mbps speeds. Wow! That's fast compared to 56kbps! 20 people buy it. 50 people buy it. Excellent, we're still only at half the capacity of our big link. Oh, but here's a technology update and ADSL can now reach 25Mbps. As you can see, as more and more people buy ADSL, and the ADSL routers get cheaper and faster, the pressure on the uplink increases. Now, as this happens, your ADSL modem will still report the fast speed. As far as it's concerned, it's established a, say, 25Mbps connection with the telephone exchange. Now, if it's 3am, perhaps you CAN download at close to that speed. But what if it's 7pm? And it's the season finale of "Lilliput's Got Talent". Suddenly, you've got dozens of people trying to download masses of data. Everyone is still connected to the telephone exchange at high speed, but the over-sold uplink can't transfer all of that data, so everyone's bandwidth slows to a crawl.
So, what can you do about it? Well, you probably can't complain
to your ISP. They probably sold you your internet as "Up to
Xmbps", because they know that the rated speed is rarely
achievable. You MIGHT be able to switch to an alternative
technology; if speed really matters to you, consider buying a
"dedicated line". This will bypass the contention issue and,
depending on the physical technology used may be less susceptible
to the environment. Alternatively, you could just decide "does
this matter to me?" Broadband IS important to qualty of life
online these days, but ultrafast broadband is not so much. Have a
think about what's "fast enough" for you.
Top-posting Darac's excellent long response. Here's a data point for you. The effective bandwidth increase from 10Mb/s ethernet to 100Mb/s ethernet was achieved by simply using more conductors. Already in the connectors and cabling. But no one added capacity upstream specifically for that. Just added more customers and infrastructure.
Oh, yes. That's what we were talking about. Well, I guess it's
more about the _relative_ speeds of the two ISPs, isn't it?
The easiest solution is to not limit the speeds at all. That way, each interface will use as much bandwidth as is available. If you're wanting to use QoS and so on, then I guess you need to have an idea of how much bandwidth is available, in order to decide how much of that to parcel out to each performance bracket.
I would suggest picking the average speed (average upload and average download, that is. Treat both speeds as independent). If the speeds don't vary much, then it doesn't matter too much. If they do, then sometimes you're not getting the full benefit of your line and sometimes your balancer might get a bit backed up, but it should still work.
If it really matters to you that the load balancer must match the
actual line speed closely, then see if you can script the changes;
run a periodic speed test and adjust the load balancer values