[dvblast-devel] DVR_BUFFER_SIZE issue

[Richard Hemzal]

I have tested tu run with -i 1, (using it normaly), no influence on this issue. In oposite I do not remember as far I tested it
without -i, guess will need some further test. Anyway it does not make much senses to estimated buffer as fixed when at it looks can
be changeable. Much better piece of deetction on time how long buffer is.
 
DVR_BUFFER_SIZE  vs. latency - well there will be some relation with latency, but as my experience from previous experiments more
important is chunk size in drivers, exactly as described in "extra" dir. In fact I play a lot how to traffic control data which are
going from shaper and can say that DVR_BUFFER_SIZE have some relation but not something like that will fix delay packet to packet.
In fact as my investigation it will not change number of packet as as they are sent in one burst. On other hand I did not yet traced
in code if this realy or just my opinion based on wireshark dump.  I guess it should have influence on minimal retention time you
can set. 

Does the latency plays for you somewhere? I did also some (lot) tests on various dvb cards and found that in real network more
important for me retention time than latency. 

Have to note that than plays with chunk size , latency and retention is to reasonably setup traffic control of output.... much more
universal to limit bursting.

 

-----Original Message-----
From: dvblast-devel-bounces at videolan.org [mailto:dvblast-devel-bounces at videolan.org] On Behalf Of Christophe Massiot
Sent: Thursday, January 26, 2012 10:41 PM
To: Mailing list for DVBlast developers
Subject: Re: [dvblast-devel] DVR_BUFFER_SIZE issue

Le 25 janv. 2012 à 09:42, Richard Hemzal a écrit :

> I have met issue that getting message from dvblast
> 
> error: couldn't read from DVR device (Value too large for defined data 
> type)
> 
> in some cases.
> It looks that this message I am getting when szstem has some 
> filesystem activity and it is probbaly related also with driver of 
> card, in my case TBS6280. I also cannot exclude that this can affect usage of traffic control rules. In fact problem happens not
each time, but in same system within few minutes will apear.
> 
> Solution, or workaround,  is to expand DVR_BUFFER_SIZE in dvb.c

Another possible solution would be to raise DVBlast's priority with nice or schedtool.

> originaly
> #define DVR_BUFFER_SIZE 40*188*1024 /* bytes */ must change into 
> #define DVR_BUFFER_SIZE 200*188*1024 /* bytes */
> 
> I can say that also value 100*188*1024 not enough. 
> 
> Should we do this value controllable from command line? 

Do you know if this value as an influence on the latency ? Actually I thought until now that is was of no use at all (wasn't
connected to anything behind), but maybe it depends on the driver.
_______________________________________________
dvblast-devel mailing list
dvblast-devel at videolan.org
http://mailman.videolan.org/listinfo/dvblast-devel