|
PureBytes Links
Trading Reference Links
|
----- Original Message -----
From: "Jerry" <drwar@xxxxxxxxxxxx>
To: "'Bilo Selhi'" <citadel@xxxxxxxxxxxx>; <omega-list@xxxxxxxxxx>
Sent: Tuesday, April 24, 2001 11:09 PM
Subject: RE: The Ideal DATA Server Features Wish List
> Bilo
>
> By cleaning, Are you referring to discarding bad ticks by some known
process
> of elimination? Or some method of replacement/recalculation of what the
> value should have been.
>
> This is quite an eye opener. Do you have any references or links to
> information about all this.
system performance is largely a function of noise in price time series.
if there are bad ticks or outside trades in price then noise increases.
bad ticks are usually digit drops or errors in data. those are easy to track
on the server level. you have to check for digit drops on every ticks
comming in.
outside trades are trades that either reported late or special regulation
trades. those are easy to track also. NAZ or NYSE transmits flags for
special
regulation trades or late reported trades so they can be tagged also
there is also the problem with missing data ie data gaps. all you can do
there is
at least provide audible and visual alert to the user on datafeed drops.
bad ticks is also a function of the exchange the data is coming from
and the datafeed vendor.
NY futures exchanges are very noisy.
Chicago exchanges are pretty good.
NYSE is not too bad with occasional late trades
NAZ is the worst.
>
> > - data vendors care not about the tick correction which
> > is the main thing ( system performance can be improved
> > by 1/2 just by cleaning your data!!! resulting in 1/2 noise
> > reduction )
>
> Is this the process you use ?
take a naz stock and filter out data based on inside bid and ask.
then compare... you will see what i mean.
to properly filter out last based on bid ask what you do is
any trades outside of best bid and ask + or minus up to 1-3 outside
levels ( input depending on spead and liquidity ) should be ignored
because most of those trades are late reported ticks....
once you do that then data becomes uniform, tight looking and
true to what that trades really were.
many times in naz market makers will report block trades 1-5 min later
which creates spikes. that's why naz price is so jumpy on high resolution
data. now that will screw up your system at those resolutions like there
is no tomorrow. if you use a stop order you will get an order where
the price has not traded yet or you will get stopped out where you
should not get stopped out...
looking at Tradestation Pro data i can easily see that they are not
filtering those late reported trades out, means they are not tracking
tick regulation flags and eliminating those. but they do seem to filter out
digit shifts and 0 ticks and large ticks. so they might be using % band
around data or similar technique.
if you take a look at 1min csco on Tradestation Pro you will see
spikes everywhere. there are no large spikes but those late trades are
everywhere....
also they don't seem to get it that you need to give the user an audible
alert if the feed goes down ( data gaps ) and then it goes back up...
meaning
they are not detail oriented there.
>
> > - bid ask cleaning is unheard of... although it's fairly easy
> > to implement on a server farm level.
actually if they just provide the api and last, bid ask, it's all needed for
now to get the filtering done on the user level so that they don't have to
mess with it.
> >
>
>
> Thanks
>
|