Derived vs Iap
Jim Bretz
Looks like my post pitting Derived vs Iap parameter got buried. Let me post
it one more time.
Depending on the equations it might actually be better to process the
equations on the clients. This is the case most of
the time. Generally, the derived processing is only a small fraction of the
processing that the client PC has to endure. The main load is usually
graphics and actually data handling. The rule of thumb is to only use the
IAP processing if absolutely necessary.
Advantages to running an equation on the client:
1) The processing and storage requirements on the CDS are greatly
reduced. In some extreme cases, the storage and processing requirements
are reduced by a factor of 10 or more (i.e. 1 gig vs 10 gigs, 2
megs/second vs 20, etc).
2) Functions are processed on a "as needed" basis, so only what's being
viewed on the client at that specific moment is calculated. This helps
to keep the derived processing requirement very low.
3) It gives the user more flexibility to correct the equation and have
those changes take effect "instantly" (and apply to all past data as
well). Because the results of the equations aren't saved to disk,
correction can be made at any time without the need to correct and
rewite
an entire data file.
4) Computations are in essence "parallelized" amongst the user PCs. Only
users with a huge amount of derived equations are strapped with the
computational expense (an thus only their display runs slower).
Disadvantages to running an equation on the client:
1) It's possible to overload a single PC with derived equation, but this
is extremely rare. It generally only occurs when "heavy hitting" custom
COM functions are being used (i.e. non IADS developed).
2) Running an equation as an IAP can actually slow the client down
because now it's forced to get more data from the CDS. It's a fine
balance and depends on how many parameters and their sample rate.
Advantages to running an equation on the IAP processor:
1) If you are developing a custom COM function (or derived equation for
that matter) based on an algorithm that doesn't tolerate time jumps or
reversals, it's best to run it as an IAP. On the client, the time for
computation follows the user wherever they jump/scroll/etc.
2) Again regarding custom COM functions... if ran on an IAP processor you
no longer need to distribute the custom dlls to each workstation. This
helps with configuration control.
3) If you develop an equation that takes a large amount of processing
horsepower, you can isolate this function to an IAP processor. As
mentioned before, in most cases, this is usually a result of running a
custom COM function and not an equation developed by the Iads standard
functions. I'll never say never though... I'm sure you could bring the
machine to it's knees with a 100k sps equation ;)
4) If your customer requires data files for these parameters due to some
post flight restriction or otherwise, you can supply them a data file
using this mechansim
Disadvantages to running an equation on the IAP processor:
1) Single point of failure for derived calculations. It's rare, but if
the IAP processor goes down, all of your derived equations computed by
that IAP will stop. Usually, this occurs when you're running a custom
COM
function (non IADS). Of course, the IAP processor can be restarted.
2) Performance issues... If the IAP processor can't compute the derived
equations within a given time frame (20 ms), this could cause
misalignment of data or "blocked requests" (long discussion). Of course,
you can "load balance" the equation processing among several computers
or
CPUs, but this adds more complexity and testing time. In essence, the
whole process becomes more complex.
I guess the bottom line here is that it's simply more complexity, risk,
and work to run derives as IAPs. Don't get me wrong, it's a great tool
and is absolutely needed in some instances. What I'm trying to point out
is that I (myself) would only endure the extra burden if I was forced to
by one of the conditions above.
The best bet is to run without IAPs first, then evaluate the client PCs
performance. If the update rate looks acceptable, then you're done ;)
If you want to press on with a comparison study, you can use the "Perf"
button on the dashboard to bring up a performance tool on the client PCs
and check the "Updates per second" statistic. If it's not acceptable, you
can experiment by switching the parameters to IAP and running the test
again (noting the before and after update rate).
Like I said, most of the time, the rate is directly related to graphics
processing, data handling, or "dynamics" on the ActiveX displays... but I
could be wrong depending on how complex your equations and
AnalysisWindows are designed.
Jim