Emmanuel: This is good stuff to know and thanks for posting it! And holy cow, how many people go to that level of detail to tune the performance of a Linux system? (Though of course I realize your case was unusual.)
-Mike Isely On Mon, 25 Jun 2012, Emmanuel Touzery wrote: > OK my final mail on the topic, since it's a bit off topic on this list. > > I got it to work reliably without cuts, the secret was in extra settings, > especially for IPv4 tuning. > > my whole series of settings is here: > > echo 50000 > /proc/sys/kernel/sched_rt_period_us > echo 20000 > /proc/sys/net/core/netdev_max_backlog > echo 2500000 > /proc/sys/net/core/optmem_max > echo 16777216 > /proc/sys/net/core/wmem_default > echo 16777216 > /proc/sys/net/core/wmem_max > echo 1 > /proc/sys/net/ipv4/tcp_low_latency > echo 750000 > /proc/sys/kernel/sched_min_granularity_ns > echo 600000 > /proc/sys/kernel/sched_latency_ns > echo -1 > /proc/sys/kernel/sched_rt_runtime_us > > I'm also shutting down cron, xinetd, and ntp before recording. crazy but i > HAD cuts because of ntp triggering once per hour. > > i also increased the IPv4 incoming buffers on my PC on the other side: > echo 16777216 > /proc/sys/net/core/rmem_default > echo 16777216 > /proc/sys/net/core/rmem_max > > mplayer for recording DVB-T, cat with flywheel for AV IN, and then: > sudo chrt -f -p 99 <pid> > sudo renice -n -20 <pid> > sudo ionice -c1 -p<pid> > > and note that this is over wifi. also works fine when i stream a video over > DLNA at the same time. > > anyway, all is well that ends well, in the end it works fine. > > now if only there could be support for the IR blaster on the HVR-1900 it > would be a perfect setup :-) > > emmanuel > > On Sun, Jun 17, 2012 at 11:24 AM, Emmanuel Touzery <[email protected]>wrote: > > > well i researched a bit more, now i'll try dvbstream and vlc streaming. > > > > > > On Sun, Jun 17, 2012 at 10:48 AM, Emmanuel Touzery > > <[email protected]>wrote: > > > >> 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 > -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 _______________________________________________ pvrusb2 mailing list [email protected] http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
