[pvrusb2] hauppage hvr-1900 on raspberry pi

Tue Jun 26 17:29:49 CDT 2012

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 <etouzery at gmail.com>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 <etouzery at gmail.com>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 <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
> >>>
> >>
> >>
> >
> _______________________________________________
> pvrusb2 mailing list
> pvrusb2 at isely.net
> 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