Linux NFS development
 help / color / mirror / Atom feed
From: Peter Staubach <staubach@redhat.com>
To: Stefan Wuerthner <trash.wuerthner@gmx.de>
Cc: nfs@lists.sourceforge.net
Subject: Re: Sporadic timeout problems during streaming to nfs server
Date: Wed, 14 Sep 2005 17:17:29 -0400	[thread overview]
Message-ID: <43289369.9080906@redhat.com> (raw)
In-Reply-To: <ef6372aa4d.stefan@wuerthner.dyndns.org>

Stefan Wuerthner wrote:

>In message <044B81DE141D7443BCE91E8F44B3C1E288E43F@exsvl02.hq.netapp.com> you wrote:
>
>  
>
>>>In message 
>>><044B81DE141D7443BCE91E8F44B3C1E288E43C@exsvl02.hq.netapp.com>
>>> you wrote:
>>>
>>>      
>>>
>>>>don't use the "soft" option -- use "hard" instead.  "soft" 
>>>>        
>>>>
>>>with "udp" is
>>>      
>>>
>>>>a sure recipe for data corruption and the very symptoms you describe
>>>>below. 
>>>>
>>>>        
>>>>
>>>I already tried "hard", but without success:
>>>
>>>The serial log tells me:
>>>
>>>[Fri Sep  9 11:50:20 2005]
>>>nfs: server 192.168.24.50 not responding, still trying
>>>[Fri Sep  9 12:58:53 2005]
>>>PANIC: not enough space in ringbuffer, available 42887, needed 93225
>>>
>>>
>>>E.g. the client cannot reach the server and therefore the 
>>>client ringbuffer
>>>overflows. This results in a total lockup of the client...
>>>      
>>>
>>a ring buffer overflow is a NIC driver problem.  the NFS timeout issues
>>suggest a network problem (either the link or the NICs or...).  i would
>>start looking closely at your client-side network (driver version,
>>hardware, cabling, switch, etc).
>>
>>in the long run you want to use NFS over TCP rather than UDP (and don't
>>use "soft").
>>
>>    
>>
>
>Client side is more or less fixed because it's not a computer but a
>consumer device running busybox. Ethernet controller is partially
>formed by the CPU (slow PPC)...
>
>The ring buffer is afaik not part of the NIC, but has been added
>some time ago to buffer peak bitrates in the TS stream. Hardware 
>should be o.k. (Cat5e+ cabling, Allied Telesyn switches).
>
>The difficult points are:
>
>1. Real-time application: video streaming (MPEG2 stream)
>2. Receiver NIC is limited to 10MBit half-duplex
>3. video streams can peak to 8-10MBit...
>
>So:
>
>1. NFS over TCP is too slow
>2. - "hard" is no option, because it stops writing the stream finally
>   - "soft" allows the server to restart the recording after several seconds
>     but there is a small interruption in the final recording
>
>The interesting questions are:
>
>Why does streaming work for e.g. 30min or 65min and then fail with
>'timeout'?
>
>How can I get more information on the server side what happened exactly at
>this point of time. I could not find any logs related to serverside NFS.
>

10Mb/s is really slow, for today's standards.  Almost anything ought to
be able to drive the network at full speed, even with TCP.

Can you try this without the ring buffer?

I would suggest using ethereal or tcpdump on the server to watch the
traffic and see if anything appears unusual when the situation occurs.

       ps


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2005-09-14 21:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-09-14 14:00 Sporadic timeout problems during streaming to nfs server Lever, Charles
2005-09-14 21:10 ` Stefan Wuerthner
2005-09-14 21:17   ` Peter Staubach [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-09-14  2:17 Lever, Charles
2005-09-14  9:58 ` Stefan Wuerthner
     [not found] <twig.1074096221.40393@mail.uni-tuebingen.de>
     [not found] ` <20040114161124.GD31464@gw.netwinder.org>
     [not found]   ` <756bb8704c.stefan@wuerthner.dyndns.org>
     [not found]     ` <20040114171148.GA761@gw.netwinder.org>
2005-09-13 23:41       ` Stefan Wuerthner
2005-09-14  0:01       ` Stefan Wuerthner

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=43289369.9080906@redhat.com \
    --to=staubach@redhat.com \
    --cc=nfs@lists.sourceforge.net \
    --cc=trash.wuerthner@gmx.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox