represented by a record of (1) the market, (2) the price, (3) the volume, and (4) the time, leaving out the time stamp can render a considerable savings in the space it would otherwise consume in the datafeed.

Most data providers broadcast a "current market time" on a periodic basis in the datafeed, typically every minute. Ordinarily, trading applications interpreting the datafeed set their "current time" based on this data. To gain access to the greater granularity of time increments than one minute, the trading application will typically set the computers internal clock according to the value received from the datafeed. This setting could occur each time the "market time" is received, but more typically it is set either when the program is booted or on a daily basis. With the users own computer clock thereby synchronized with the datafeeds reported market time, reading the clock on receipt of each trade and using that value for the time stamp of the trade, gives a crude (but best) approximation of the time that the trade actually occurred.

However, leaving it up to the users application software to record the time stamp is by no means without its problems. First, some computer trivia. Computers have two clocks. They have a hardware clock that runs all the time, even when your computer power is switched off. They also have a software clock that runs only when the operating system (e.g., UNIX, DOS, Win95, WinNT, OS/2) is running. When the operating system, or "O/S," first starts, it initializes its internal software clock to match hardware clock time. Software clock initialization only has effect until the O/S is restarted. If you change the software clock time and then restart the operating system, the software clock time will be set back to hardware clock time.

Regarding the potential problems, it is obvious that if datafeed transmissions are late, the computer clock will be set wrong. If the users computer is not synchronized with the true market time, the time of each trade will be misrecorded, causing even bigger problems with respect to the value of subsequent analysis. Even if the users computer is correctly synchronized with the time of the market, data delays, especially in fast markets, mean that there can be some variance between the true time of the trade and the time it is delivered for recording at the users site, even under ideal conditions.

A sometimes-confusing phenomenon occurs when your incoming data shows a time on your charting software that is different than the time shown by the computer operating system. This could happen when your data server is setting and reading the hardware clock while your O/S is reading the software clock. This has confused many users as they sit watching two different clock times on their computer screen.

Some software datafeed servers will ignore the "seconds" information in the time-of-day packets. This makes it impossible to create time-bars lasting less than 1 minute each.

Questions to Ask

Does the server software update the computers hardware of software clock? Does the server time-stamp data packets using the hardware or software clock? Does the server include the "seconds" information when time-stamping a quote?

Buffer Overflow

There are two main causes of data loss or dropout at the receiver end: buffer overflow and signal corruption. You need to know when this occurring and why, otherwise youll be trading merrily away without knowing what the market is really doing.

Assuming your receiver is picking up 100 percent of the data, your computer might fail to process it all simply because it is receiving more data than it can handle. Your receiver box and software package may not be designed to select (filter) from the enormous data throughput only those instruments you want to enter your symbol portfolio. Consequently, your computers I/O buffer may get overwhelmed and new data will then simply have nowhere to go. They get dropped until the buffer empties out.

Computer manufacturers now implement a fast I/O chip (16550) for the COM port. This is generally fast enough for most purposes; however, if an overflow error occurred in the 16550 and the software properly triggered the "reset" flag, the port erroneously does not clear the flag. This would result in considerable lost data (a classic hardware bug). To work around this bug, some software products will set and then clear the flag when this error occurs. Even so, it is better to avoid overflowing the buffer altogether.

To lower the chances of buffer overflow, try a vendor that enables data filtering in the receiver box. Also, shut off news monitoring if you do not really need it. Shut off exchanges you are not interested in.

Another way to address the problem is to speed up I/O throughput. To do so, you need special hardware and software to replace the COM port on all computers. Some vendors, like FutureSource, have their own plug-in board so you dont need to use your computers port. If that is not available, try a vendor whose receiver has a built-in buffer, and as far as buffers go, bigger is better. For example, DBC Signals Plus box has a built-in buffer that can hold about 16K bytes.

More powerful buffering methods include installing T/Link software and a T/Port board. The T/Port has 16K bytes of input buffer whereas the modern 16650 so-called high-speed COM port has only 16 bytes. So the T/Port has 1,000 times the input buffer size of the modern 16650. T/Port and T/Link are available from Telcor Ltd (phone: 441-238-4970).

Even if your I/O is very fast, you can still lose data if your computer is too slow to handle the average data throughput. Eventually the T/Port buffer will overflow and you are still with the same problem. The T/Link software expands the 16K buffer to essentially unlimited size by using 200K of RAM and if that overflows it is sent to your hard disk.

Still, you need data on screen in a timely manner, not just buffered somewhere. Therefore, your computer needs to be fast, too. Speeding up your main processor means getting a fast Pentium, AMD, or Cyrix processor. A top-quality graphics board will also help prevent delays by updating screens very quickly.

Questions to Ask

When buffer overflow occurs, does the server software set and clear the "reset" flag in 16550 I/O chip?

Is the datafeed server compatible with Telcors T/Link software and T/Port hardware?

Can you afford to buy a top-quality graphics board? Bad Packets

A bad packet is a data packet that was received, but the data contained is only partially correct, due to signal corruption caused by a weak signal somewhere between the vendor and your computer.

To verify you are getting bad packets, most software provided by vendors offer a bad packet counter that you could inspect periodically. If the bad packet count is incrementing higher, you have the problem. The better products should distinguish between two types of error: dropout (some bytes were lost in a packet) and CRC error (some bytes values were corrupted). Some software charting products, like WINdoTRADEr, can do both.

In addition, your black box may unlock, from time to time, due to a weak or corrupted signal, or dirty cable connectors. All data reception is lost until the box regains a lock on the incoming signal.

Here are some potential remedies. Tighten all cable connectors. Verify your satellite dish is aimed properly. Get a larger dish. Reorient the dish. Spray a lubricant or wax over the dish to prevent snow buildup, make sure your satellite dish LNB has a noise figure no higher than 0.8dB. If not, get one with a lower noise rating. The LNB is a Low-Noise Block downconvertor, the electronic gizmo positioned by the three-strut support at the focal point of the dish. It detects, amplifies, and downconverts (shifts from GHz frequency down to MHz frequency), making the signal less vulnerable to noise and attenuation in the cable.

At times, the vendor may be the cause of bad packets, typically the result of power outages, crashed computer hard drives, and numerous other technical failures. According to Murphys Law, the datafeed always seems to go down at the worst possible moment in your trading.

Questions to Ask

Does the receiver or software have a bad packet counter?

Does the receiver or software have a means of alerting the trader when excessive bad packets occur?

Can you swap a small dish for a larger one and pay only the difference in cost?