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 <[email protected]>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 <[email protected]> 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 <[email protected] > >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 > > [email protected] > > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > _______________________________________________ > pvrusb2 mailing list > [email protected] > http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2 > _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
