|
PureBytes Links
Trading Reference Links
|
One final (?) word on this subject:
If the problem is of the kind which does not appear until you create a new
chart or do something to the real-time chart which causes that chart to be
redrawn, you can at least save the correct data in ASCII form by dumping it
from the real-time CHART (NOT from the Server "edit tick" window). The
data are received and charted correctly, but stored in the data base
INcorrectly; So, if you dump from the chart, you capture the good data.
Note, however, that this provides the data only in ASCII form.
Regards,
Carroll S.
----- Original Message -----
From: "Gary Fritz" <fritz@xxxxxxxx>
To: "tony varela" <tonyvar@xxxxxxxxxxxxxxxx>
Cc: <omega-list@xxxxxxxxxx>
Sent: Tuesday, April 11, 2000 7:56 PM
Subject: Re: PriceScale -- ND, NQ, NDX
> > i was told not to change the price scale but to edit the first bad
> > tick with the same value as the last good tick(continuing so until
> > no bad tick existed), all this while in the edit tick screen, i
> > used a 0.5% filter. today the problem resurfaced again.
>
> Unless I am seriously mistaken, the Omega support person was confused.
>
> The problem he describes happens if you get a bad tick at the start
> of a block of 64 (? not sure about that number) ticks. All the ticks
> in that block are offset from the first tick in the block. If the
> first tick of the block is bad, all ticks in the block are bad.
>
> The symptom of that problem is that a block of 64 (or whatever)
> continuous ticks are wrong, then the price reverts back to the right
> price. It doesn't depend on the price, just on a fixed # of ticks
> after an initial bad tick that falls at the start of the block.
> After 64 ticks, the price reverts back to the proper range.
>
> That's not what we've been seeing lately. For one, you often see the
> price jump 655-odd points AND BACK, several times, within a few
> ticks. Also, the jumps happen precisely when the price passes 327+
> pts from the opening tick, and the jumps are exactly 655.36 high or
> low from where they should be. That doesn't fit with the "bad tick
> at the start of a block" problem, but it DOES fit the "16-bit offset
> from the open" problem. Finally, changing the PriceScale DOES FIX
> this problem. I changed my PriceScale and my data for yesterday
> stored properly.
>
> By the way, for some reason the OMZ files I posted are not working
> properly. When *I* download them, I see all the symbols I expect.
> But several people have said they see only @CCO and NDX, or only ND0M
> and NDX. I can't explain what's going wrong there. The OMZ file
> works properly on my system.
>
> Gary
>
|