All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom McNeal <trmcneal@attbi.com>
To: Raphael Clifford <cliffor@rockefeller.edu>,
	NFS maillist <nfs@lists.sourceforge.net>
Subject: Re: Re: jumbo frames and performance
Date: Mon, 17 Jun 2002 14:13:42 -0700	[thread overview]
Message-ID: <3D0E5106.6392471@attbi.com> (raw)
In-Reply-To: 3D0E3D05.3010108@rockefeller.edu

> as far as i know, jumbo frames are supported only on gigabit.

Yup, you're right.  Duh.

> >>> Also, since you're using 0.3.3 utils, I assume you are using sync
> >>> exports; otherwise there are costs at the server which are hidden
> >>> from the benchmark data.
> >
> > if you use "sync" the server behaves like all other NFS servers
> > and pushes data to disk when the client asks it to.  if you
> > use "async" the server ignores the client, and pushes data to
> > disk when it feels like it.
> >
> > so, if you benchmark with "async" you get artificially good
> > write results because the server responds "OK" to write requests
> > before it has really written them to disk.  "async" is not
> > an option you would ever use in a production environment,
> > naturally.
> >
> 
> Right, performance from the client perspective is explained in the faq
> (actually its not really presented from any particular perspective, but
> its closest to the client perspective) but I thought the point being
> made above was that the server suffers from a large overhead too.  So
> there are two perspectives. The first is that async is faster for the
> client and corrupts your data and the second is whether or not it
> reduces the load for the server.  This is not explained explicitly in
> the HOWTO.


What I meant by "costs at the server which are hidden from the 
benchmark data" was the cost of getting the data to the disk,
and the fact that this is hidden from the measurements you
are taking at the client, when the server uses the 0.3.3 async
default.  The actual load on the server may be somewhat different
in sync and async, due to the fact that the write to the disk
might be bundled with other writes when doing it asynchronously,
but I'm not really sure how significant that would be.

Tom


--
------------------------------------------------------------
Tom McNeal       trmcneal@attbi.com     (650)906-0761 (cell) 
------------------------------------------------------------

----------------------------------------------------------------------------------------------------
                                     Sponsor's Message
----------------------------------------------------------------------------------------------------
                      Bringing you mounds of caffeinated joy
                         >>>     http://thinkgeek.com/sf    <<<

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

      reply	other threads:[~2002-06-17 21:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E17K1pY-00014i-00@usw-sf-list2.sourceforge.net>
2002-06-17 19:12 ` jumbo frames and performance Raphael Clifford
2002-06-17 19:48   ` Raphael Clifford
2002-06-17 21:13     ` Tom McNeal [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=3D0E5106.6392471@attbi.com \
    --to=trmcneal@attbi.com \
    --cc=cliffor@rockefeller.edu \
    --cc=nfs@lists.sourceforge.net \
    /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.