|
PureBytes Links
Trading Reference Links
|
"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
> >
> >
>
|