Mini-FAQ: QoS setup on the RouterTech firmware

All about firmwares for routers. Support for RouterTech firmwares is here too.
User avatar
Shotokan101
RouterTech Team
RouterTech Team
Posts: 4779
Joined: Thu Jan 26, 2006 3:17 pm
Location: Glasgow, Scotland

Post by Shotokan101 » Thu May 10, 2007 12:47 am

legume wrote:
How do you display the "tc" info. ?
tc filter ls dev ppp0

It's horrible to read :-)

Andy.
What firmware are you running Andy ?

The command doesn't work for me (but I'm on a Beta f/w)....
Jim

.....I'm Sorry But I Can't Do That Dave.....
legume
Experienced
Experienced
Posts: 101
Joined: Fri Apr 13, 2007 11:57 pm

Post by legume » Thu May 10, 2007 12:58 am

What firmware are you running Andy ?

The command doesn't work for me (but I'm on a Beta f/w)....
2.2 I assume you are shaping on wan and wan is ppp0 (0=zero) the "ls" is lowercase LS as in list

tc filter show dev ppp0 should also work.

Andy.
User avatar
Shotokan101
RouterTech Team
RouterTech Team
Posts: 4779
Joined: Thu Jan 26, 2006 3:17 pm
Location: Glasgow, Scotland

Post by Shotokan101 » Thu May 10, 2007 1:07 am

Code: Select all

BusyBox on RouterTech.AR7WRD_R login: root
Password:

*********************************************************
*   ROUTERTECH AR7WRD (series R) LAN 4-PORT/WiFi/USB    *
*********************************************************


BusyBox v0.61.pre (2007.03.15-09:44+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

/var # tc filter ls dev ppp0
Error: No support for filter. Please build 'tc' with TC_CONFIG_ALL
Object "filter" is unknown, try "tc help".
/var #
/var #
/var # tc filter show dev ppp0
Error: No support for filter. Please build 'tc' with TC_CONFIG_ALL
Object "filter" is unknown, try "tc help".

.... :? (although it IS a non-standard beta) ....
Jim

.....I'm Sorry But I Can't Do That Dave.....
legume
Experienced
Experienced
Posts: 101
Joined: Fri Apr 13, 2007 11:57 pm

Post by legume » Thu May 10, 2007 1:24 am

/var # tc filter ls dev ppp0
Error: No support for filter. Please build 'tc' with TC_CONFIG_ALL
Oh dear I wonder whether just the output or qos is totally broken for you.

Heres what I get for one very simple rule which just puts udp as high prio.

Code: Select all

/var # tc filter ls dev ppp0
filter parent 51: protocol ip pref 1 u32
filter parent 51: protocol ip pref 1 u32 fh 804: ht divisor 1
filter parent 51: protocol ip pref 1 u32 fh 804::800 order 2048 key ht 804 bkt 0 flowid 51:2
  match 00110000/00ff0000 at 8
filter parent 51: protocol ip pref 1 u32 fh 804::801 order 2049 key ht 804 bkt 0 flowid 51:2
  match 00110000/00ff0000 at 8
filter parent 51: protocol ip pref 1 u32 fh 800: ht divisor 1
filter parent 51: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 51:4
  match 00000000/00000000 at 12
  match 00000000/00000000 at 16
  match 00000000/0000ff00 at 8
  match 00000000/ffffffff at 20
filter parent 51: protocol ip pref 1000 u32
filter parent 51: protocol ip pref 1000 u32 fh 804: ht divisor 1
filter parent 51: protocol ip pref 1000 u32 fh 804::800 order 2048 key ht 804 bkt 0 flowid 51:2
  match 00110000/00ff0000 at 8
filter parent 51: protocol ip pref 1000 u32 fh 804::801 order 2049 key ht 804 bkt 0 flowid 51:2
  match 00110000/00ff0000 at 8
filter parent 51: protocol ip pref 1000 u32 fh 800: ht divisor 1
filter parent 51: protocol ip pref 1000 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 51:4
  match 00000000/00000000 at 12
  match 00000000/00000000 at 16
  match 00000000/0000ff00 at 8
  match 00000000/ffffffff at 20
You get reams for more complicated stuff - partly due to duplicate output on old tc/kernels.

FWIW that last rule looks like it will never match anything to me - I think it's there to do with trusted box, but looks wrong.

If I didn't do Qos on my other gateway anyway I think I would script myself - could use the highest prio then aswell and have a bit more control.

One thing that the web interface doesn't offer is prio by packet size - I use that in my own script - It's nice to prio acks so upload doesn't hurt download.

Andy.
User avatar
Shotokan101
RouterTech Team
RouterTech Team
Posts: 4779
Joined: Thu Jan 26, 2006 3:17 pm
Location: Glasgow, Scotland

Post by Shotokan101 » Thu May 10, 2007 1:28 am

Looks like it's just due to a variation in my beta f/w build I think
Jim

.....I'm Sorry But I Can't Do That Dave.....
ssmaxss
Newbie
Newbie
Posts: 1
Joined: Sun Apr 29, 2007 5:37 pm

Post by ssmaxss » Thu May 10, 2007 11:37 am

Hi! Are there any chances that RouterTech will support jdg-qos script (it needs ipp2p module for detection of p2p packets)? I have used it in Dlink G604T firmware by McMCC and it is great.
User avatar
Neo
RouterTech Team
RouterTech Team
Posts: 3586
Joined: Thu Jan 26, 2006 1:09 pm
Contact:

Post by Neo » Thu May 10, 2007 12:49 pm

@ ssmaxss - I have moved your post to the QoS Mini-FAQ thread as that seems a more appropriate location ;)
RouterTech Team and Founding Member
Image
RouterTech Merchandise (UK)
No support via PM, please ask your questions on the forum!
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12067
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Post by thechief » Thu May 10, 2007 5:54 pm

