Quote:
The first such Delay is that the BA Application only outputs one table of Updated Data every ten updates. The Main Helper Controller Object cannot even Read the parsed Data until the Helper's DataParser gets done splitting all the BA data into Brand size Bites and turned its own (Read) Ready Property to True.
This answers my question:
Quote:
I am not sure where the split between a 20ms update rate and a 200ms update rate is occurring in your model, is it the Helper.Accumulator that is going to do this, so the FIFO per brand name is updated every 200 ms (10 frames) of is the Brand object going to do this, so it only call the calculator units once every 10 updates?
However it immediately raises another question:
Who is doing the OHLC calculation.
I presume from what you have said that the BA Application is not doing this, what this means is that once every 10 updates the BA application write out 10 updates, the Main helper unit process this and then the Brand unit goes through the 10 updates to do the OHLC calculation before it can start the indicator calculation.
I sure you can see that if the BA application did the OHLC check on every update then when it came to do the update on the tenth update, there would only a single comparison to make and so the OHLC check will take less time on that particular update, also it would only need to output 4 variables instead of 10.
Note I am not suggesting the BA application does the OHLC check, I am just using this to illustrate that controlling when calculations are done can improve throughput enormously.
As I stated in my earlier post #50:
Quote:
Minimising the Maximum calculation time is one aspect of maximising throughput without loss of updates.
Quote:
There is no fixed time interval available, That is provided by an out Object over the internet.
How are we supposed to calculate the Time constants for EMA if we don't know how often the series is being calculated.
By using BA Update tiks, or as close to a constant fraction thereof as we can manage. Everybody involved understands that an Update tic is as close a timing mark as is available. We cannot Force BA to follow any timing system we use. Our Timing must be based on the BA. The Curves the outputs are based on will be a little fuzzy, but close enough and a whole lot faster than using a TI Scientific calculator. The Prices in a Race just don't move that fast.
If we are going to use the BA updates as our “clock” we need to find out how accurate that is and how much it varies. Does the update rate vary depending on the race?, the number of horses?, the internet connection??, how long it is to the start of the race, does it vary during the 10 minutes up to the start of the race.
Since one of the requirements is to get a reasonably accurate time dependent calculation, we need to be able to adjust our “smoothing” constants in the calculator objects depending on what the actual update rate is. We also need to cater for the last 3 seconds of data being a variable number of items.
One thought I had for CPerry : “ Does betangel time stamp the updates?” if they do that would be great. ( Note in the financial application I did the data was time stamped, so problem solved)
So if we are going for a variable recalculation rate ( max) we are going to need to do a lot of extra processing to sort out the time. Is this really going to give us a greater throughput than building it as a deterministic system where we control what gets updates and when?
