[pvrusb2] hauppage hvr-1900 on raspberry pi

[Emmanuel Touzery]

Otherwise if someone is interested, for now I still can't make DVB-T
recording work smoothly. Ethernet was a big help but not quite enough.

I've made quite some tuning, using mplayer instead of tzap+cat, and then
strongly prioritize that mplayer process: chrt 99 with FIFO scheduling,
nice -20, ionice -c1 (though i guess that last one doesn't make a real
difference), and even some scheduler tuning to increase latency and
prioritize real time processes:

echo -1 > /proc/sys/kernel/sched_rt_runtime_us
echo 40000 > /proc/sys/kernel/sched_rt_period_us
echo 600000 >  /proc/sys/kernel/sched_latency_ns
echo 400000 >  /proc/sys/kernel/sched_min_granularity_ns

I've also tried NFS, udp and tcp, with max block size (1Mb!), 32kb and
64kb, but i still get cuts.

I actually now get 15 minute blocks without cuts. But even only every 15
minutes, a cut is a cut...
i also tried overclocking the pi without big differences (i actually didn't
try to overclock it on the latest settings but i guess it also wouldn't
help).

i'll see, i'm still not quitting but getting closer :-/

emmanuel

On Thu, Jun 7, 2012 at 10:08 PM, Felix Lighter <felix.lighter at gmail.com>wrote:

> I'm glad that Ethernet helped the situation.
> Beware USB - it's also notorious for aggressively interrupting the CPU.
> 480Mbps USB2 comes at a high price, CPU-wise. And as you point out,
> it's already busy capturing video.
>
> I would definitely suggest looking into NFS, since you should be able
> to lighten the CPU load even further by increasing the write buffer
> size (in the mount options). Take a look and see whether Samba also
> offers any options for tuning network usage / bandwidth.
>
> Cheers,
> FL
>
> On 7 June 2012 15:43, Emmanuel Touzery <etouzery at gmail.com> wrote:
> > Hello,
> >
> >  Thanks for a lot for the tip. I tried quickly with a SMB share which I
> > already had setup and... yes it seems better! Although I really can't
> > believe it, it does seem to help. I'm glad you give me a plausible
> > explanation with DMA though, because that's the last thing I was
> expecting.
> > Especially since my network is not wired and though it's plugged using
> > ethernet on the pi, it reaches my computer through wifi.
> >
> >  I'll try more. I didn't try much with USB keys too because I measured a
> > slightly lower throughput than with the SD card and I read that on the
> pi,
> > the throughput for USB+ethernet is shared. I figured, since USB is
> already
> > busy receiving the data from the video capture device, better save on the
> > SD... but apparently not.
> >
> >  But really I can't conclude much until I test more. The first tests
> seems
> > to say network>usb>sd. but even on network I've seen a skip. Though it's
> on
> > a non-preempt kernel and without any sort of buffering (eg flywheel or
> > fifo), nor nice or chrt.
> >
> >  Anyway, it seems there's not much hope of configuring something
> > differently on the driver or the kernel, so for now I'll focus on where
> to
> > save: SD, network, usb, with or without FIFO and so on. And maybe also
> NFS
> > vs SMB, if SMB doesn't always cut it. Definitely network appears the most
> > promessing option for now! So thanks again for the tip!
> >
> > emmanuel
> >
> > On Wed, Jun 6, 2012 at 10:27 PM, Felix Lighter <felix.lighter at gmail.com
> >wrote:
> >
> >> Saving to a network share (e.g. NFS with intermediate block size)
> >> might perform better.
> >> The Ethernet port is likely to be much better served by the CPU's DMA
> >> facilities than its SD interface is.
> >>
> >> Cheers, FL
> >>
> > _______________________________________________
> > pvrusb2 mailing list
> > pvrusb2 at isely.net
> > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
>