On Thu, Jul 31, 2014 at 12:21 PM, David Halls <david.ha...@toshiba-trel.com> wrote:
> Dear All, > > I have a Python block that produces packets of size 1536 bytes. Due to > various reasons, the latter parts of my flow graph are very slow (this is > desired and cannot be changed). After producing 510 packets, I get the > following error. > > "handler caught exception: operands could not be broadcast together with > shapes (1527) (1536) > Traceback (most recent call last): > File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py", line > 55, in eval > try: self._callback() > File "/usr/local/lib/python2.7/dist-packages/gnuradio/gr/gateway.py", line > 160, in __gr_block_handle > ) for i in self.__out_indexes], > File "/usr/local/lib/python2.7/dist-packages/trl/blsd_enc_b.py", line 198, > in work > out_cA[0:len(cAm)] = cAm > ValueError: operands could not be broadcast together with shapes (1527) > (1536) > thread[thread-per-block[1]: <block blsd_enc_b (2)>]: caught unrecognized > exception" > > Debugging more carefully, I can see that: > > len(cAm) = 1536 , len(out_cA) = 32768 > Just a quick response without really studying the problem or your code. The dynamic scheduler in GR is getting in your way, and the throttle block is definitely not the right way to help you. You need to either tell the scheduler what you need it to send your block or handle it internally. There are three ways to solve these issues: 1. Use set_output_multiple in the constructor, which will only allow the scheduler to send you chunks of data of some multiple of the number you pass that. I've seen this slow down the scheduler in other situations, but it sounds like you're going slow, anyways, so this shouldn't cause a problem. 2. Make your input signature your packet_length so each item will be a vector of that length. This would not be my preferred way, but we've played that game before. 3. Handle it internally. Buffer up the input until you have enough to produce what you need. You'd need to inherit from gr.basic_block here and do more management of the data and buffers yourself. Tom > for the first 490 packets, and then the length of 'out_cA' begins to reduce > > packet_num = 490 > len(cAm) = 1536 , len(out_cA) = 32247 > packet_num = 491 > len(cAm) = 1536 , len(out_cA) = 30711 > packet_num = 492 > len(cAm) = 1536 , len(out_cA) = 29175 > packet_num = 493 > len(cAm) = 1536 , len(out_cA) = 27639 > packet_num = 494 > len(cAm) = 1536 , len(out_cA) = 26103 > packet_num = 495 > len(cAm) = 1536 , len(out_cA) = 24567 > packet_num = 496 > len(cAm) = 1536 , len(out_cA) = 23031 > packet_num = 497 > len(cAm) = 1536 , len(out_cA) = 21495 > packet_num = 498 > len(cAm) = 1536 , len(out_cA) = 19959 > packet_num = 499 > len(cAm) = 1536 , len(out_cA) = 18423 > packet_num = 500 > len(cAm) = 1536 , len(out_cA) = 16887 > packet_num = 501 > len(cAm) = 1536 , len(out_cA) = 15351 > packet_num = 502 > len(cAm) = 1536 , len(out_cA) = 13815 > packet_num = 503 > len(cAm) = 1536 , len(out_cA) = 12279 > packet_num = 504 > len(cAm) = 1536 , len(out_cA) = 10743 > packet_num = 505 > len(cAm) = 1536 , len(out_cA) = 9207 > packet_num = 506 > len(cAm) = 1536 , len(out_cA) = 7671 > packet_num = 507 > len(cAm) = 1536 , len(out_cA) = 6135 > packet_num = 508 > len(cAm) = 1536 , len(out_cA) = 4599 > packet_num = 509 > len(cAm) = 1536 , len(out_cA) = 3063 > packet_num = 510 > len(cAm) = 1536 , len(out_cA) = 1527 > > I believe this is because the latter parts of the flow graph are blocking, > their buffers become full, and this backs up to my source block. This is > confirmed by connecting my source block to null sinks, which then allows > the source block to run infinitely (well, a long while!). > > Is there a way I can slow up this block? I tried using a throttle on the > output, but this doesn't help (in fact it seems to make it worse!). > > The full code of the block is attached. > > Thanks! > > David > > ________________________________ > > NOTE: The information in this email and any attachments may be > confidential and/or legally privileged. This message may be read, copied > and used only by the intended recipient. If you are not the intended > recipient, please destroy this message, delete any copies held on your > system and notify the sender immediately. > > Toshiba Research Europe Limited, registered in England and Wales > (2519556). Registered Office 208 Cambridge Science Park, Milton Road, > Cambridge CB4 0GZ, England. Web: www.toshiba.eu/research/trl > > > ------------------------------ > This email has been scanned for email related threats and delivered safely > by Mimecast. > For more information please visit http://www.mimecast.com > ------------------------------ > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
