On Thursday 18 January 2007 23:28, [EMAIL PROTECTED] wrote:
> [ivtv 0.4.0, myth 0.18.1, 5xPVR-250's and ivtv 0.4.1, myth 0.18.1,
1xPVR-350.]
>
> I'm trying to increase my ivtv buffering [1]. There's a mantra for
> doing so at [2] which claims
> options ivtv yuv_buffers=32 mpg_buffers=16 vbi_buffers=16
pcm_buffers=16 dec_osd_buffers=2
> is the right idea, though I've tried this in the past and discovered
> that this adds about 100 meg per card to the system's memory
> requirements, which isn't so great on a 1gig system that's also
> running mythbackend and mysql and has lots of tuners. Searching for
> yuv_buffers on the web just finds lots of other documents that include
> that entire line like a cargo cult, with no actual discussion.
>
> But is that yuv_buffers setting even -necessary- if all I'm doing is
> dumping mpeg data directly off the cards? My understanding was that
> yuv is the non-mpeg mode that pretty much nobody uses; why would
> increasing that buffering help me? Should I just use the line above
> but exclude the "yuv_buffers=32"? Can I set it to 0 or some small
> number? [Search results mention problems w/old kernels and
yuv_buffers=0
> but I don't know if that's still the case in 2.6.12 (mine) and later.]
You can try to set it to 0 or 1, but I'm not sure it will work. I'm
working on a much improved ivtv driver where this is certainly honored,
but it is for kernels >= 2.6.18 only. For pure MPEG encoding you only
need the MPG buffers and the VBI buffers (which can be safely set to 1
or 2, 16 is way overkill).
>
> I'm hoping that by -not- increasing that particular bit of buffering,
> I can get more memory to be used by, e.g., the filesystem cache to
> improve mysql performance. (I may also only use mpg_buffers=8 and see
> if that's enough, or I might even go to mpg_buffers=32 if [2] is wrong
> that 16 is the maximum [is there a hardcoded max somewhere?].) Note
> that I -am- capturing VBI/CC data as well, so I assume I should still
> increase both that and the PCM buffering as I'm increasing MPG
buffering.
>
> Also: If I'm using a PVR-350 (for both capture -and playback-),
should
> I care about a yuv_buffer setting on the machine that owns -that-
card?
No.
> (I'm also guessing not, but I'm asking for completeness.) And is
> the dec_osd_buffers setting ignored for the 250's? [If so, I'll
> leave it on the machine w/only 250's just so all machines have the
> same buffering configuration, but if it's chewing up memory that can't
> be used 'cause the machine w/the 250's has no 350, I'll remove it.]
It should be ignored by non-PVR350 cards.
>
> [Note also that I asked on the ivtv/mythtv lists around Sep 1 '06 why
> increasing the buffering yielded -such- a large increase per-card, but
> got no response; simple math seems to indicate that I was losing lots
> more memory (~2x?) to the buffering than the lines above and the
syslog
> output indicated should be allocated; if someone would like to address
> that, i can dig up the original analysis.]
>From what I remember the old driver (i.e. anything but the trunk)
contained some dubious code for buffer allocations. This has been much
improved in the trunk code of ivtv.
Regards,
Hans
>
> [1] The MythTV scheduler hits MySQL very hard every time it runs, and
> even after increasing a number of MySQL buffer-size variables (which
> helped substantially, but not completely) and playing with I/O
> scheduling priorities (which either hurt or did nothing), I'm still
> seeing frequent glitches in recordings if one ends (forcing a
> scheduler run) while at least one is still capturing---I get "I/O
> bound" errors in the myth log and "ENC Stream 0 OVERFLOW" errors in
> syslog, even after ensuring that MySQL's DB files weren't on the same
> spindle nor even IDE bus as the disk writing the capture data and
> after making sure that the DB was always optimized every day. [Yes,
> the disks are UDMA 133, yes DMA is enabled, yadda yadda.] I -really-
> don't want to have to add a -third- CPU to the mix -just- to run MySQL
> on it, just to avoid periodic I/O stalls when that scheduler query
> runs [3], hence my hope that I can increase buffering "enough" without
> starving the rest of the system.
>
> [2] http://www.mythtv.org/wiki/index.php/Hauppauge_PVR-350
>
> [3] If that would even help (I haven't tested it yet)---after all,
Myth
> is constantly writing to the recordedmarkup table -while capturing-,
> which means that scheduler query might stall the recordedmarkup
> writes, which might then stall Myth emptying ivtv's capture buffers
> and hence cause the overruns I'm complaining about. This seems like
> it could use some improvement somehow and ISTR there -might- have been
> improvements in later versions of Myth but can't remember now if they
> got backed out 'cause they caused some other problem.
>
> _______________________________________________
> ivtv-users mailing list
> [email protected]
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
>
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
