I am currently using the ultimate-tc script from 
http://lartc.org/howto/lartc.cookbook.ultimate-tc.html
and I want to make sure that internet radio packets (mp3 streaming audio)
will always get through no matter what. I have added some iptables commands
like this:
iptables -A OUTPUT -t mangle -p tcp --dport 8000 -j TOS --set-tos 
Minimize-Delay
iptables -A OUTPUT -t mangle -p tcp --sport 8000 -j TOS --set-tos 
Minimize-Delay
with the aim of marking the streaming audio packets so that they will get
a higher priority: but I''m not sure if this is needed or exactly how it
works!
Some audio streams come in with the incoming packets marked [tos 0x40] and
the outgoing packets marked [tos 0x10] (according to tcpdump) but not all.
The ultimate-tc script ends with these ingress rules:
########## downlink #############
# slow downloads down to somewhat less than the real speed  to prevent 
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
# attach ingress policer:
tc qdisc add dev $DEV handle ffff: ingress
# filter *everything* to it (0.0.0.0/0), drop everything that''s
# coming in too fast:
tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1
This will drop packets to keep the download rate just below the maximum
capacity of the link: which will keep the ISP''s queue empty and improve
latency. But I am concerned that if there are a *lot* of other download
streams going at the same time as my audio stream, then these rules
may drop lots of packets from the audio stream and cause it to skip.
Should I add rules to drop audio stream packets at ${DOWNLINK}kbit rate
and drop all other traffic at $[9*$DOWNLINK/10]kbit rate, in the same way
that ultimate-tc does for outgoing traffic? If so, what should the rules look
like?
Something else I don''t understand about ultimate-tc is that the high
priority
class gets a rate of ${UPLINK}kbit and the low priority class gets
$[9*$UPLINK/10]kbit: but doesn''t the rate refer to traffic *in that
class*.
Traffic-Control-HOWTO Section 7.1.5. (Rules) says:
"Ideally, the sum of the rates of the children classes would match the rate
of
the parent class, allowing the parent class to distribute leftover bandwidth
(ceil - rate) among the children classes." but this isn''t the case
for the
ultimate-tc script. 
-- 
			Martin
Martin.Ward@durham.ac.uk http://www.cse.dmu.ac.uk/~mward/ Erdos number: 4
G.K.Chesterton web site: http://www.cse.dmu.ac.uk/~mward/gkc/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Martin Ward wrote:> I am currently using the ultimate-tc script from > http://lartc.org/howto/lartc.cookbook.ultimate-tc.html > and I want to make sure that internet radio packets (mp3 streaming audio) > will always get through no matter what. I have added some iptables commands > like this: > > iptables -A OUTPUT -t mangle -p tcp --dport 8000 -j TOS --set-tos > Minimize-Delay > iptables -A OUTPUT -t mangle -p tcp --sport 8000 -j TOS --set-tos > Minimize-DelayOUTPUT only sees locally generated packets.> > with the aim of marking the streaming audio packets so that they will get > a higher priority: but I''m not sure if this is needed or exactly how it works! > > Some audio streams come in with the incoming packets marked [tos 0x40] and > the outgoing packets marked [tos 0x10] (according to tcpdump) but not all. >I would use MARK as other traffic may have TOS set, see below.> The ultimate-tc script ends with these ingress rules: > > ########## downlink ############# > # slow downloads down to somewhat less than the real speed to prevent > # queuing at our ISP. Tune to see how high you can set it. > # ISPs tend to have *huge* queues to make sure big downloads are fast > # > # attach ingress policer: > > tc qdisc add dev $DEV handle ffff: ingress > > # filter *everything* to it (0.0.0.0/0), drop everything that''s > # coming in too fast: > > tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \ > 0.0.0.0/0 police rate ${DOWNLINK}kbit burst 10k drop flowid :1 > > > This will drop packets to keep the download rate just below the maximum > capacity of the link: which will keep the ISP''s queue empty and improve > latency. But I am concerned that if there are a *lot* of other download > streams going at the same time as my audio stream, then these rules > may drop lots of packets from the audio stream and cause it to skip. > > Should I add rules to drop audio stream packets at ${DOWNLINK}kbit rate > and drop all other traffic at $[9*$DOWNLINK/10]kbit rate, in the same way > that ultimate-tc does for outgoing traffic? If so, what should the rules look > like?There are lots of complicated things you can do with policers/u32 but I have no experience. First thoughts are to mark all that aren''t -sport 8000 and change the police rule to police to police marked. iptables -A PREROUTING -t mangle -p tcp ! --sport 8000 -j MARK --set-mark 1 tc qdisc add dev $DEV handle ffff: ingress tc filter add dev $DEV parent ffff: protocol ip prio 1 handle 1 fw police rate ${DOWNLINK}kbit burst 10k drop flowid :1 I haven''t tested that.> > Something else I don''t understand about ultimate-tc is that the high priority > class gets a rate of ${UPLINK}kbit and the low priority class gets > $[9*$UPLINK/10]kbit: but doesn''t the rate refer to traffic *in that class*. > Traffic-Control-HOWTO Section 7.1.5. (Rules) says: > "Ideally, the sum of the rates of the children classes would match the rate of > the parent class, allowing the parent class to distribute leftover bandwidth > (ceil - rate) among the children classes." but this isn''t the case for the > ultimate-tc script. >I don''t do it like that - I use ceil and like my rates to add up - but I suppose it works OK. Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Andy Furniss wrote:> There are lots of complicated things you can do with policers/u32 but I > have no experience. > > First thoughts are to mark all that aren''t -sport 8000 and change the > police rule to police to police marked. > > iptables -A PREROUTING -t mangle -p tcp ! --sport 8000 -j MARK --set-mark 1 > > tc qdisc add dev $DEV handle ffff: ingress > > tc filter add dev $DEV parent ffff: protocol ip prio 1 handle 1 fw > police rate ${DOWNLINK}kbit burst 10k drop flowid :1 > > I haven''t tested that.Ignore that - it''s no good if your stream(s) use much bandwidth. If you only have one LAN interfave you can shape ingress by seting up queues on that. Andy. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/