|
PureBytes Links
Trading Reference Links
|
Once again-- Here is an overview of the process:
It's not a question of whether or not the tick is good or bad-- if it's
good, it is processed normally and you continue on to bag your normal
$100,000 profit for the day. Assume that it's bad, for this example:
First of all the tick *DOESN'T* plot correctly on your chart-- If it's zero,
it plots as zero and you must do the "right-click edit" thing to fix it.
After this, your real-time chart is accurate-- This example assumes
**ONLY** the first tick was bad-- Sometimes, subsequent ticks are bad
(particularly at the opening of the Market-- especially NASDAQ high fliers)
and this will create additional havoc with your RT charts.
The server takes the same bad tick --uncorrected-- and proceeds to store it
and use its value as the basis for the next 60 ticks (actually, it's
probably 63 ticks, but why confuse the issue further).
The server doesn't store the next ticks as they are received-- (but they
**ARE** used to generate your RT charts) -- it calculates the difference
between the new ticks and the original tick in the block and uses the result
of this calculation to generate the value of the next 60+ ticks in your
database-- If the original tick was accurate, there is no problem. If the
original tick was bad-- the next 60+ ticks are based on this erroneous first
tick and stored in your database that way.
If you re-generate your chart by using real-time data-- such as scrolling
your work-spaces using the Page Up/Page Down keys-- your charts are
re-generated from the data in your Ram --which you corrected-- so the charts
are accurate.
If you generate a completely new chart --such as, by clicking on the chart
icon-- the data is drawn from the file on your hard-drive which has the
erroneous data-- the chart will be corrupted.
Currently, the only way to fix the corrupted data is to edit the first tick
--after the close of the Market-- to a correct value-- or some value near
the accurate value-- such as, the value of the previous tick. TS will then
re-calculate the subsequent ticks in the block and they will be accurate.
If you delete the first tick in the block (as opposed to editing it), you're
SOL because TS needs this tick as a basis for calculation of the next 60+
ticks. In this case, you will need to manually edit each of the subsequent
60+ ticks to correct them.
Hope this makes sense...
Moral: Don't even attempt a discussion at this level with someone named
Melody :)
___________________________
At 06:15 PM 10/3/98 -0700, you wrote:
>ok, one more time
>
>-receive tick from receiver, don't know if it's good or bad at this
>point
>
>-tick plots on ts4 tick chart in real time correctly and at the proper
>value, no bad tick evident yet
>
>-check tick history and find blocks of bad ticks
>
>-force a redraw of ts tick chart and now a block(s) of bad ticks appear
>
>is this what you're finding? this is what i found and reported as
>such to melody with gif snapshots for proof.
>
>my question to melody was: were the ticks originally good and then
>corrupted by the server -or- was initial block tick bad and the server
>corrupted the rest of the 60 tick block?
>
>TJ
>
>---Ron Augustine wrote:
>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.
>
>
|