All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Wuerthner <trash.wuerthner@gmx.de>
To: nfs@lists.sourceforge.net
Subject: RE: Sporadic timeout problems during streaming to nfs server
Date: Wed, 14 Sep 2005 23:10:51 +0200	[thread overview]
Message-ID: <ef6372aa4d.stefan@wuerthner.dyndns.org> (raw)
In-Reply-To: <044B81DE141D7443BCE91E8F44B3C1E288E43F@exsvl02.hq.netapp.com>

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.



> > > > -----Original Message-----
> > > > From: Stefan Wuerthner [mailto:trash.wuerthner@gmx.de] 
> > > > Sent: Tuesday, September 13, 2005 8:02 PM
> > > > To: nfs@lists.sourceforge.net
> > > > Subject: [NFS] Sporadic timeout problems during streaming to 
> > > > nfs server
> > > > 
> > > > - I have the following setup:
> > > > 
> > > > DBox (DVB-C receiver, 10BaseT) connected to
> > > > 100MBit-Switch connected over 10m TP to
> > > > 100MBit-Switch connected over 5m TP to
> > > > Netwinder (Linux server, 100BaseT)
> > > > 
> > > > - Export options on the Netwinder (Kernel 2.4.19-rmk7-nw1):
> > > > 
> > > > dbox2(rw,insecure,all_squash)
> > > > 
> > > > - Mount options on the DBox (Kernel 2.4.31-dbox2) to stream 
> > > > the DVB-TS:
> > > > 
> > > > rw,soft,udp,nolock,rsize=8192,wsize=8192
> > > > 
> > > > - This results in:
> > > > 
> > > > 192.168.24.50:/home/wuerthne on /mnt/filme type nfs 
> > (rw,v3,rsize=8192,
> > > > wsize=8192,soft,udp,nolock,addr=192.168.24.50)
> > > > 
> > > > 
> > > > Unfortunately, I sometimes get a timeout error in the serial 
> > > > logfile of my
> > > > DBox:
> > > > 
> > > > [Tue Sep 13 19:15:49 2005]nfs: server 192.168.24.50 not 
> > > > responding, timed out
> > > > [Tue Sep 13 19:15:49 2005][stream2file]: error in write: 
> > > > Input/output error
> > > > [Tue Sep 13 19:15:51 2005][stream2file] pthreads exit 
> > code: 4294967293
> > > > [Tue Sep 13 19:15:56 2005][neutrino.cpp] executing 
> > > > /var/tuxbox/config/recording.start.
> > > > [Tue Sep 13 19:15:57 2005]Record channel_id: 44d00016dcd epg: 
> > > > 44d00016dcda60c, apids  mode 1
> > > > [Tue Sep 13 19:46:43 2005]nfs: server 192.168.24.50 not 
> > > > responding, timed out
> > > > [Tue Sep 13 19:46:43 2005][stream2file]: error in write: 
> > > > Input/output error
> > > > [Tue Sep 13 19:46:44 2005][stream2file] pthreads exit 
> > code: 4294967293
> > > > [Tue Sep 13 19:46:49 2005][neutrino.cpp] executing 
> > > > /var/tuxbox/config/recording.start.
> > > > 
> > > > E.g. the client recognizes a timeout and restarts the 
> > recording. This
> > > > results in two ore more fragments which is not desirable.
> > > > 
> > > > For some time now, I played with different NFS options, 
> > > > changed switches and
> > > > so on but to no avail. Sometimes I can stream 5GB without 
> > problems,
> > > > sometimes the timeout occurs after a short period of time.
> > > > 
> > > > 
> > > > Any ideas what I can change or how I can diagnose this 
> > > > problem further to
> > > > avoid the timeouts?
> > > > 
> > > > 
> > > > Stefan
> > > > 
> > 


-- 
-----------------------------------------------------------------------------
Stefan Wuerthner                             web  http://wuerthner.dyndns.org
-----------------------------------------------------------------------------


-------------------------------------------------------
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:11 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 [this message]
2005-09-14 21:17   ` Peter Staubach
  -- 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=ef6372aa4d.stefan@wuerthner.dyndns.org \
    --to=trash.wuerthner@gmx.de \
    --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.