[pvrusb2] hauppage hvr-1900 on raspberry pi

[Emmanuel Touzery]

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
>>>
>>
>>
>