When viewing HDTV over and nfs mount, I get high IO wait times on the frontend for some reason. The backend, which has the recordings store local, has one of two CPUs averaging 50% and at times pegged due to EIT usually. If I lower the NFS read buffer to 1 meg I get much better performance than with say an 8meg read buffer. Why this is, I don't know.
<br><br>I tried switching to samba for my frontend recordings mount and that helps a great deal. I don't get get high IO wait times anymore but HD playback still isn't perfect. If anything on the frontend or backend takes extra CPU, like EIT on the backend or mysql, I get stuttering.
<br><br>I'm starting to think my problem with HD viewing is with smbd or nfsd context swithing on the backend causing the stutter, whereas using myth:// elminiates that since the process causing the context switching is mythbackend itself.
<br><br>- Mark.<br><br><div><span class="gmail_quote">On 11/21/06, <b class="gmail_sendername">Daniel Kristjansson</b> <<a href="mailto:danielk@cuymedia.net">danielk@cuymedia.net</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 2006-11-21 at 15:38 -0800, Bruce Markey wrote:<br>> Chris Pinkham wrote:<br><br>> "FWIW: My in experience streaming works far better...<br>> ...several posts in the dev & users lists that suggest to
<br>> use streaming rather than nfs mounts."<br>><br>> "I am one that finds streaming via protocol better than<br>> nfs mount."<br>><br>> They are both saying that serving the files from the backend
<br>> seems to work better than NFS. This is what I'd expect as the<br>> backend method can be application aware of the read ahead and<br>> block size needs. If we can't out-perform NFS then we're doing<br>> something wrong because nothing in NFS was designed with the
<br>> needs of mythfrontend specifically in mind =).<br><br>I theory Myth streaming should perform as almost as well or<br>in some cases better than NFS when the file storage is local<br>to the backend, but in practice I've found NFS to be much better
<br>at the task. Perhaps it's because NFS is in the kernel and<br>so doesn't add as much latency as Myth streaming. Or it could<br>be because it doesn't use TCP by default and so can transmit<br>the data with much less overhead and the Nagling doesn't
<br>stop us cold when there is a dropped packet. Maybe there is<br>a bug or there are some really large timeouts in the Myth<br>streaming implementation. Whatever the cause, most of the times<br>I've had performance problems with MythTV it was because Myth
<br>streaming was getting in the way. I haven't felt the motivation<br>to make Myth streaming actually work, since the work around<br>is so simple, don't use it.<br><br>> The block size used to be adjusted based on an estimated bitrate
<br>> but that didn't turn out to work so well. What I'm thinking<br>> right now is that maybe the block size should be adjustable<br>> based on the demand for the read ahead buffer. Start small then<br>> grow the block size until the read ahead buffer stays above
<br>> some level without having to request too often. This could make<br>> it use small blocks right after seeking then build in size after<br>> a few iteration during continuous playback.<br><br>Wouldn't this cause HDTV streams to always stutter at startup?
<br>Or are you considering something that preserves state across<br>streaming sessions?<br><br>-- Daniel<br><br>_______________________________________________<br>mythtv-dev mailing list<br><a href="mailto:mythtv-dev@mythtv.org">
mythtv-dev@mythtv.org</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev</a><br></blockquote></div><br>