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