ssmaxss wrote:Hi! Are there any chances that RouterTech will support jdg-qos script (it needs ipp2p module for detection of p2p packets)? I have used it in Dlink G604T firmware by McMCC and it is great.
Have no idea what it is, or how much work it would take to support it.
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
User avatar
Shotokan101
RouterTech Team
RouterTech Team
Posts: 4779
Joined: Thu Jan 26, 2006 3:17 pm
Location: Glasgow, Scotland

Post by Shotokan101 » Thu May 10, 2007 6:16 pm

I came across this when I was looking for some iptables info. a while ago

http://www.digriz.org.uk/jdg-qos-script/
Jim

.....I'm Sorry But I Can't Do That Dave.....
User avatar
Shotokan101
RouterTech Team
RouterTech Team
Posts: 4779
Joined: Thu Jan 26, 2006 3:17 pm
Location: Glasgow, Scotland

Post by Shotokan101 » Thu May 10, 2007 6:32 pm

Some good info. on Qos in general and wondershaper and jdg-qos on this forum thread :-

http://www.broadbandreports.com/forum/remark,16250220
Jim

.....I'm Sorry But I Can't Do That Dave.....
User avatar
thechief
RouterTech Team
RouterTech Team
Posts: 12067
Joined: Wed Feb 01, 2006 10:22 pm
Location: England, the Centre of Africa
Contact:

Post by thechief » Thu May 10, 2007 6:55 pm

Thanks. It looks too much like hard work.
The Chief: :afro: Be sure to read the Firmware FAQ and do a Forum Search before posting!
No support via PM. Ask all questions on the open forum.
aaaaa
Newbie
Newbie
Posts: 5
Joined: Wed Oct 17, 2007 8:47 pm

Post by aaaaa » Sat Oct 20, 2007 9:15 am

I don't suppose you guys know a way to prioritise ACK packets? I hear putting them on high priority is very helpful during a saturated network.

And a quick QOS-theory question, if I have a protocol on low priority, say 20%, and but its the only thing running on the network, will it get 20% of the speed or will it use all the network resorcses until a high priority protocol starts being used and kicks it into the slow lane.
legume
Experienced
Experienced
Posts: 101
Joined: Fri Apr 13, 2007 11:57 pm

Post by legume » Sat Nov 17, 2007 6:46 pm

Prio for acks is good and It's roughly possible by using tc to match the length field in an IP packet to select packets < 64 or 128 etc bytes. You can go further and match the ack bit aswell - personally I don't bother.

Less than 64 will catch most empty acks - 128 all, but will catch other traffic aswell.

If you wanted to do it on routertech you would need to script it - and possibly make sure the script gets rerun when the wan goes down and comes back.

The QOS on routertech uses a TI qdisc priowrr that is not like normal Linux qdiscs. It doesn't actually rate limit so a class with 20% will use all the bandwidth if no other traffic needs it.

If you are still interested/reading this one month on, post and I can post more detail.

I do use Linux for QOS, but do it on a different box so don't have anything that will work directly on rtech. At least you won't need to patch the kernel for atm overheads like you do to shape properly on a dsl line with rate limiting Linux qdiscs.

Andy.
User avatar
Shotokan101
RouterTech Team
RouterTech Team
Posts: 4779
Joined: Thu Jan 26, 2006 3:17 pm
Location: Glasgow, Scotland

Post by Shotokan101 » Sat Nov 17, 2007 6:53 pm

It's always interesting to eget tech. Info. Legume - post away :wink:
Jim

.....I'm Sorry But I Can't Do That Dave.....
legume
Experienced
Experienced
Posts: 101
Joined: Fri Apr 13, 2007 11:57 pm

Post by legume » Sun Nov 18, 2007 10:19 pm

The match for IP total length just looks like this

Code: Select all

match u16 0x0000 0xff80 at 2
Two bytes into an IP packet is a 16 bit total length field.
The match uses a mask of 0xff80 and matches 0 so any packet < 128 bytes in this case will match.
0xffc0 should match < 64 bytes - you can only do powers of 2.

You can also match tcp as the payload from the protocol field

Code: Select all

match ip protocol 6 0xff
tc saves you looking up the ofset for this one, but still needs the mask.

You could go on into the tcp header to match the ack flag, as some examples do. I was never convinced it's trully needed as almost all tcp packets have it set.

There is a complication when matching past IP because IP headers are variable length - though in practice nearly all are 20. You can check for this as some examples do - they just bail out of the match when faced with a long IP header.

Acks can eat a fair chunk of upstream bandwidth if you have a highly asymmetric dsl line.
An ack may be as small as 40 bytes IP, but that takes 2 ATM cells so it will use 106 on the wire.
An 8128/448 connection would use all it's upstream bandwidth if TCP acked every packet - delayed acks mean it's more like every other, but there are times when it will do one per packet - eg. after loss.

Generally if you want to flood your upstream and have decent browsing / gaming and download speed you need to make sure dns/game traffic gets top prio acks next and bulk tcp lowest. You also need to somehow prio http gets - you get a burst of these when opening a web page.

How you actually do the above is the tricky bit - it depends on what traffic/apps you have on your network. Personally I just give top to not tcp second to < 128 tcp and dst port 80 (for the GETs - this fails if someone uses 80 for upstream bulk traffic - like msn file transfers). I also have a match for the IP's of the game servers my son uses for tcp games like wow and tibia - all the rest are udp.

I suppose if you have alot of bulk going to 80, then it would be possible to match the word GET in the tcp payload - a quick tcpdump shows me that it's in the same place in the packets - but tcp headers are also variable length and you are more likely to get longer ones than IP due to sacks after loss. It would still be far better than doing nothing, though.

I get away with just putting udp top as I don't use apps that use udp for bulk (like tvutime) or have any tunnels, webcams sometimes use udp but it's not enough to flood my line YMMV.

TI's priowrr qdisc is documented by comments in the source. It has 2 absolute prio - one hidden from the GUI as reserved for voip, but I assume it will work from a script.
After the prio are 2 wrr classes which get what's left and it is shared out depending on what percentage you give the classes.

I'll try a test sometime if I get a chance of the net to myself - probably not tonight.

Andy.
Post Reply