I have also tested the examples at http://linux-tc-notes.sourceforge.net/tc/doc/sch_hfsc.txt in two different labs (both virtuals, I must say) and have not managed to see the expected latency results.
I think I can ask it in an easier way. With the configuration below I get far more delay on 192.168.10.0/24 traffic than on 192.168.20.0/24 traffic. Am I doing something wrong? If you think it is better to ask for support somewhere else and you know where, I'd be grateful if you let me know. Thank you. tc qdisc add dev eth0 root handle 1: hfsc default 90 tc class add dev eth0 parent 1:0 classid 1:1 hfsc ls m2 100kbps ul m2 100kbps tc class add dev eth0 parent 1:1 classid 1:10 hfsc rt m1 50kbps d...
HFSC: rt traffic far more delayed than ls traffic
Question on HFSC Real Time and Upper Limit
If there is Link Share, then Real Time has no limit. Not quite. Real Time never respects the upper limit, it doesn't matter if you use Link Share or not. Link Share always respects upper limit, and what's more also includes anything Real Time sent when it checks it.
Question on HFSC Real Time and Upper Limit
Added tag linux-tc-notes-1.05-1 for changeset 289a48e240ef
Release linux-tc-notes-1.05-1 - see ChangeLog.txt
Release linux-tc-notes-1.04-1 - see ChangeLog.txt
Added tag linux-tc-notes-1.04-1 for changeset d...
Release linux-tc-notes-1.03-1 - see ChangeLog.txt
clarify link share wording
Added tag linux-tc-notes-1.03-1 for changeset a...
The "tc filter .. police" command does not have parameter "limit"
linux-tc-notes-1.02-1 - the source forge release
Added tag linux-tc-notes-1.02-1 for changeset 6...