[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Martijn Grooten wrote:
>
> No, I do mean outbound. I'm using a rather old business ADSL line
> which is capped at about 40KB/s. I've had a go at setting the TOS
> using iptables as described here
> http://lartc.org/howto/lartc.cookbook.interactive-prio.html but I've
> not seen any effect. Now I'm getting suspicious that this might be
> because the machine has a fine connection to its next hob, which is a
> gateway/router and which it shares with some other machines. It's at
> the gateway that the traffic is capped. So am I right that this is
> where I should play around with iptables rather than on my own
> machine?
If it is a Linux box yes, otherwise as I said you need the queue
building up on an interface you control.
Setting TOS will have almost no effect unless the queue where packets
are waiting before the slow hop is respecting those bits.
>> Do you cache the DNS information locally? If not I'd start with that, since
>> that will reduce traffic and improve performance.
>
> I don't cache DNS information but then, I'm not doing the DNS lookups
> myself, that's done by machines/programs I'm testing, so if they don't
> do clever DNS lookups, then it's not up to me to fix it.
> Moreover,
> most DNS lookups are lookups against DNSBLs, so lots of different
> addresses all the time; I guess that even the most clever DNS-caching
> would only half the amount of DNS lookups. (Whereas lookups of
> www.google.com take 100 times as long when the outbound bandwidth is
> fully used.)
Yes, but Google doesn't change much, so local caching would eliminate
that 100 fold time increase, even if you are only gaining on half the
addresses looked up, by definition you gain it on those you use most.
DNSBL lookup performance probably doesn't matter much, as it isn't
interactive, where as browser performance can hurt.
The biggest gain for DNS caching locally is usually answering the stupid
queries. So the more stupid or badly configured clients are the bigger
the gain from caching DNS.
So I think you should be aware what is happening, if only sniffing the
outbound traffic to ensure there aren't lots of stupid queries being
sent out.
Traffic shaping makes sense when you need to prioritize traffic, or
guarantee a specific performance for a given application. For example
guaranteeing DNS performance is fine, if DNS performance matters (or
performance of new connections matters since they often need DNS), but
the steps you need to take to do this will decrease overall performance
marginally, and non-DNS traffic significantly if you are sending a lot
of DNS requests.
Similarly an HTTP proxy might reduce traffic on this link.
> As for wondershaper, does it do more than set the TOS using iptables?
Yes it ensures the traffic queues on the interface it is set. So if you
say "wondershaper eth0 370 8000" it will applies some queues to eth0 and
force traffic to go at 8000Kbits per second from that interface.
You can see the change of queue by typing "ip addr list" or "ip addr
show eth0"
# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP qlen 100
link/ether 00:0c:f1:c9:a9:67 brd ff:ff:ff:ff:ff:ff
inet 10.254.239.1/24 brd 10.254.239.255 scope global eth0
# wondershaper eth0 370 8000
# ip addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc cbq state UP
qlen 100
link/ether 00:0c:f1:c9:a9:67 brd ff:ff:ff:ff:ff:ff
inet 10.254.239.1/24 brd 10.254.239.255 scope global eth0
Before wondershaper the queuing algorithmn is the default pfifo_fast
(see man pfifo_fast), after it is CBQ (Class based queuing - yes "man
cbq" works).
You need the "tc" command to see what the queuing is, and to be honest
it is darned confusing to decipher what a particular set of queues and
filters does. Far easier to write a script to do what you want than to
debug someone else's configuration.
You'd have to see the man page for wondershaper, and I'm not a huge fan
of wondershaper as it probably does more than you want. But it does the
right sort of thing, so well worth understanding how it works if you
need to do something similar. We use HTB ("man htb") at work, as it is
much more suitable for simply guaranteeing minimum bandwidth to specific
services.
Note the default pfifo_fast respects TOS bits, but I'm guessing the
interface on your box can send at 100Mbps to the router, so it probably
never has more than a handful of packets queued at any one time. So the
most boost it can ever give a packet is to send it ahead of it's very
short queue.
--
The Mailing List for the Devon & Cornwall LUG
http://mailman.dclug.org.uk/listinfo/list
FAQ: http://www.dcglug.org.uk/linux_adm/list-faq.html