Mick wrote:
I think that the problem is associated with the way that the Linux box treats
bind requests. Other than QoS which will try to allocate some bandwidth to
bind packets, or nice which will elevate bind's processes - you may want to
check your kernel's IO scheduler and set it to something that will give each
process an equal bite of the cherry. Trial & error may get you there.
I don't think QOS is the right answer - since I've never seen this
problem before - and I've never used QOS on Linux before. I think that
the scheduler might explain things far better. I half-remember something
about the inclusion of the new "CFS" scheduler when I compiled the
kernel - maybe the default changed when I moved to the 2.6.23-gentoo-r3
kernel from - erm - some older 2.6 version many months ago.
Maybe I should upgrade to the latest kernel (I'm reluctant to do this in
a hurry - since I've lost my notes on which kernel options I'd activated
- and it's a 'live' box I'm using on a day-to-day basis that I'd rather
not break. Doah!)
A workaround to avoid WinXP name requests timing out is to manually set at
your WinXP clients the Netgear's IP address as their secondary DNS server.
That's a fantastic hack... I like the idea... though, obviously, if it
were trivial, I'd prefer Bind on gentoo not to hang. ;)
My router is a "Netgear Wireless ADSL Firewall Router" - it seems pretty
common... and I've not found other people moaning that it has
problems... For me, it only has problems when accessed from my Linux box.
I used to run a Netgear DG834 and did not notice anything like this. After a
few seconds the Gentoo and WinXP clients would share the bandwidth -
irrespective of which one started downloading first. WinXP might have been
slightly more hesitant to start with, but after say 30 seconds it would even
out. However, this was with wired full duplex connections. Wireless is half
duplex, transmit and receive happens sequentially not in parallel - when
downloading on the Gentoo goes at full pelt it may take longer for inbound
packets to get to bind and this could make the rather short TTL that
MSWindows has to time out.
That's encouraging. Always good to know that there are no 'known'
bugs... I was caught out by this a few years ago with a DLink router -
where I assumed it was my FreeBSD box at fault - but, actually, the
router had broken firmware.
PS. Have you tried this with two Linux clients (use Knoppix on one of your
MSWindows boxen)?
No, I could, I guess - but I'm 95% convinced now that this is an I/O
scheduling issue on my Gentoo box - and is not an issue with my router.
Many thanks.
