Support Board
Date/Time: Tue, 26 Nov 2024 01:37:52 +0000
Post From: Version 1047: Millisecond time stamping
| [2013-11-27 20:08:17] |
| jesslinn - Posts: 108 |
|
I was going off the 8 byte time that appears in the SCID files, which has enough room for 300 years of nanoseconds, when I suggested keeping the exchange milliseconds and incrementing in microseconds, but you may use something besides 8 bytes internally. Certainly there are issues and cost in any case. Your mechanism for adding a millisecond as a sequence number is better than nothing. At least it keeps time marching forward which can be nice. The issue really is trying to maintain order between ticks for different instruments. Wouldn't it be nice, for example, to be able to notice that every time a 2000 share or larger ask is put up on ARCA that a 100 share up-bid on ISLAND appears 10 msec later. Detecting such automated strategies is interesting to some of us and is not possible without millisecond time stamps. Exchanges are improving their timestamps and some of your competitors are responding. We are just letting you know that some or your customers would find value in a solution. Just because we are not competing with HFTs does not mean that it is not useful to monitor the very delays that ganz mentioned. Wouldn't you like to know if you get your ticks 600 msec faster from one vendor than another or even more important, that a particular tick is greatly delayed from the average from a given vendor. This is not possible without keeping millisecond timestamps since all of the delays normally add to less than a second. |