[ts-gen] Re: updateAccountTime event - args.timeStamp value

[orcwcbe at owlriver.com]

On Mon, 22 Jan 2007, Murali Varadachari wrote:

> Any idea why the event gives two different formats instead 
> of one consistent format?

As a wild ass guess, it is nothing more than different code, 
written for different purposes to support different 
requirements which IB or its customers have felt over time.

It is a nice attribute of the 'seconds since Epoch' date that 
it monotonically increases for all time intervals I am going 
to be trading in within the next few years [until 2034]; a 
nice attribute of a simple HH:MM date is that it is compact, 
and within the timeframe it is supposed to represent, capable 
of displaying with accuracy, the precision of the whatever the 
underlying datum is, but it cannot tell you what day it 
relates to.

I'll go through a recap of some design decisiojns we have made 
in our tool which works with the TWS.  We see several 
different time scales in our adjunct to to TWS, the 
'trading-shim' ( http://www.trading-shim.org/ ) -- Let me 
annotate and comment on a few data lines from last Tuesday's 
log might to illustrate how we (consciously) decided to 
address the matter of differing time horizons [each section is 
one detail line from our log file; I will intersperse 
commentary, marked by ***]:

Jan 16 09:45:46 centos-4 : shim|real|0.28|24510|35146| 
1027150|4|100|5|# |4|100|5|version|0.28|070105|

*** This is the startup banner message from a given run of 
that program.  It is running under *nix process ID: "|24510|"

Note the "|35146|", which is our counter of the number of 
seconds in the local TZ, since midnight; we choose to count 
from local midnight (rather than say from Unix Epoch), so that 
day to day comparisons are simplified, selecting on that 
field; we choose not to even carry the year in the detail 
lines of this datset.  The values to the left of the last 
colon are provided by the local logging unit; the content to 
the right of the last colon is provided by the trading shim

[herrold at couch ~]$ date -u -d ' 2007-01-16 35146 seconds' +"%Y-%m-%d %T %z"
2007-01-16 09:45:46 +0000

The "1027150|" is the number of microseconds since the program 
started up, left truncated and rolling every 20 seconds or so 
as I recall (we cannot use a monotonically increasing number, 
because there are too many microseconds in a day for 
convenient display -- 864,000,000,000 of them)

The particular version I am running is a release series 
"|0.28|" (a monotonically increasing number sequentially 
numbered) from a source tree issued sometime on the day 
"|070105|" [20]07-01-05 (where we have truncated the implicit 
century)  Again YYMMDD is a monotonically increasing number.

Jan 16 09:45:46 centos-4 : shim|real|0.28|24510|35146| 
1027257|1| 9|1|1|

*** We got the initialization handshake back from the TWS in a 
short interval:  1027257 - 1027150 = 107 microSeconds

[herrold at couch ~]$ echo "1027257 - 1027150" | bc
107
[herrold at couch ~]$

As this is a connection across a local lan from one client 
running the trading-shim, to a upstream server running an 
instance of the TWS, I am confident that I have very good 
network connectivity, and that the TWS is running 
responsively. ***

*** We download much data (several thousand rows) from our 
database, and validate its consistency, and then begin to emit 
transactions;  Again the (MySQL) database server is on yet 
another host from the client.  This takes a bit under a 
second:

[herrold at couch ~]$ echo "2000672 - 1027257" | bc
973415
[herrold at couch ~]$

***

Jan 16 09:45:46 centos-4 : shim|real|0.28|24510|35146| 
1307275|3|14|1|5|

*** We have a pacing sleep of one second in here to let the 
TWS stabilize.  We turn up verboseness of logging by the TWS, 
at 1.3 seconds into the process ["1307275|"]  ***

Jan 16 09:45:47 centos-4 : shim|real|0.28|24510|35147| 
2000672|3|10|3|1|5|3|

Jan 16 09:45:47 centos-4 : shim|real|0.28|24510|35147| 
2007957|3|10|3|2|166|7|

*** These send off a pair of requests: for Market Depth 
information on AIG.STK.SMART, and for some History on 
YM.FUT.ECBOT in two requests over 2007957 - 2000672 = 7285 uS 
(== 7.2 milliSecond) ***

Jan 16 09:45:47 centos-4 : shim|real|0.28|24510|35147| 
2068106|1|12|1|
  5| 0|0|1|   71.18|     1|bid|insert|STK.SMART.AIG.

Jan 16 09:45:47 centos-4 : shim|real|0.28|24510|35147| 
2429532|1|12|1|
  5| 0|0|1|    71.2|     4|bid|insert|STK.SMART.AIG.

Jan 16 09:45:47 centos-4 : shim|real|0.28|24510|35147| 
2429829|1|12|1|
  5| 2|2|1|   71.18|     1|bid|delete|STK.SMART.AIG.

*** and Market Depth data started flowing back to the end 
client in 67.434 mS

[herrold at couch ~]$ echo "2068106 - 2000672 " | bc
67434
[herrold at couch ~]$

Note: this is a round trip from the client, through the local 
TWS, to IB, getting a datastrean validated, authorized, and 
flowing, back to the local TWS, and back to the client -- This 
is _blazingly fast_!! Java and C++ are what the TWS and the 
trading shim are implemented in, and each really flies.***

The point of going through these timeings is to point out that 
a second is a very long time in the capacity profile of 
computers; We accomodate time scales from centuries, days, 
seconds, and down to microSeconds with the trading shim, by 
prior design, as one of our design goals has been from the 
start:
 	"We ... focus on design for scalability to hundreds of
 	simultaneous lines of inquiry into the ECN markets."


That said, let me do a short advert.  The trading shim is a 
C++ tool, which provides a command-line and dbms controlled 
interface to the socket-based TWS API.  It is licensed for 
free use under the GPL.  Our mailing list is similarly free 
for subscription at:
 	http://www.trading-shim.org/mailman/
A person interested in the progress of the tool might study 
our NEWS file:
 	http://www.trading-shim.org/capitals/?NEWS

If you'rre still with me, thank you for your interest; we 
welcome feedback and comment. Come join the fun.

-- info at trading-shim.com
  	Russ and Bill