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

Repost ATI_list subject_TradeLab good news



PureBytes Links

Trading Reference Links

There has been such a flood of list and private mail about the UMDS that I
will comment here collectively about several issues, rather than making
individual responses.

> Nice to hear about progress on the server front! Since
> I assume that much of the data charting interface is
> server dependent, it would appear that the server
> decision is critical to moving forward.

There are many interdependencies.  It is possible to make the translations
necessary so widely different products can work together, but just as with
mechanical devices, product matings nearly always are more satisfactory
where products were designed early on to be used together.

> I've been keeping up with the UMDS web pages for some
> time and I do have a couple of concerns:
>
> 1) One attraction of TL was the open data format and the
> ability to write VB programs which would support import/
> export of data to/from any source. For example, I have
> recently written a VB program which processes the Time
> and Sales files posted nightly by the CME (free and
> accurate) into tick data and then builds replacement
> intraday datafiles for Ensign as well as ascii intraday
> files for SuperCharts. Also, I'm in the process of writing
> VB programs to import and manage EOD futures and
> continuous contract data from Pinnacle.
>
> From what I've been able to determine, the UMDS interface
> is closed and the ability to import data is going to be
> limited and subject to the purchase of additional software
> ($250-$350) as well as specialized dll's (cost unknown)
> and (perhaps) the purchase of data from limited sources.

We need to be clear about the interface level we are discussing.  The UMDS
interface is not "closed."  MarketStream sells an Application Programming
Interface (API) kit to developers writing application programs like TradeLab
.  The cost is about $1,300.  I don't remember exactly.

It contains documentation suitable for professional application programmers
and about 30 interface functions in a DLL.  Few traders would understand the
documentation or know how to use the functions.  MarketStream cannot afford
to both provide the kit and teach someone to program for the fee, so it is
shipped only after advanced programming knowledge is demonstrated in
telephone discussions with the developer.

That is reasonable, both because of the impossible technical support problem
that would result if most traders were to buy the kit and because
MarketStream has an interest in insuring interfacing is done correctly, so
the server isn't blamed for problems caused by incorrect interfacing.

However, none of that will be important to most users, because they will
have no need to interface to the server directly.  TradeLab will interface
for them.

The UMDS-to-TradeLab interface will write UMDS database data out to standard
ASCII and TradeLab IEEE data files.  It also will read data into the UMDS
from both those file formats and from an Omega Server database.  It will
make direct server interfacing unnecessary.

It will be simple to use.  There will be no need to chart and then paste out
small sections of data as required by TradeStation.  You simply will specify
the data you want, the format you want it saved to, and a file name.

It is my understanding that data import/export capabilities also are being
added to other application programs that use the UMDS.  Any of them could be
used to get data into or out of the server for the benefit of all interfaced
programs.

> The UMDS pages are silent on the issue of limitations
> regarding the aquisition/cost of replacement tick
> data and EOD data.

No data will be provided with the free version of the server, but the UMDS-
to-TradeLab interface will let you copy data from an Omega Server if you
also have an Omega Server interface.  It also will let you import ASCII data
files from any end-of-day data service.

If you pay MarketStream a license fee for the "open" version of the UMDS
that can be used concurrently with multiple trading programs, you will be
able to download tick and daily data from the web without additional charge.
 The primary purpose of that service is to provide a way to fill gaps where
a user's datafeed or computer has been out of service.  I don't know how far
back data will be available.  We were told the only issue with that is
required storage space and that old data will be removed from time-to-time
to keep the disk space requirement reasonable.  The storage space
requirement will be greater than with the similar service provided by Omega,
because the MarketStream database will include tick and daily data for every
symbol on a datafeed.

We understand MarketStream also will provide past data on CD.  I am not sure
if there will be an additional charge for that.

We can't quote prices for MarketStream, but their web site shows the license
fee for the "open" version of the UMDS will be $375, with a $25 discount if
it is ordered electronically.

> The one negative impression of UMDS which I've taken away
> from their webb pages is that I can look forward to
> continued severe limitations in access to _my_ data.
> Would you please address this issue?

I commented on that above.  You will have easy access to your data.

> 2) I concur with the advantages of drawing intraday chart
> data from the ticks rather than pre-building intraday
> files ala Ensign and TradeStation, especially when it
> comes to the issue of fixing bad ticks. That said, the
> fact that UMDS holds everything in memory is of concern
> when the inevitable computer crash occurs. Does UMDS
> provide some kind of logging process which will 1) prevent
> the total loss of data acquired prior to a crash and 2)
> permit the quick reloading of the tick data so that charts
> can be maintained. In my experience, the worst part of a
> crash is not the couple of minutes of data lost during
> reboot but the loss of a major chunk of data not saved
> prior to the crash.

Even though the UMDS maintains all the data received during a day in memory,
it saves new incoming data to disk each minute, so only 30 seconds of the
data received before a power failure will be lost on average.  The server
design is unusually robust with respect to power failures.  The database
index file usually isn't corrupted like it often is with most designs.
Where the index hasn't been corrupted, the UMDS is able to restart almost
instantly.  On rare occasions where it has been corrupted, index rebuilding
is unusually fast.  I don't think you will find a server that is more robust
in that respect.

> Interfacing of Tradelab with the Universal server is very
> good news.
>
> Will Version 3 of the Universal Market Data Server still
> have the limitation of not collecting data for 5 minutes
> during every 24 hours ? This can be a problem for those
> trading the spot forex markets which trade 24 hours a day,
> 5 days a week.

