Hi Miguel, :) Having had a night of sleep: Normally in GNU Radio, you've got input- and output buffers, and if there's no space in your output buffer, you can't process input, so you stall until there's space in your output buffer. That's how the throttle block works: by not taking samples from its input buffer faster than specified by the "throttle rate", it not only slows down the blocks downstream in the flow graph, but it also keeps the input buffer full. Its input buffer is the output buffer of the block upstream, and so, that block can't run arbitrarily fast (that mechanism is called /backpressure/, by the way).
But: The packet_encoder, old as it is, internally uses an old-style message sink. Which means it takes samples out of its input buffer, processes them somehow, and shoves them into a FIFO. That FIFO does not have a way of saying "I'm full", but just grows and grows and grows... So, the packet_encoder breaks up the backpressure chain, and that's a bad thing, architecturally, as you can see, because the block upstream (i.e. the vector source) can now run as fast as it can – that is, as fast as the packet_encoder consumes the items it produces, and as fast as the file sink consumes them, whatever is slower. Without the packet_encoder, backpressure from the throttle block works, so that's why your file is smaller. Hope that explains the observation, at least a bit :) Best regards, Marcus On 23.03.2016 00:11, Miguel Santos wrote: > Sadly, we all need some sleep... > Well, thanks, A LOT! I'll try that. > Have a good night, you deserve a statue or a Nobel or something like that! > > Best regards, > Miguel > > On 22-03-2016 22:41, Marcus Müller wrote: >> Indeed, there seems to be a problem here; sadly, I'll really need >> some sleep tonight ;) >> >> To answer your question, yes, Packet Encoder is really old and IMHO >> should be deprecated in favor of the architecture you'd find in the >> ofdm_tx.grc example (should be installed somewhere like >> /usr/(local/)share/gnuradio/examples/gnuradio/digital/ofdm ) >> >> However, if you just need a preamble: >> use a second vector source for the preamble (or something else), and >> use the "patterned interleaver", e.g. with something like pattern = >> [1]*header_len + [0]*payload_len >> >> Best regards, >> Marcus >> >> On 22.03.2016 23:17, Miguel Santos wrote: >>> As an attachment I send the .grc on which I'm doing tests. >>> So: >>> - with head and/or throttle between source and packet encoder -> fine >>> - bypassing Head and Throttle -> huge file >>> - bypassing Head, Throttle and Encoder -> fine >>> I answered your questions below. >>> >>> Another question: I'm using Packet Encoder only to add a preamble to >>> perform frame sync. Is it the only way? >>> >>> On 22-03-2016 21:42, Marcus Müller wrote: >>>> Hi Miguel, >>>> >>>> On 22.03.2016 21:54, Miguel Santos wrote: >>>>> On 22-03-2016 20:32, Marcus Müller wrote: >>>>>> Hi Miguel, >>>>>> >>>>>> On 22.03.2016 17:14, Miguel Santos wrote: >>>>>>> Yes, it's set to repeat. >>>>>> oh! >>>>>>> My real flow graph ends with a file sink, but >>>>>>> here, as an example to test which block was the problem, I used a number >>>>>>> sink just to be able to run it and test it. >>>>>> But then, how does your flow graph decide it's done? >>>>> It doesn't. For now, I'm dealing with transmitting and receiving >>>>> problems, so I don't really care about the message. For testing purposes >>>>> I'm transmitting an infinite amount of 0s and 1s (the same repeated >>>>> sequence defined in Vector Source block) and I manually stop the flow >>>>> graph after a certain amount of time. >>>> Ah, so there's no "right" amount of samples. It all depends on when you >>>> decide to manually stop, and on the speed at which samples are processed. >>>> I'd recommend adding a "head" block somewhere. That will signal "hey, >>>> we're done" as soon as the specified amount of samples have passed. >>> Exactly! I tested with the Head block and it behaves as it should. I >>> think the problem occurs only when vector source is connected directly >>> to packet encoder. >>> By the way, why does the file becomes empty if "Num items"<4096? I'm new >>> to this world and there's a LOT of things I don't understand. >>> >>>>> The differences between the two >>>>> cases I presented were noted running the flow graph for, for instance, 5 >>>>> seconds (counted by me). It's not very accurate, I know, but we're >>>>> talking of a big difference (like a few KB or MB to hundreds of MB or >>>>> even a few GB), so it's not important. >>>> So, sorry for asking again, but I really want to be sure: *with* the >>>> packet_encoder, the file is much much larger than without, right? >>>> >>>> Best regards, >>>> Marcus >>> Yeah, that's it: WITH >>> >>>>> Thanks for your time and sorry for not being explicit enough. >>>> Don't worry! If this is a bug, it's really worth figuring out. >>>> Also, we're a helpful bunch of people. >>>> >>>> Best regards, >>>> Marcus >>>>>> Best regards, >>>>>> Marcus >>>>>>> I've made more tests and if I switch Throttle with Packet Encoder, it's >>>>>>> all good. The same happens if I connect File Sink to Throttle (when they >>>>>>> are switched). >>>>>>> So maybe the problem is with the position of throttle? After watching >>>>>>> the tutorials I thought that its position was irrelevant... >>>>>>> >>>>>>> On 22-03-2016 08:02, Marcus Müller wrote: >>>>>>>> Hi Miguel, >>>>>>>> >>>>>>>> I assume your Vector Source is not set to "Repeat"? Or how does your >>>>>>>> Flow graph Terminate? >>>>>>>> Generally, no block can modify its input buffer; hence, what File Sink >>>>>>>> "sees" as an input number sequence must be identical (unless we really >>>>>>>> have a bad memory access bug at hand, which I don't think). >>>>>>>> >>>>>>>> Bet regards, >>>>>>>> Marcus >>>>>>>> >>>>>>>> On 22.03.2016 00:39, Miguel Santos wrote: >>>>>>>>> Hi all! >>>>>>>>> While I was using the block Packet Encoder I realized that my input >>>>>>>>> file >>>>>>>>> (saved before that block) becomes a lot bigger. >>>>>>>>> So I made a simple example to show that problem. >>>>>>>>> >>>>>>>>> Vector Source ---> Packet Encoder ---> Throttle ---> Number Sink >>>>>>>>> ---> File Sink >>>>>>>>> >>>>>>>>> Just to make it clear, File Sink is connected to Vector Source, BEFORE >>>>>>>>> Packet Encoder. >>>>>>>>> Running the flow graph the same amount of time, I get an input file of >>>>>>>>> 700~800 MB for this flow graph and ~3MB for the same flow graph with >>>>>>>>> Packet Encoder bypassed. >>>>>>>>> Is this a bug? Could it be a larger processing time of that block >>>>>>>>> that's >>>>>>>>> delaying the data flow? Am I missing something? How can I solve that? >>>>>>>>> Any help would be nice. >>>>>>>>> >>>>>>>>> Thanks for your time, >>>>>>>>> Miguel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Discuss-gnuradio mailing list >>>>>>>>> [email protected] >>>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>>> _______________________________________________ >>>>>>>> Discuss-gnuradio mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>>> _______________________________________________ >>>>>>> Discuss-gnuradio mailing list >>>>>>> [email protected] >>>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>>> _______________________________________________ >>>>>> Discuss-gnuradio mailing list >>>>>> [email protected] >>>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>>> _______________________________________________ >>>>> Discuss-gnuradio mailing list >>>>> [email protected] >>>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>>> _______________________________________________ >>>> Discuss-gnuradio mailing list >>>> [email protected] >>>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
