[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fwd: server /charting problem with bad ticks]


  • To: omega-list@xxxxxxxxxx
  • Subject: Re: [Fwd: server /charting problem with bad ticks]
  • From: Carroll Slemaker <cslemaker1@xxxxxxxx>
  • Date: Sun, 4 Oct 1998 20:37:47 -0400 (EDT)
  • In-reply-to: <199810041558.IAA21422@xxxxxxxxxxxxxx>

PureBytes Links

Trading Reference Links

Ron Augustine wrote:

> Moral: Don't even attempt a discussion at this level with someone
> named Melody  :)

This was a cheap shot, Ron, and undeserved.  The information which
Melody  FORWARDED  to me originated with Omega's software engineering
group.

Thanks for your (Ron's) response in which you explained the problem. 
However, it is an explanation with which I am intimately familiar, and
have been for a long time.  Unfortunately, it is wrong, at least with
respect to the cases to which I am referring.

In one of your posts on this topic, you said that "we may be talking
about two different things" (in a response to Trade Jack) and that is
correct.  BMI subscribers, apparently, suffer a recurring problem in
which the first tick of the day is bad.  Such a bad tick, obviously,
must be the initial tick of the first block of the day and I am sure
that your description OF THAT CASE is accurate.

I, however, subscribe to Signal and I have never seen that problem. 
What I HAVE seen, however (along with many other subscribers to both
Signal  AND  BMI) is one or more disjoint groups of bad prices for $INDU
occurring in mid-day or afternoon but with the following properties:  a
chart constructed in real time does NOT show ANY bad prices;  a chart
drawn (or redrawn) from the database shows lengthy groups of consecutive
bad prices;  correction to the stored values of one or more
initial-block prices causes all the bad prices to appear correctly.

It is a simple matter to simulate each theory which purports to explain
this problem - and that is what I did in the lengthy analysis which I
sent to Omega and later posted to this List.  Simulation of the old
"standard" explanation gave results completely at odds with what we are
seeing;  simulation of my theory gave precisely the results we are
seeing.

One thing I reported to Omega but did not include in my earlier post to
this List is the following.  One day I "caught TS in the act" - that is,
I discovered that the data was corrupt while I still had an active chart
showing tick data for $INDU collected in real time.  First I went to the
"View Data" window (I believe it's called) for that real-time chart and
dumped the data to an ASCII file.  Then I went to the $INDU "Edit Tick"
window in the Server and dumped that data to another ASCII file.

Then I loaded both files into a text editor as separate columns and
aligned them so that corresponding prices in both files appeared on the
same line.  The files, of course, matched tick-for-tick except that the
one dumped from the database had several lengthy runs of bad prices.

Locating the first bad price, I used the corresponding good price to
correct that bad price in the Server's "Edit Tick" window.  This would
cause a large block of the bad prices to now be correct (in the "Edit
Tick" window).  I continued to do this until all the bad "initial" ticks
had been corrected.  I then dumped the database data to a third file,
inserted it into a third column of the text editor, and aligned it with
the other two.

The first and third columns matched EXACTLY;  these columns also exactly
matched the middle column above and below the group of bad prices.  The
key observation here is that the price in column 1 which corresponded
with the first bad price in col 2 was PERFECTLY GOOD.

One final comment - note that Omega's engineering dept agrees that my
"theory" is correct:  in the subject cases, the data is received
correct, is displayed correctly in a real-time chart, and is corrupted
in preparing it for insertion into the database.

Carroll Slemaker