The problem is that the DNS resolver in glibc has a too low setting
for retransmits before giving up (4-5 or so only, it's also a big problem
together with dynamic IP and dial-on-demand where the socket address rewriting
needs some time) Fix is to change glibc to retransmit more often and
recompile it or alternatively use a local dns proxy that does more aggressive
retransmits (that won't fix the low timeout though)
> I'm curious about this effect so I've been trying to find information
> on this and while I can find lots of information on the Ethernet
> capture effect there doesn't seem to be anything on the TCP capture
> effect. Could someone point me at an explanation of this effect?
I also don't know that term, but the basic problem is that TCP only slows
down when its packets are dropped. Packets are dropped when a device queue
fills, and when one sender is much faster than the other the faster sender
often wins the race, while the packets of the slower one get dropped.
[this is a rough simplification; there have been many books and papers
written on queueing in the internet]
One problem is for example that Linux's default queue length is good
for ethernet, but not slower or higher latency links.
You can try to tune it using ifconfig device txqueuelen <number>.
Try values between 5-30, default is 100.
DSL also has very asymetric bandwidth, if you're saturating e.g. the uplink
channel completely acks in the other direction will also have a hard
time to get through.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/