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
next prev parent 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