Eric,
I have spent a good day looking at your QoS implementation. Its going to be awhile before I come up with a complete design to show you but a couple of things.
You make pretty extensive use of iptable chains for BW monitoring. I have not done any throughput testing but this has got to have an impact I would think. My design will have much less chain traversals so performace will improve.
Have you thought about monitoring the qdisc instead? These are already maintained so would not mean extra burdon on the router?
Also looking at your QoS script it did not take long to see that there is linkage with your BW monitor there. Can you elaborate on that? How are the MARKS used by the BW monitor?
BW Monitoring and QoS Efficiency
Moderator: Moderators
BW Monitoring and QoS Efficiency
Linksys WRT1900ACv2
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM
Netgear WNDR3700v2
TP Link 1043ND v3
TP-Link TL-WDR3600 v1
Buffalo WZR-HP-G300NH2
WRT54G-TM
Re: BW Monitoring and QoS Efficiency
The number of chains a packet traverses doesn't have all that big an impact on the CPU. What does have an impact is the nature of the rules it is tested against. Some matches (like checking protocol, or src or dst ip address) are really quick, while others (like layer 7 matching) chew up a ton of memory/cpu. What matters isn't the number of rules, but the nature of the rule in question. One layer7 match can be a LOT slower than a hundred src matches.
The bandwidth match is designed not to take up many CPU resources on match, so this isn't going to be the culprit. I know this because it's a custom module that I wrote myself and optimized to use as few resources as possible. Also, doing monitoring in iptables means that I don't need a bandwidth monitoring daemon running. That's one less process taking up overhead, which helps reduce memory use. Finally, if QoS isn't enabled, I still need the bandwidth monitor to run... so monitoring qdiscs alone isn't the answer.
Right now, bandwidth monitor merely monitors CONNMARKS, not marks. The first CONNMARK byte contains the MARK for the upload traffic class, and the second CONNMARK byte contains the MARK for the download traffic class. That way, if a connection is already classified the mark can be set directly from the CONNMARK with the appropriate mask, and the connection continues to hold the traffic class it originally had.
The bandwidth match is designed not to take up many CPU resources on match, so this isn't going to be the culprit. I know this because it's a custom module that I wrote myself and optimized to use as few resources as possible. Also, doing monitoring in iptables means that I don't need a bandwidth monitoring daemon running. That's one less process taking up overhead, which helps reduce memory use. Finally, if QoS isn't enabled, I still need the bandwidth monitor to run... so monitoring qdiscs alone isn't the answer.
Right now, bandwidth monitor merely monitors CONNMARKS, not marks. The first CONNMARK byte contains the MARK for the upload traffic class, and the second CONNMARK byte contains the MARK for the download traffic class. That way, if a connection is already classified the mark can be set directly from the CONNMARK with the appropriate mask, and the connection continues to hold the traffic class it originally had.