This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[ASL5] Shaping bandwidth by service (QoS)

Hello all,

I recently upgraded to 5.026 (Will update when I can allow a restart) from version 4.024, and I really like it.  One thing I would like to be able to do is prioritize two of the services I use so they don't use bandwidth when I want it.

I have installed BitTorrent and Direct Connect. They use ports  and  respectively.  I have both limited to an upload speed enough below my total upload (256kb/sec) that I don't notice slowdowns when one or the other is running.

On the occaisions that both run at the same time, however, their bandwidth limits exceed the maximum upload of my connection, and saturate it (Meaning sloooow internet for me).  This is not ideal.

I would like to be able to configure, through QoS or whatever else, rules that allow those services to saturate my connection until I use the connection for something else, at which point they back down gracefully and allow me to do my things unimpeded because my tasks (Email, Internet, etc.) are higher priority.

I know that ASL4 had the option to prioritize packets without setting hard limits on them, but I'm not sure aboust 5.  Reading the second post here,  it seems that I can only set hard limits on the different priorities.  I don't understand why this would be useful to anyone over true bandwidth shaping and prioritizing.

What do I need to do to maximize the efficiency of the two services while not impeding my connection use?

Thanks,
~Ryan


This thread was automatically locked due to age.
  • [ QUOTE ]
    I have installed BitTorrent and Direct Connect. They use ports  and  respectively.

    [/ QUOTE ]If you use an advanced, state of the art, Bit Torrent client such as Azureus, then you only need external access to port 6881. Ports 6882, 6883, etc. are not needed.

    Port 6969 is the tracker service port. Access to it from the outside is only needed if you are operating your own tracker for any original torrents that you are seeding. If you use an external tracker service (I use tracker.prq.to  for the bit torrents that I originate, which is The Pirate Bay in Stockholm, Sweden, the world's largest tracker site) then there is no need to have any port 6969 access.

    In short, you can run multiple bit torrents, seeding and/or leeching,  with only port 6881 accessible through your ASL firewall from the outside. If you close the other ports that you opened up for your bit torrent client, and just use port 6881, than that should help you simplify your QoS configuration.
  • I do use Azureus.  Thank you for the heads-up on the ports that aren't necessary.  Either way, however, it doesn't matter much because I can just use the "torrent" service group definition in creating QoS rules.

    I'm also still curious about how to properly prioritize it.  I'd still like it to be such that I don't have to limit Azureus/DC++, except when I want to use the computer, and am given priority.

    Is there no way to do this?
  • Set their priority to low in the packet filter page?
  • If you are using the Azureus bit torrent client, you can set the maximum download and upload rates that are being used by the bit torrent traffic from inside the client.

    As an example, I have an ADSL connection that is rated at 1.5 Mbit/sec down, and 512 Kbit/sec up. I have configured my Azureus client for a maximum upload rate of 36 KBytes/sec (approximately 360 Kbit/sec with the overhead). That way I make sure that the bit torrent traffic does not saturate my uplink, since I also run VPN, webserver and FTP server.

    I have QoS configuration in place for the outbound traffic on my ASL v4 firewall, but when it comes to the bit torrent traffic, the easiest spot to trottle back the download and upload rates are right within the client itself. This is particularly easy to do with Azureus.

    Left to its own devices, a bit torrent client, particularly if you are participating in several bit torrent swarms at the same time, will consume all available bandwidth in both directions. To try to deal with this in some other place than the client itself, is only going to result in unnessesary packet drop.