@syswizard No, you can definitely encounter same timestamps in a ticker tape. Right now the granularity of the data is millisecond. However, with upcoming changes in CTA and UTP SIP feeds, the granularity will move to nanoseconds.
Yes, but I wonder if that is because you are only at the millisecond level ? Since there are 1 million nanoseconds per millisecond, could there be 2 separate trades posted on the exchange's server with the same nanosecond timestamp ? I find that hard to believe.
@syswizard That's a good question. Current SIP data feeds only provide millisecond resolution, we see a lot of prints on same millisecond for active symbols such as SPY or QQQ. Here's a small snapshot from this morning's session for SPY, you can see how often the 766000 millisecond repeats (it's formatted as microsecond timestamp). It will be very interesting to see how the timestamp will look like once industry moves to nanosecond resolution, whether there will be any duplicate timestamps then. id,timestamp,price,size,exchange,cond1,cond2,cond3,cond4 T,201507104441737000,206.590000,149,J,0,0,0,0 T,201507104441737000,206.590000,100,Z,0,0,14,0 T,201507104441737000,206.590000,100,Z,0,0,14,0 T,201507104441737000,206.590000,47,Z,37,0,14,0 T,201507104441737000,206.590000,100,B,0,0,0,0 T,201507104441737000,206.590000,5,B,37,0,0,0 T,201507104441737000,206.590000,18,B,37,0,0,0 T,201507104441737000,206.590000,82,B,37,0,0,0 T,201507104441737000,206.590000,3,B,37,0,0,0 T,201507104441738000,206.590000,100,K,0,0,0,0 T,201507104441738000,206.590000,100,K,0,0,0,0 T,201507104441738000,206.590000,72,K,37,0,0,0 T,201507104441738000,206.590000,28,K,37,0,0,0 T,201507104442251000,206.590000,100,P,0,0,0,0 T,201507104443327000,206.600000,500,Z,0,0,14,0 T,201507104443327000,206.600000,100,T,0,0,0,0 T,201507104443327000,206.600000,300,Z,0,0,0,0 T,201507104443327000,206.600000,200,Z,0,0,0,0 T,201507104443327000,206.600000,200,Z,0,0,0,0 T,201507104443601000,206.600000,27,J,37,0,0,0 T,201507104444766000,206.600000,200,P,0,0,14,0 T,201507104444766000,206.600000,400,P,0,0,14,0 T,201507104444766000,206.600000,100,P,0,0,14,0 T,201507104444766000,206.600000,100,P,0,0,14,0 T,201507104444766000,206.600000,100,P,0,0,14,0 T,201507104444766000,206.600000,200,P,0,0,14,0 T,201507104444766000,206.600000,100,P,0,0,14,0 T,201507104444766000,206.600000,200,X,0,0,0,0 T,201507104444766000,206.600000,200,P,0,0,14,0 T,201507104444766000,206.600000,100,P,0,0,14,0 T,201507104444766000,206.600000,200,X,0,0,0,0 T,201507104444766000,206.600000,800,T,0,0,0,0 T,201507104444766000,206.600000,200,Z,0,0,0,0 T,201507104444766000,206.600000,495,P,0,0,14,0 T,201507104444766000,206.600000,200,T,0,0,0,0 T,201507104444766000,206.600000,600,T,0,0,0,0 T,201507104444766000,206.600000,100,K,0,0,0,0 T,201507104444766000,206.600000,100,T,0,0,0,0 T,201507104444766000,206.600000,100,Z,0,0,0,0 T,201507104444766000,206.600000,500,T,0,0,0,0 T,201507104444767000,206.600000,100,Z,0,0,0,0 T,201507104444767000,206.600000,200,T,0,0,0,0 T,201507104444767000,206.600000,100,T,0,0,0,0 T,201507104444767000,206.600000,200,T,0,0,0,0 T,201507104444767000,206.600000,200,T,0,0,0,0 T,201507104444767000,206.600000,200,T,0,0,0,0 T,201507104444767000,206.600000,100,T,0,0,0,0 T,201507104444767000,206.600000,100,T,0,0,0,0 T,201507104444767000,206.600000,100,T,0,0,0,0 T,201507104444768000,206.590000,100,B,0,0,14,0 T,201507104444768000,206.590000,200,Z,0,0,0,0 T,201507104444768000,206.590000,200,Z,0,0,0,0 T,201507104444770000,206.590000,100,P,0,0,0,0 T,201507104444770000,206.590000,100,P,0,0,0,0 T,201507104444770000,206.590000,100,P,0,0,0,0 T,201507104444770000,206.590000,300,P,0,0,0,0 T,201507104444770000,206.590000,100,P,0,0,0,0 T,201507104444776000,206.595000,100,D,0,0,0,0 T,201507104444776000,206.590000,28,P,37,0,0,0 T,201507104444776000,206.590000,28,P,37,0,0,0 T,201507104444777000,206.590000,50,P,37,0,0,0
Hi @activetick, I found the atfeed http server is taking about 98% CPU usage of my mac osx when it is running as a background process. However, It is normally 1-2% when the http server is executed in a bash shell. Is there anything I could do to to solve this issue?
@hardywu ActiveTickHttpServer prints out status messages to console, and also uses std::cin to read from console for command processing. If you send the process to background, this read/write console activity causes high cpu usage with kernel. A workaround for this, would be if you use a screen utility. Screen utility acts as a background shell in which you can launch your process, and detach from it. You can also attach to it later. All console input and output is accessible from screen. To do this, try: 1. create a new screen instance, run: screen -S ActiveTickHttpServer (this will launch a new instance of the screen) 2. go to where ActiveTickHttpServer binary is located, and launch like you would using regular bash 3. detach from screen by pressing ctrl+a+d 4. to attach to your screen, type screen -x ActiveTickHttpServer Here's some background on screen utility: http://ss64.com/osx/screen.html
@activetick Thank you for this workaround. It seems to be the best option besides writing a new http server oneself.
Hi, @activetick , I came cross with the issue of running the sample codes of C++ api. Could you point out how could I correct the error? Code: ATInitAPI(); ... APISession session; Requestor requestor(session); cout << "session id: " << session.GetSessionHandle() << endl; Streamer streamer(session); cout << "session id: " << session.GetSessionHandle() << endl; .... ATGUID guidApiUserid = Helper::StringToATGuid(apiUserid); bool rc = session.Init(guidApiUserid, serverIpAddress, serverPort, &Helper::ConvertString(userid).front(), &Helper::ConvertString(password).front()); The error log shows Code: session id: 140225461354848 session id: 140225461359424 Segmentation fault: 11 And I can locate the error to the Code: Streamer (ActiveTickStreamListener) which seems to change the value of session Code: session.GetSessionHandle() .