It probably will.  MarketStream is aware of the importance of not losing
incoming data at any time.  However, end-of-day processing must occur once a
day and it is difficult to perform while processing incoming data.  It is
something like the problem of transacting new sales while counting money in
a cash drawer, except there are millions of transactions to keep track of.

It may be possible to cache incoming data during that time and then process
it late, but that would slow end-of-day processing and a multi-megabyte
cache would be required to cache a data stream for five to ten minutes if
there happened to be a burst of trading activity.  Incoming data could be
cached to disk, but that would slow processing far more, because the disk is
needed almost constantly during end-of-day processing.

Most servers probably lose incoming data during end-of-day processing.
However, users generally aren't told about it and with most designs there
will be scattered losses of many ticks over a long period rather than total
loss for a few minutes.

> 3) Can you give us some specific targets regarding
>  availability of the charting module. While anxious to get
> started with TradeLab, I can handle the delays attendent
> with the shift in strategy. What I do need is a target so
> I can determine which projects to put on hold and which I
> should advance using current tools.

I will address that in a separate post, because there is a lot to explain,
discuss and show.

> Bob, I will be most happy to wait for a stand alone
> product. I see no advantage to having a 2D module right
> now for Omegas server, I have heard from two beta testers
> that the TS 5.0 is not Y2000 compliant anyway. Take your
> time and do it right, I'm on cloud nine just knowing that
> you are a client oriented person. Your efforts could be
> even classified as charitable! Thank you Bob!!

I don't know anything about TS 5.0 Y2K compliance, but I can assure you
TradeLab and the UMDS are both fully year 2000 compliant.  Not only is
TradeLab Y2K compliant, but a new ASCII data file Wizard even provides a way
to fix old two-digit year ASCII data files that are not.  I will explain
more about it in a separate post.  I also will post some Wizard screen
images, so you can better understand how it works.

Furthermore, if the TradeLab Omega Server interface and the UMDS interface
are used together to copy data from an Omega Server to a UMDS, the data
saved in the UMDS will be correctly dated and year 2000 compliant.

> I assume that there are some critical dependencies between
> the charting module and the server which are greatly
> affected by the significant changes which will be required
> to the server interface to accommodate UMDS. Just one
> example would be the methodology for editing bad ticks
> found on a chart. While equally as anxious to start
> working with TradeLab, even for EOD only, I would prefer
> to wait than to get a product which will require a major
> re-work to continue moving forward. I expect that some
> patience here will pay dividends in the near-term future.

That is an attitude others also have expressed.  We have felt a lot of
pressure to get the 2D Charting module released.  Almost all has been
pressure we have put on ourselves, rather than pressure from users who have
been surprisingly understanding.  We appreciate that understanding.  It
reaffirms our belief that most serious traders are a lot wiser than some
suppliers think.

We all want the best trading software possible.  With mutual understanding
and the flexibility for a little give and take here and there, that is what
we are going to have.

> I would VERY much like the 2D Charting module to be the
> NEXT product released. Am I the only one who would like
> to see 2D Charting released NEXT?????  Are there MAJOR
> problems getting 2D Charting finished or just flat-out
> not working on it because of the time spent working with
> the Universal Market Data Server Software?

We have been working every day on the 2D Charting module and related code
components.  Universal Market Data Server technical evaluation, contract
negotiation, and code changes to accommodate server technical requirements
have delayed that work and caused some rework, but those are only some of
the reasons the 2D Charting module was not released as soon as we had
estimated.

There are no major problems.  At least, not major in relation to the scope
of a project like TradeLab.  Just hundreds of thousands of lines of code to
write, test, debug, and sometimes rewrite because of problems discovered in
testing or because we think of a better way after using it a while.  I will
explain more fully in a separate post.

> I quess I'm missing something here. My question is, once
> the "TRADELAB COMPATIBLE" Universal Market Data Server is
> completed and released for use with TradeLab, WHAT WILL
> TRADELAB BE ABLE TO USE THE UNIVERSAL MARKET DATA SERVER
> FOR?
>
> I agree that the Universal Market Data Server is far
> superior to the Omega server, but again, WHAT WILL
> TRADELAB BE ABLE TO USE THE UNIVERSAL MARKET DATA SERVER
> FOR?

The UMDS has many technical and practical operational advantages compared to
the current Omega Server.  Judging from a high volume of mail about it, many
want to benefit from the advantages.  Those who don't can use an Omega
Server.  The UMDS is merely an option for those who prefer it.  It is not a
requirement.

Many advantages already have been mentioned.  Some of the more important are
(in no particular order of importance):

* It is much more reliable.

* It is compatible with more datafeeds, including the $99 per month DTN
service.

* You can switch datafeeds any time.

* Several other trading programs use it and it can serve data to TradeLab
and them concurrently.

* It is Year 2000 compliant.

* It is 32-bit software that can run in its own WinNT process space, so it
doesn't take resources from other application programs.

* It typically uses the CPU only 10 to 15 percent of the time, compared to
the nearly 100 percent usage of an Omega Server collecting less data.

* It doesn't have the Omega Server portfolio management problems.

* You will be able to import data into it.

* It was developed by a professional programmer who employed advanced
programming methods to achieve high performance.  The application
programming interface documentation is excellent.  That will be of no direct
concern to most users, but it reflects thoughtful design and it impresses me
, because the application programming interface documentation for most
products is awful.

* All the users we have talked to think it is great.

  -Bob Brickey
   Scientific Approaches
   sci@xxxxxxxxxx

--
  TC