________________________________________ From: trond...@trondeau.com [trond...@trondeau.com] on behalf of Tom Rondeau [t...@trondeau.com] Sent: 31 July 2014 19:11 To: David Halls Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Slow down rate of Python source block
On Thu, Jul 31, 2014 at 12:21 PM, David Halls <david.ha...@toshiba-trel.com<mailto: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 ******************************************************************************************************************************************************** Tom, Thanks for your reply. Unfortunately as it is a Python block, I cannot use 'set_output_multiple'. For 2. do you mean set the input signature of the blocks fed from the source block. This could be possible but quite a few different blocks (some standard GR blocks) are fed from it. Could you provide some more details, or a link to similar implementation for option 3. - again is this possible from within a Python block? Regards, David 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<http://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<mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ________________________________ 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
