I think I am missing something about QOS, because as nearly as I can tell it isn't working for me.
I am running dd-wrt SP1 final(end of may build). I can get about 310 up and 3000b/s down. I have my QOS settings set to 295/2900 up/down. I have bittorrent L7 and bittorrent ports set to bulk. I also play with MUTE occassionally and that also has the L7 and additionally the port set to bulk.
Basically it doesn't seem to do anything. If I test things by starting up bittorrent all other traffic has horrible performance. Even if I put the desired high level service (like sip or html) up to premium. websites time out, page not found errors, pages take forever to load, voice quality is horrible.
The only way I have found to bring things back into useability is to manually lower the BT upload stream on the BT client itself to something quite small.
1. So what am I missing?
I thought that QOS would prioritize my traffic so that I wouldn't receive a performance hit on my top applications, but allow low priority applications to dynamicly use up the remnant bandwidth.
2. One of the two QoS algorithms is a heirarachical one and the explaination I saw looked like it would require an external definition of the bandwidth available at each level of the tree. Is this automagically determined or is there a setup screen I am missing?
3. Which algorithm typically works the best with what kind of traffic?
I have the excact same problem. Even specified a manual service ping with protocol icmp at premium priority, http/dns with express, and all ethernet ports with standard.
When uploading/downloading with ftp/bittorrent/whatever: ping and browsing becomes horribly slow.
The download/upload speed is set way below actual link speed (2/3). Have tried both schedulers.
Also tried with two different routers with DD-WRT v23 SP1 final.
WRT54GL v1.1 and WRT54G v2.2
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Thu Jun 22, 2006 20:54 Post subject:
post a screenshot of your qos page _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Joined: 18 Jun 2006 Posts: 1110 Location: Kiel (54.4247,10.1721)
Posted: Sat Jun 24, 2006 9:16 Post subject:
BrainSlayer wrote:
post a screenshot of your qos page
Since I have the same problems with it I'll take the task and post my settings, but first my setup:
Arcor DSL 3000/512 - DSL-Modem - WRT54GSv1.1 (DD-WRT v23 SP1 Final (06/19/06) std) - one long wire to another switch - ONLY wired clients
My Problem:
I have a webserver running including a site for our webcams which get a lot of image request during summertime because you can look at the beach ;D
To prevent our upstream from beeing jammed and also avoid a ftp-password to be transmitted frequently in cleartext (=uploading the image to an external webserver) we made a cache script using php which lies on an external server, it loads the image from us and caches it, if like 10 people at a time are on our page they all get this image (=no traffic to us) only if the cached image is older than 10secconds the script will get a new one.
Pro: no users = no traffic, 1000users = 1xtraffic
Cont: the external server makes one request but this gets the full bandwidth, a 100mbit connected machine sucking up a 512kbit connection.. Which makes Voip and online gaming a mess, every some secconds during a game my ping goes from 15-20 up to 800ms, and back of course, and during a voice call the voice stucks.
So that is why I want QoS ;D (Everyone has a personal scenario, this is mine.
Additional Info:
I only use one LAN Port as mentioned to get up to my switch, so all clients user one port => prioritize by port will not work
The webserver also acts as an Voip Gateway=> prioritize by mac address will not work.
My problem is that the upstream bandwith does not get affected as I want, i set upstream to 100 (which is far below the 80% of my 512k) like you can see here:
but it still get nearly full upstream bandwith (why not using arcors speedtest when using arcor-dsl?):
but downloads still get nearly full bandwidth:
Joined: 06 Jun 2006 Posts: 7492 Location: Dresden, Germany
Posted: Sat Jun 24, 2006 14:03 Post subject:
since you have http in standad queue it should reach almost full speed. i dont see any problems in your setup and it still works as it should. qos takes a real effect if you're downloading something with bittorrend and then you start a http download. you will see that the bittorrent speed will be reduced at this time _________________ "So you tried to use the computer and it started smoking? Sounds like a Mac to me.." - Louis Rossmann https://www.youtube.com/watch?v=eL_5YDRWqGE&t=60s
Joined: 18 Jun 2006 Posts: 1110 Location: Kiel (54.4247,10.1721)
Posted: Sat Jun 24, 2006 14:42 Post subject:
BrainSlayer wrote:
since you have http in standad queue it should reach almost full speed.
Even if I set the "Uplink (kbps)" too 100 it shall be normal that it can upload with >500? That really suprises me...
BrainSlayer wrote:
i dont see any problems in your setup and it still works as it should. qos takes a real effect if you're downloading something with bittorrend and then you start a http download. you will see that the bittorrent speed will be reduced at this time
Well, i tried a different shaper (tbf rate shaping as root and the childs as priorities) which really works well, now i've got another question:
Is there a place inside the /jffs directory where i can place script that get executed at boot time/if-up-time and so on? So I can place my own shaper script inside my /jffs dir and it will get executed on ifup ppp0?!
Even if I set the "Uplink (kbps)" too 100 it shall be normal that it can upload with >500? That really suprises me...
I don't think those fields are meant to be hard limits - they're there to characterize your line speed so the Wundershaper can prioritize ACK's appropriately. _________________ Formerly participating under a pseudonym to counter an unjust Sveasoft practice.
Joined: 18 Jun 2006 Posts: 1110 Location: Kiel (54.4247,10.1721)
Posted: Mon Jun 26, 2006 17:34 Post subject:
bill_mcgonigle wrote:
I don't think those fields are meant to be hard limits - they're there to characterize your line speed so the Wundershaper can prioritize ACK's appropriately.
As far as i got the point with limiting the upstream ist to make sure that the queue you have at the ISP-Side of your link will not get full, so those should really be hard limits.
I am using a different kind of QoS now, besides priority shaping I use tbf rate which really does limit the upstream to the rate you say him. Works like charm for me.
(therefore having different problems )