Trond, et al.
I'm getting poor NFS performance (~250KBps read and write) on 2.4.18 and am
wondering if I'm the only one. There is no performance drop under other OSs
or other kernel versions, so I don't think it's the server.
Here's the the details:
2.4.18 patched with:
NFS client patches (linux-2.4.18-NFS_ALL.dif)
xfs-1.1-PR1-2.4.18-all.patch
Ingo's Foster IRQ patch (these are dual Xeons)
If you need any more details, let me know.
Thanks,
Dan
--
Dan Yocum
Sloan Digital Sky Survey, Fermilab 630.840.6509
[email protected], http://www.sdss.org
SDSS. Mapping the Universe.
>>>>> " " == Dan Yocum <[email protected]> writes:
> Trond, et al. I'm getting poor NFS performance (~250KBps read
> and write) on 2.4.18 and am wondering if I'm the only one.
> There is no performance drop under other OSs or other kernel
> versions, so I don't think it's the server.
> Here's the the details:
> 2.4.18 patched with:
> NFS client patches (linux-2.4.18-NFS_ALL.dif)
> xfs-1.1-PR1-2.4.18-all.patch Ingo's Foster IRQ patch (these
> are dual Xeons)
> If you need any more details, let me know.
The latest NFS_ALL patches include experimental code that changes the
UDP congestion control. I'm basically trying to relax the algorithm to
what is standard on *BSD (i.e. we follow the standard Van Jacobson).
This would mean that we don't wait for the reply from the server
before we send off the next request. Unfortunately, there appears to
be a lot of setups out there that start to drop packets when this
occurs, and I haven't yet finished determining the root cause.
If I can manage to get my laptop to work again, I'll try to
investigate a bit more this weekend...
Cheers,
Trond
Trond,
So, would I be correct in assuming that backing out the
linux-2.4.18-ping.dif patch would solve the problem in the short term?
Thanks,
Dan
Trond Myklebust wrote:
>
> >>>>> " " == Dan Yocum <[email protected]> writes:
>
> > Trond, et al. I'm getting poor NFS performance (~250KBps read
> > and write) on 2.4.18 and am wondering if I'm the only one.
> > There is no performance drop under other OSs or other kernel
> > versions, so I don't think it's the server.
>
> > Here's the the details:
>
> > 2.4.18 patched with:
> > NFS client patches (linux-2.4.18-NFS_ALL.dif)
> > xfs-1.1-PR1-2.4.18-all.patch Ingo's Foster IRQ patch (these
> > are dual Xeons)
>
> > If you need any more details, let me know.
>
> The latest NFS_ALL patches include experimental code that changes the
> UDP congestion control. I'm basically trying to relax the algorithm to
> what is standard on *BSD (i.e. we follow the standard Van Jacobson).
>
> This would mean that we don't wait for the reply from the server
> before we send off the next request. Unfortunately, there appears to
> be a lot of setups out there that start to drop packets when this
> occurs, and I haven't yet finished determining the root cause.
>
> If I can manage to get my laptop to work again, I'll try to
> investigate a bit more this weekend...
>
> Cheers,
> Trond
--
Dan Yocum
Sloan Digital Sky Survey, Fermilab 630.840.6509
[email protected], http://www.sdss.org
SDSS. Mapping the Universe.
>>>>> " " == Dan Yocum <[email protected]> writes:
> Trond, So, would I be correct in assuming that backing out the
> linux-2.4.18-ping.dif patch would solve the problem in the
> short term?
Not ping, but linux-2.4.18-rpc_tweaks.dif...
Cheers,
Trond