All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bogdan Costescu <bogdan.costescu@iwr.uni-heidelberg.de>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: nfs@lists.sourceforge.net, <netdev@oss.sgi.com>
Subject: Re: [NFS] nfs performance: read only/gigE/nolock/1Tb per day
Date: Tue, 23 Apr 2002 20:16:06 +0200 (CEST)	[thread overview]
Message-ID: <aa48ll$77b$2@main.gmane.org> (raw)
In-Reply-To: <shsznzubcdv.fsf@charged.uio.no>


[ cc-ed to netdev; the discussion was about receiving bursts of ICMP Time 
Exceeded messages after some large NFS datagrams could not be reassembled; 
sometimes down/up the interface on the receiver/reassembly side cures it ]

On 23 Apr 2002, Trond Myklebust wrote:

>      > How big are the datagrams compared with the MTU ? With 32K
>      > datagrams over Ethernet, you're talking about roughly a full Rx
>      > ring worth of packets (32 is common for the Rx ring size)...
> 
> It has been a while ago (I've since mothballed the machine) but I saw
> it on a Pentium 90 with only 8k write sizes. 4k was fine, 8k gave
> avalanches.

IMHO you can't comletely eliminate hardware related problems: apart from 
having a slow CPU, some early PCI implementations were buggy (although you 
don't say if it's PCI or ISA and what's the link speed).

>      > Does the other side sees these messages ?
> 
> IIRC, yes, and the server was resending the datagrams. From the code,
> it looks as if there is no attempt to stop loopback situations
> occurring when this goes on:
> i.e. resending an ICMP when the server resends a datagram which times
> out again appears to be possible. This might be what was happening...

That's why I cc-ed netdev. My knowledge above the driver level is close to 
non-existant...

-- 
Bogdan Costescu

IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De

      parent reply	other threads:[~2002-04-23 18:16 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-04-22 14:49 nfs performance: read only/gigE/nolock/1Tb per day Lever, Charles
2002-04-22 15:32 ` Trond Myklebust
2002-04-22 18:52   ` Bogdan Costescu
2002-04-23 10:39     ` Trond Myklebust
2002-04-23 15:14       ` Bogdan Costescu
2002-04-23 16:36         ` Trond Myklebust
2002-04-23 18:16           ` Bogdan Costescu
2002-04-23 18:16           ` Bogdan Costescu [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='aa48ll$77b$2@main.gmane.org' \
    --to=bogdan.costescu@iwr.uni-heidelberg.de \
    --cc=netdev@oss.sgi.com \
    --cc=nfs@lists.sourceforge.net \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.