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

RE: The Ideal DATA Server Features Wish List



PureBytes Links

Trading Reference Links

I think BS is referring to centrally stored and managed data on demand which
is not implicit in a data server.  He prefers the TsPro model where the data
is collected cleaned etc on the vendors server farm and then users plug in
and have access to real time quote delivery plus history on any symbol
without having previously collected the data locally.  Thus, it is not
necessary to store data locally on your own hard drive since you can "see"
any data you want on the vendor's server.

Personally I like Kent's model better.  Now that we have cheap huge hard
drives I vastly prefer to store data on my own hard drive and I insist on
having that choice.  I want fast, clean, reliable data too just like
everybody else.  But I want my data server to permit me to filter what I
want and store what I want on my hard drive.  Having access to history on
demand is a great idea as long as I can download it onto my hard drive and
pass it thru the filters I establish.  BS makes a point that traders
shouldn't have to manage data.  But once you set your filters up you dont
have to do anything except let the system collect and store the quotes.  If
you have a quality data feed there should rarely/never be any work necessary
except maybe downloading gaps caused by ISP outages etc.  I am more than
willing to do this occasional work myself to avoid being trapped by a
proprietary data on demand model.

If you use a pure data on demand setup like TsPro you are stuck with the
data they give you and you have no control over how well they do the job.  I
have no basis to trust Omega to do a good job on an ongoing basis.  Plus if
poor quality finally drives you away to a different vendor you have no data
on your harddrive since under the data on demand model you only get to look
at the vendors data not actually have it.  I anticipate that there are other
problems with data on demand such as server outages on weekends just when
you happen to want access to certain data.  Having the data on your local
hard drive eliminates these issues.  Moreover under the TsPro model your
software and data are completely proprietary and you cant just switch data
vendors.  You must completely walk away from your investment in TsPro.
That is the reason I will never use it unless they change the model, make
Ts2k and Ts4 compatible with thier data feed and continue to develop Ts2k.
More than anything we need competition and choice in data vendors since
nothing else will force them to improve quality.

No one has mentioned Up/Dn ticks and volume.  I would like a data server to
store U/D ticks and vol on a minute and daily basis.  I also want the
ability to control the logic by which the tick by tick allocations to Up and
Dn are made.  Omega's Ts4 and Ts2k data servers store U/D vol and ticks but
the logic has changed in Ts2k and causes occasional errors and there is no
way to access the daily values which are stored in GS.  More importantly I
would like the ability to modify the U/D allocation method so that more
accurate results might be achieved.

Regards

Bill Wood


-----Original Message-----
From: Kent Rollins [mailto:kentr@xxxxxxxxxxxxxx]
Sent: Tuesday, April 24, 2001 9:33 PM
To: OmegaList
Subject: Re: The Ideal DATA Server Features Wish List


Blowhard wrote:
>>i am sorry to say that but those are outdated specs
>>circa about 10-5 years ago.


Well, excuse the crap out of me.

Here are my thoughts on your specs:


- on demand real time  sever
Isn't this implicit in a "data server"?

- on demand historical server
Isn't this implicit in a "data server"?

- intelligent tick correction
He already stated that that would be a feature.  But thanks for confirming
that it is useful to you.

- bid ask data
Ah.  So you say this is a "newly important" (ie, not "outdated")
feature....interesting.

- tick correction based on bid ask
One useful thing you said which really didn't require asaulting my
wish-list.

- on demand real time L2 server / fast options
Again, this is "new"?

- fast
Duh

- reliable
Duh

- compact, well coded and portable
compact: Duh.  well coded: who cares as long as it's fast, reliable and
compact.  portable: not important to me.

- world wide coverage
Useful but again did not require asaulting me.

- fast API
Duh


Igno, Byebye