|
PureBytes Links
Trading Reference Links
|
I see this kind of behavior quite frequently with TS4.0. The problem
was worse with BMI than with Quote.com, however. It could be the
time-stamp issue:
TS4.0 processes each real-time tick in the order it is received. Each
tick retains the data feed time-stamp. But when reloading a chart
TS4.0 constructs the bars from the time stamps on the ticks so the
bars can be different.
There are sometimes ticks out of time-stamp order. TS4.0 does not
actually save out-of-order ticks in the data base (I think) but they
will appear on a real-time chart and trigger trading signals. An
incorrect time-stamp may even trigger the close of a bar before it
should close. TS4.0 does not give an error message on out-of-order
ticks.
This gives different behavior in real time than when reloading the chart.
Quote.com re-time-stamps all quotes it receives since the time-stamps
on the data received from the various exchanges are wrong from time
to time so this helps quite a bit. But the Quote.com servers
sometimes add incorrect time-stamps. (I have suspected that they
might even intentionally introduce errors when they are busy to keep
the internal delays from being so obvious, but that is just a
suspicion...)
TS2000i re-labels the time stamp of each real-time tick as it is
received. They are given the time stamp of the computer clock so you
need to be sure your computer clock is synchronized with an atomic
clock with a utility such as AtomTime. This, at least, makes the
performance the same for real-time and historical tests on the same
data. Obviously, this assures that time-stamps are in order so all
ticks can be saved in the data base.
But this still has a flaw if you download historical data from
Quote.com with something like DynaLoader. These downloaded ticks
retain the original Quote.com time stamp which will usually be a few
seconds to minutes different than the computer clock. (TS2000i
time-stamps to the second whereas TS4.0 time-stamps to the minute.)
So the time-stamps on downloaded data will not quite match the
time-stamps inserted real-time by TS2000i.
Some of these time-stamps are out of order in the historical data.
TS2000i gives an error message when trying to load an OMZ file with
out-of-order ticks but TS4.0 does not. Historical downloads from
Quote.com have lots of out-of-order ticks and I know DynaLoader had
to add special processing to handle them. I don't know if they
reorder them or discard them but the current DynaLoader version gets
rid of out-of-order ticks somehow so you do not get error messages
when pasting the OMZ files into TS2000i.
I "reverse engineered" the rules for how TradeStation creates
time-stamped bars a while back for a project that required creating
"synthetic bars". My findings are summarized below in case you are
interested in trying to trace the error in detail.
Bob Fulks
----
For time-based bars they appear to do the following:
For example, consider the 30 minute bar labeled 1530:
The calculations are done on the first 1530 tick.
The Open of the 1530 bar is the first 1500 tick.
The High of the 1530 bar is the highest tick of the interval from the
first 1500 tick up until and including the tick prior to the first
1530 tick.
The Low of the 1530 bar is the lowest tick of the interval from the
first 1500 tick up until and including the tick prior to the first
1530 tick.
The Close of the 1530 bar is the value of the tick prior to the first
1530 tick.
----
For multi-tick bars:
The Open of the bar is the value of the first tick.
The High of the bar is highest tick of the interval from the first
tick up until and including last tick.
The Low of the bar is lowest tick of the interval from the first tick
up until and including last tick.
The Close of the bar is the value of the last tick.
Multi-tick bars are labeled with the time of the last tick.
----
>Has anybody seen behavior like this before?
>
>My partner and I are running the same systems on parallel TS4's.
>Both are running Quote.com data. We sometimes get minor data
>differences but no big deal.
>
>Recently, including twice this morning, his TS4 has acted weird. In
>one case it failed to register a signal I got. When he re-applied
>the same system to the same chart with the same parameters, it got
>the signal correctly.
>
>In another case he got a signal when I did but the price was wrong.
>The system computed a sell price by subtracting a value (8.0) from
>the Low of the current bar. The Low of the bar on his TS4 AND mine
>was 1532.1. His TS4 signalled a sell price of 1525.7!? 1525.7 + 8.0
>= 1533.7, and he didn't have ANY bars that had a Low of 1533.7.
>Knowing the code, I can't see any way it could have computed that
>value, though I wasn't at his TS so it's possible I missed something.
> But then he re-applied the same system on the same chart, and it
>calculated the correct stop price of 1532.1-8.0 = 1524.1.
>
>This is NOT a case of "bouncing ticks" changing signals between
>realtime and historic charts, or anything like that. These systems
>behaved patently wrong in realtime, and we could see it. We checked
>all the parameters and verified they were set up right. Then they
>worked right when we re-applied them.
>
>Any guesses???
>Thanks,
>Gary
|