Hi,

 

You could follow the below steps to manually adjust the bandwidth by using the SmartByte application

 

 

1. Open the SmartByte application

 

2. Once the application has loaded, press the F4 key on your keyboard to

load the settings page

 

3. In the settings page, you will see the current bandwidth settings.

 

4. You can change these by clicking on them and replacing the number with the appropriate speed, in megabits per second (Mbps).

 

5. You can use the rates stated in your Internet service provider’s plan, or you can use an online speed test, such as https://dell.to/2Tr2DN0. If you elect to use a speed test, make sure you first change the speeds in SmartByte to something far higher than your actual plan so that the current settings do not limit speed.

 

6. Once you have changed the numbers appropriately, click Save Settings and close the application.

 

 

Let us know if this helps.

 

If you follow the directions of the moderator, keep an eye on your link speeds.  When I put the ISP speeds in the Killer Wireless control panel, my speeds dropped by 75%..

There may be a method to Killer Wireless's madness in the way it regulates wireless speeds but I never did understand it and many folks are upset by the loss of speed.

@Saltgrass  based on the application asking for bandwidth limits and you seeing 75% bandwidth with it enabled, chances are that SmartByte is doing something similar to fq_codel on the Linux side. Essentially, as link utilization gets close to the configured max, the system starts dropping packets in an intelligent way (high-bandwidth connections get packets dropped more often) to ensure there’s always some link capacity available and therefore to eliminate buffering, which means reduced latency because packets won’t spend time waiting in potentially large buffers. This mechanism can also be used to control inbound traffic, because if the system drops packets it actually did receive rather than acknowledging them, then due to the way TCP works, the sender will reduce its transmission speed when it sees packet loss. So if you drop packets (again, intelligently) until the total bandwidth of everyone sending you data is slightly below the actual bandwidth of your Internet connection, then your ISP should never need to buffer anything, so once again you can improve latency by avoiding buffering.

The bottom line is that you sacrifice some maximum throughput in exchange for reduced latency and a smoother experience. When done well, it’s actually a great design. But I don’t know if SmartByte’s specific algorithm is a good implementation like fq_codel has proven to be.

I have a UniFi Dream Machine router that can do this for my entire network, and it uses fq_codel. It’s particularly good for things like offices that use VoIP phones and don’t want a large file transfer to consume all bandwidth while their small but VoIP packets get stuck in a buffer or even potentially dropped. With fq_codel, if link utilization gets near the max, the VoIP packets will still go through since they don’t consume much bandwidth, and fq_codel will instead drop packets from the large file transfer to cause the sender to slow down.