|
PureBytes Links
Trading Reference Links
|
Perhaps this bit of information will be a clue. Just noticed it last week.
When running a a paintbar study on the emini tick bars some bars had one
color like they were supposed to and some bars had both colors. It was a
very simple paintbar study. If the close of the bar was above the moving
average the bar was painted blue and if below the average it was red. The
bars were 75 ticks each, or supposed to be. The average was 24 period
simple MA. The bars that were made from the previous day's data had correct
coloring and some of the new bars that were being painted with live data as
it came in were two tone, i.e. part blue and part red. Not many of them
were like that, but enough that it was noticeable. Now if the chart was
closed and then reopened the bars had correct coloring, that was done after
the market close. Next week I am going to watch this a bit closer and see
when the two tone effect occurs. Also by inserting the volume indicator on
a tick bar chart and using the histogram format, each volume bar should have
the same height if the Tick Volume option for volume has been selected. In
looking at various symbols it appeared that the tickloss percentage was not
a linear relationship from symbols that had a thousdand ticks or 4,000 ticks
or 25,000 ticks. The more ticks a symbol had the greater percentage of
loss. Like 2% for the big snp and 20 to 25% for the emini and that was with
no overflows on the TX920 port. I guess all this proves is the horse is
lame and shouldn't be ridden unless it is fed by the proper feed. Win98,
ProSuite, Global Server, BMI Data Manager, BMI satellite feed should not be
a recommended configuration is the bottomline feedback from numerous traders
that have gone this route before me. Using systems on tickbar charts on the
emini with this hardware configuration is an unequivocal, undconditional,
absolute no no.
BobR
----- Original Message -----
From: "Brian Massey" <bnm03@xxxxxxx>
To: "List, Omega" <omega-list@xxxxxxxxxx>
Sent: Sunday, March 19, 2000 11:27 AM
Subject: RE: DTN Satellite / Serial Card Alternatives
> "What puzzels me now is where do the emini ticks go. "
>
> My guess is that they're never reported by BMI and/or several trades
(ticks)
> are combined into one big trade (for stocks) and sent that way to conserve
> bandwidth. This could happen in futures too. For example sometimes in
> certain stocks you'll see a volume of over 100K for some ticks and it
> happens several times throghout the day. I think someone reported on this
> list that these are combined trades. If this is true, then it's possible
> that other ticks with less volume and therefor less noticeable represent
> several trades. Using tick bar charts will cause systems to behave
> differently with different data vendors.
>
>
>
> > -----Original Message-----
> > From: BobR [mailto:bobrabcd@xxxxxxxxxxxxx]
> > Sent: Friday, March 17, 2000 1:43 PM
> > To: .Omega List
> > Subject: Re: DTN Satellite / Serial Card Alternatives
> >
> >
> > OK, by lowering the receiver buffer size and selecting None for any
> > handshaking options, my Turbo920 had Zero overflows today on both
> > of the 920
> > ports. That is good. The bad is that the old tried and true
> > standby of TS4
> > on the same BMI satellite data feed on another machine received many
more
> > ticks than the ProSuite/GS/BMIDM. Both receive much less than what is
> > reported at HistoryBank.com each night. PS is on Win98 and TS on W95
> > machines. So, I am finally coming around to the conclusion that others
> > have, that BMI data is part of the problem, that the BMI Data Manager is
> > part of the problem, that the GS may be part of the problem, that the
> > version of Windows is part of the problem. What puzzels me now
> > is where do
> > the emini ticks go. If the Turbo920 doesn't report any overflows
> > they have
> > to be lost in the BMIDM or the GS. For the emini the loss can be
> > as high as
> > 20 to 25% in the GS whereas for other indices the loss is 2% or less.
The
> > higher the tickcount for the symbol the higher the percentage of
tickloss.
> >
> > BR
> >
> > ----- Original Message -----
> > From: "Jimmy Snowden" <jsnowden@xxxxxxxx>
> > To: ".Omega List" <omega-list@xxxxxxxxxx>; "BobR"
<bobrabcd@xxxxxxxxxxxxx>
> > Sent: Friday, March 17, 2000 7:40 AM
> > Subject: RE: DTN Satellite / Serial Card Alternatives
> >
> >
> > > No overflows here and I have used the 920 for over a year.
> > Global Server
> > is
> > > the weak link now. Can't wait to see what happens when DTN gets the
T1
> > line
> > > configured and data really flows.
> > >
> > > Jimmy
> > >
> > > -----Original Message-----
> > > From: BobR [mailto:bobrabcd@xxxxxxxxxxxxx]
> > > Sent: Wednesday, March 15, 2000 10:08 PM
> > > To: Omega List
> > > Subject: Re: DTN Satellite / Serial Card Alternatives
> > >
> > >
> > > Here is something to consider when trying to adapt some of the
> > high speed
> > > serial port boards to DTN or BMI satellite in hopes of minimizing
> > tickloss.
> > > These boards such as the TE920 are designed to accomplish the
> > high speed
> > by
> > > use of hardware or software flow control. The BMI satellite
> > receiver does
> > > not use any flow control and I have been told neither does the 115K
DTN
> > box,
> > > i.e. it is like a data hose and has no internal buffering.
> > After a week
> > of
> > > fooling around with configurations on the TE920 on DTN and BMI on
> > different
> > > machines and software, a friend of mine and I are still experiencing
> > > overflows. That means the buffers(even 64 byte buffers) are not
emptied
> > > fast enough before new data arrives. The 920 is an ISA board and in
my
> > case
> > > it had gross incompatibility with an internal modem in the adjacent
slot
> > and
> > > would cause screwy things to happen like windows would freeze and a
> > constant
> > > beeping error occurred. There were no conflicts with irq's or dma or
> > memory
> > > assignments...chuck the modem...with a nonbuffered port the machine is
a
> > > single function machine. Yes, it will do many things
> > simultaneously, but
> > at
> > > the loss of ticks. I just don't think that a 64 or even 128 byte
buffer
> > > will solve this problem. Thus, the requirement for a better
datamanager
> > and
> > > or a truly buffered board or box as mentioned below. I would like to
be
> > > proved wrong on this point.
> > > BR
> > >
> > >
> >
>
>
|