jumbo frames and performance

jumbo frames and performance

[Raphael Clifford]

Would you mind explaining the two performance points below a bit further 
and maybe putting them in the FAQ?  They look very interesting. 
 Regarding the "sync" option, why does not having it incur extra costs 
at the server?
Cheers,
Raphael


>It also looks like you are not using jumbo frames, which 
>Trond has mentioned as a big performance boost for tcp in 
>100 baseT full duplex environments.
>
>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.
>
>Tom
>
>  
>




_______________________________________________________________

Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

RE: jumbo frames and performance

[Lever, Charles]

> Would you mind explaining the two performance points below a 
> bit further 
> and maybe putting them in the FAQ?  They look very interesting. 
> Regarding the "sync" option, why does not having it incur 
> extra costs at the server?
> 
> >It also looks like you are not using jumbo frames, which 
> >Trond has mentioned as a big performance boost for tcp in 
> >100 baseT full duplex environments.

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

> >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.

this is explained somewhere in the performance chapter, near
the end.

_______________________________________________________________

Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: jumbo frames and performance

[Raphael Clifford]

>
>
>>   
>>
>>> It also looks like you are not using jumbo frames, which Trond has 
>>> mentioned as a big performance boost for tcp in 100 baseT full 
>>> duplex environments.
>>>     
>>
>
> as far as i know, jumbo frames are supported only on gigabit.
>

That's what I thought too.

>
>  
>
>>> 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.
>
> this is explained somewhere in the performance chapter, near
> the end.
>  
>

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.

Cheers,
Raphael



_______________________________________________________________

Sponsored by:
ThinkGeek at http://www.ThinkGeek.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Re: jumbo frames and performance

[Tom McNeal]

> 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