# Async message flow control

**URL:** <https://www.ruby-forum.com/t/async-message-flow-control/239450>\
**Category:** GNU Radio\
**Created:** [February 26, 2014, 6:02pm UTC](https://www.ruby-forum.com/t/async-message-flow-control/239450 "2014-02-26T18:02:23Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\
**Post date:** [February 26, 2014, 6:02pm UTC](https://www.ruby-forum.com/t/async-message-flow-control/239450/1 "2014-02-26T18:02:23Z")

</div>

How does one achieve flow control with the new style message passing  
API? I have a use case in which I’m generating packets in one flowgraph  
and pushing them through a pdu\_to\_tagged\_stream (P2TS) block to be  
modulated in another flowgraph. I believe I’m overwhelming the P2TS  
block’s queue because I get warnings about dropped messages. One hack I  
made was to insert a throttle block into the packet generating  
flowgraph. This helped a bit, but I have to guess the magic throttle  
rate at which I don’t fill up the queue. Is there a way to have P2TS  
block when its queue is full and therefore generate backpressure on the  
upstream flowgraph?

I basically have flowgraph (FG1) --\> message domain --\> flowgraph (FG2)  
–\> USRP. FG1’s flow rate is not constrained by streaming backpressure.  
FG2’s flow rate is constrained by a USRP. To constrain FG1’s flow rate I  
either have to use a throttle block or find a way to enforce flow  
control in the message domain.

Thanks,  
Sean

---

<div class="post-metadata">

**Author:** ![NowlanS\_Sean](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/n/f05b48/32.png) [@NowlanS\_Sean](https://www.ruby-forum.com/u/NowlanS_Sean)\
**Post date:** [February 27, 2014, 3:38pm UTC](https://www.ruby-forum.com/t/async-message-flow-control/239450/2 "2014-02-27T15:38:07Z")

</div>

On Wed, Feb 26, 2014 at 12:00 PM, Nowlan, Sean  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> Sean

Nope, no flow control on the message ports. Their original design was  
for control and meta data messages, but we quickly realized their  
capabilities with passing packets. Flow control here is one of our  
identified problems that we don’t have a current solution for. In  
other words, if you come up with something, we’d be very interested to  
hear it and will definitely work with you on it.

Tom