PureBytes Links
Trading Reference Links
|
Carroll,
I think you may have a slight misunderstanding of what is actually
happening. From my research, I've found the following:
The problem originates with a bad tick that is received from the real-time
data feed. This probably comes from the clerk incorrectly inputting the
data on the floor of the Exchange, but could also creep in somewhere along
the vast network of components that are involved in transmitting the data to
your computer.
When the bad tick is received, it is stored in the Ram memory of your
computer and this data is used to generate your charts. The initial tick is
charted at the value received and subsequent ticks are charted at their
correct value. You can correct the original bad tick on your real-time
charts in the normal manner-- thus, your chart would be displaying correct data.
The incoming data is also stored in your database at the same time that it
is charted. If the bad tick was the first of the day --or the first in one
of the 60-tick blocks-- it will be stored incorrectly, as will the following
ticks in that block. This is due to a compression scheme that is employed
to save disk space.
Only when you close your chart and re-generate it --or generate a new chart
from the database data-- will the series of bad ticks appear on your charts.
The difference is determined by whether the chart was generated directly
from real-time data or from database data.
The only way around the problem would be to have the server trap the
incoming bad tick and compare it to a user defined set of criteria to
determine if it should be discarded (For example: toss out anything that is
1 percent different than the average of the past 5 ticks). This is not
possible in TS4, but I believe it will be possible in TS5.
I hope this explanation was understandable--
_____________________________________
At 03:21 PM 10/3/98 -0700, you wrote:
>
>Here, however, is what these spokesmen are, by implication, asking me to
>believe:
>
>1. The reason we did not see the bad ticks in real time is that even
>though the Server received and stored these bad ticks, some mysterious
>problem in all our computers caused EACH and EVERY bad tick to be lost
>somewhere between the Server and the charting module.
>
>2. Even though the chances AGAINST this happening are nearly 60 to 1 for
>each individual "bad tick", EVERY ONE of the roughly twenty "bad ticks"
>just happened miraculously to arrive at our various computers at the
>precise instant when our Servers were ready to enter the initial tick of
>a new block.
>
>My final and principal question is: Does the above correctly describe
>your official position? If not, then will you please provide an
>explanation which accounts for all the above observed characteristics?
>
>Thank you very much.
>
>Carroll Slemaker
>_____________________________________________________________
|