Make sure that all the NICs are set to the same speed/duplex. I normally
force all network cards to 100MB/Full Duplex.. Take off the auto
setting.

On Thu, 2005-08-11 at 11:23 -0700, Jason Williard wrote:
> While using my NFS shares, I have noticed that there is a severe decrease in
> speed. I understand that working across a network can be slow, but this
> seems extreme. For example, when downloading the latest version of Perl
> directly to an NFS share, it will download about 7%, pause for a couple
> seconds, download another 7%, pause and this continues until the download is
> complete. Extracting the file takes about 10 times as long on the NFS share
> as it does locally.
>
> I am working with servers on a network using 100Mb connections. Does anyone
> know why this may be occuring?
>
> Thank You,
> Jason Williard
>
>

What release are you using, RedHat ES3 did have NFS problems but I believe
it was fixed in Update 4? What errors are you seeing if you use nfsstat
and do you see any errors in the messages file?

Simon



On Thu, 11 Aug 2005 11:23:13 -0700, Jason Williard wrote:

> While using my NFS shares, I have noticed that there is a severe decrease in
> speed. I understand that working across a network can be slow, but this
> seems extreme. For example, when downloading the latest version of Perl
> directly to an NFS share, it will download about 7%, pause for a couple
> seconds, download another 7%, pause and this continues until the download is
> complete. Extracting the file takes about 10 times as long on the NFS share
> as it does locally.
>
> I am working with servers on a network using 100Mb connections. Does anyone
> know why this may be occuring?
>
> Thank You,
> Jason Williard

In article ,
Olivier wrote:
>>
>Hi had terrible performance on NFS shares because of a duplex mismatch
>on my network card. The symptom was exactly yours: hi speed, then stall,
>etc. With an average transfer speed just miserable.
>Check your interfaces with mii-tool and check also your switches.

Yes, do everything that people have said, largely because they are
easy and generically useful checks. But there is a LOT more than can
cause this, most of which you had better pray you don't see :-(

With SunOS 4.1 and HP-UX 7/8, there was dire TCP performance one way
because Sun had taken one approach to tuning (large windows) and HP
the other (packet aggregation in the kernel). Traditional NFS would
not see this, but I know that such issues are still extant with some
combinations of system. And, of course, this does not affect UDP.

There can be horrible scheduler-related issues. The data paths are
long, tortuous, and there is no tracing worth a damn. The worst I
have seen is a transfer taking FIVE (5) seconds from an application
to the driver (i.e. strace to snoop) on an essentially idle system
with several times more spare CPUs than runnable threads.

[ Note that I don't mean JUST the main scheduler here, but include
such things as implicit scheduling caused by kernel locks, memory
allocation and so on. These are probably more important for I/O
data paths than the main process/thread scheduler. ]

I haven't investigated Linux in enough detail to know the comparable
problems with it, but I have reason to believe that both of those
are likely at least in some Linux configurations.


Regards,
Nick Maclaren.