Marcus, Certainly a type. Since Maricus did not mention any hardware sink I was just reminding him to add a throttle block if it is not there :)
-- Bob On Thu, Jul 30, 2015 at 11:13 AM, Marcus Müller <marcus.muel...@ettus.com> wrote: > Hi Bob, > > Sorry I have to contradict here: when working with hardware, you should > generally *never* use a throttle block. Maybe that was just a typo in your > mail? > > The reason is that the throttle blocks sole job is to call sleep functions > for long enough to press the average rate of samples going through the > throttle block is the set rate. Now, in a world where latency doesn't count > and all clocks are identical, that's not a problem. However, in practice, > this means that throttle might block for a relatively long time, when the > numbers of samples it got in one work iteration are large. In the meantime, > the downstream hardware might have run dry on samples, even if the throttle > rate is higher than the sink's sampling rate! > > Also, with rates produced by your computer's clock and the oscillator of a > hardware sink, one has to be a little faster than the other, which leads to > under or overflow problems sooner or later. > > However, in the pure simulation case, I agree, you should add a throttle > and see whether it helps. > > Best regards, > Marcus > > Am 30. Juli 2015 07:10:13 MESZ, schrieb bob wole <bnw...@gmail.com>: > >> Maricus, >> >> Does your flowgraph involves aany hardware sink e.g USRP, audio ? If try >> adding a throttle if you are not already doing it. >> >> -- >> Bob >> >> >> >>> Hi Marius, >>> >>> good question! >>> Now, typically, you'd use tools like valgrind to figure that out. I >>> haven't noticed a memory leak in GNU Radio itself, but it's absolutely >>> possible that something like PMTs do not get freed etc, and we didn't >>> notice how this could happen. >>> If you need additional things to look for: >>> * do you have something like a vector that stores e.g. messages that >>> come in? >>> * what's the failure mode of your application? Is it killed by the >>> Out-of-Memory killer, or do you get into a situation where it crashes >>> because of e.g. stack overflow? >>> >>> Best regards, >>> Marcus >>> >>> On 29.07.2015 15:57, Marius Cachelin wrote: >>> > Hi all, >>> > >>> > I am writing because I have some misunderstood concerning how memory >>> > is used in GNURadio. >>> > >>> > I developed a transmitter which can be split into 5 parts : >>> > - MAC Encoder : read PDU data from TUNTAP >>> > - HEADER Prefixer : add header before each PDU Data >>> > - PREAMBLE prefixer : add preamble before each PDU Data >>> > - MODULATOR : Performing BPSK/QPSK >>> > - FIR Interp : Pulse shape >>> > >>> > My question is : when I run my transmitter, I can see in HTOP that the >>> > memory (%MEM) used by my transmitter increase. The increasing is >>> > relatively slow, but the is an issue because I can't keep using my >>> > transmitter after a while. >>> > >>> > I have checked all my blocks. All memory allocations are freed, and >>> > all my objetcs (new...) are deleted. >>> > >>> > So, how the memory can increase if I do not allocate extra memory and >>> > free all memory? >>> > >>> > Thanks you in advance. >>> > >>> > -- >>> > *CACHELIN Marius* >>> > /Ing?nieur Syst?mes, R?seaux et T?l?communications/ >>> > marius.cache...@gmail.com <mailto:marius.cache...@gmail.com >>> >> ------------------------------ >> >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
