Actor Framework Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Actor framework for data acquisition and data process pattern

Solved!
Go to solution

Actually, debugging isn't any easier or more difficult with direct Q's. The reason people say be careful doing that is that you break the caller/callee communication paradigm and you introduce potential issues of not knowing who sent messages and why they sent them. Note that this is a guideline though. There are always reasons to break with the "strict" definition of frameworks. Mine is one. Actor messages are not fast enough by an order of magnitude for the data I'm slinging around. It's not unprecedented to add a direct actor to actor Q. Others here have done it. If you're having performance issue with actor messages, you should consider it. I use AF as more of an asynchronous shell framework with lots of nice features for startup, shutdown, and on-the-fly configuration. 

 

As a side note, the best way I've found to debug these systems is to have a very robust error and event logging system. Async processes can be very difficult to troubleshoot. By logging errors and their locations as well as custom error information, we've made the debugging process much more user friendly. 

0 Kudos
Message 11 of 26
(164 Views)


@wrkcrw00 wrote:

I pipeline data between actors using standard queue's that I create on the fly. I use actor messages only for configuration of the asynchronous processes. The actor cores of the pipelined actors enqueue / dequeue the data, perform whatever action they do, then re-enqueue down the pipeline. I have to do it this way because I'm pushing around a lot of data at pretty quick rates (100 Hz message rates). 


That is an idea. My project even faster (5000Hz). So I have to pipeline data. I also wonder if the AF framework can handle fast data rate.

 

 

0 Kudos
Message 12 of 26
(160 Views)

 


@BertMcMahan wrote:

Going around the AF messages can certainly be done but I've always read it's a bad idea due to difficulty debugging.

 

If I had an actor I wanted to pipeline, I'd give it a "Next pipe" enqueuer reference as its private data that gets set in its launcher. Don't forget, Actors are still Objects, and you can call methods directly on their reference wire before they get launched by Launch Actor. If you need to change destinations after launching, use another message.

 

When it's done with its processing, it fires the data out to the "Next pipe" AF enqueuer.

 

This still goes around the "standard" AF tree structure, but I think you gain some benefits of using the AF message structure instead of standard Queues. Just my preference though.



To Bert's point: There are certainly different ways to use the Actor Framework.  It is written a certain way for a reason. For some use cases you may have to do things slightly differently (ie enabling nested actors to communicate directly across the tree.)  My recommendation is to do this if necessary, but to understand the implications.

 

When it comes to using secondary communication mechanisms between actors such as additional queues, notifiers etc THERE BE DRAGONS!  You can certainly do it and there may be some use cases where it is absolutely necessary, but there are risks.  My recommendation is, in general, having more than one communication mechanism (ie in AF using anything other than the actors queue) is a code smell. Doesn't mean it is wrong, just that you really want to examine that decision carefully.

Sam Taggart
CLA, CPI, CTD, LabVIEW Champion
DQMH Trusted Advisor
automatedenver.com
GCentral
0 Kudos
Message 13 of 26
(148 Views)

@wrkcrw00 wrote:

Actor messages are not fast enough by an order of magnitude for the data I'm slinging around.

 


Interesting- I thought that AF messages used queues as their backbones. With dynamic dispatching of the payloads I wouldn't think they're any slower than a normal queue. What kind of limits are you seeing? I have used large data packets before to get reasonably quick throughputs (16 MB/sec, two DAQ cards sampling 16x analogs at 1 MS/s each- not "vision processing" throughput, but not trivial either), though my setup sent large messages at around 10 Hz, not small messages at 1 kHz.

0 Kudos
Message 14 of 26
(147 Views)

10Hz with actor messages is usually pretty solid. 20Hz is questionable (depends on the system). 100Hz is no go (note that my systems have several tasks running at 100Hz chunk rates). AF enqueuers are a set of 4 queue's under the hood. But there is some overhead involved, including dynamic dispatch. The DD time penalty isn't big, but it's non-zero. It does add up. There are a few other things that cause overhead in AF messaging. They are there for a reason, and make the framework as flexible as it is. They are good things. It's just not applicable to all situations. Mixing and matching frameworks is ok, you just need to understand the complexities and hopefully know what you are doing Smiley Surprised.

0 Kudos
Message 15 of 26
(143 Views)

I should clarify, I'm running 3-5 tasks on a cRIO at 100Hz chunk rates, while also doing a bunch of processing. Every system is different and your mileage will vary, but generally speaking AF is not meant for "fast" message rates.

0 Kudos
Message 16 of 26
(140 Views)

Good to know. I'm still surprised that the limit is as low as it is (20 Hz seems like there must be massive amounts of overhead in the "severals" of milliseconds).

 

I don't mean to say "never go outside the bounds of the framework", just "do this with caution, as it's not generally advisable". Very high messaging rates is, of course, a valid reason to do it. Very high total throughput with large chunks is (probably) not a good reason to do this. You clearly have a solid reason to do it, and I don't mean to disagree with your application.

0 Kudos
Message 17 of 26
(137 Views)

@wrkcrw00 wrote:

10Hz with actor messages is usually pretty solid. 20Hz is questionable (depends on the system). 100Hz is no go (note that my systems have several tasks running at 100Hz chunk rates). AF enqueuers are a set of 4 queue's under the hood. But there is some overhead involved, including dynamic dispatch. The DD time penalty isn't big, but it's non-zero. It does add up. There are a few other things that cause overhead in AF messaging. They are there for a reason, and make the framework as flexible as it is. They are good things. It's just not applicable to all situations. Mixing and matching frameworks is ok, you just need to understand the complexities and hopefully know what you are doing Smiley Surprised.


Good to know that. In my project, as what you said about chunk rate, it is 5kHz. Then, AF message rate will not be competent. 

 

 

0 Kudos
Message 18 of 26
(134 Views)

Not sure if this help, but here's another data point. We've recently finished a project on a cRIO-9038 that was sampling 16 channels at 50kS/s, chunking and sending messages every 200ms (160,000 points per message) to a calculation actor. We never had any issues with the system keeping up, so I think you can make it work with less frequent but larger messages.

0 Kudos
Message 19 of 26
(132 Views)

@wrkcrw00 wrote:

I pipeline data between actors using standard queue's that I create on the fly. I use actor messages only for configuration of the asynchronous processes. The actor cores of the pipelined actors enqueue / dequeue the data, perform whatever action they do, then re-enqueue down the pipeline. I have to do it this way because I'm pushing around a lot of data at pretty quick rates (100 Hz message rates). 


 

The configuration parameters should be in the private data of the actor class. May I ask how do you give the configuration to the standard queue as you create it on the fly.

0 Kudos
Message 20 of 26
(130 Views)