DavZim / RITCH

An R interface to the ITCH Protocol
https://davzim.github.io/RITCH/
Other
18 stars 5 forks source link

timestamp #11

Closed macdeutsche closed 5 years ago

macdeutsche commented 5 years ago

Hi David I have questions. In your messagetypes.cpp, what's the meaning of unsigned long long int get6bytes(unsigned char buf) { return (__builtin_bswap64(reinterpret_cast<uint64_t*>(&buf[0])) & 0xFFFFFFFFFFFF0000) >> 16;

This is used to get 6 bytes for the timestamp.

But I am still working on the itch 4.1 and 4.0 file, but timestamp is 4 bytes. So I used unsigned long long int get6bytes(unsigned char buf) { return (__builtin_bswap32(reinterpret_cast<uint32_t*>(&buf[0])) & 0xFFFFFFFFFFFF0000) >> 16; }

I know it's not 6bytes, but retained the name for convenience.

What do "0xFFFFFFFFFFFF0000" and ">>16" do? Does __builtin_bswap64 return 8 bytes or 6 bytes? How about __builtin_bswap32? does it return 4 bytes?

DavZim commented 5 years ago

The getXbytes functions retrieve X bytes from the buffer and converts them from big endian to little endian. If you use want to retrieve 4 instead of 6 bytes, you can use the get4bytes.

The & and the >> are bitwise operations. The documentation for the __builtin_bswapXX functions, can be found here. Both functions swap X bytes. The getXbytes function should suffice in your case.

macdeutsche commented 5 years ago

appreciate it. I have attached the working 4.1 file. Worked OK so far, except that ITCH is supposed to be in nano second. So I was assuming that the timestamp is nanosecond.

But it looks like it's millisecond. That's why I am examining whether timestamp was correctly read in the file.

So __builtin_bswap32 converts 32bit to 4 bytes. __builtin_bswap64 converts 64 bit to 8 bytes. You used this in both get6bytes and get8bytes.

I was thinking given that timestamp in itch 5.0 is 6 bytes, you are somehow converting 8byte reading into 6 byte using "0xFFFFFFFFFFFF0000" and ">>16".

RITCH-4.1.zip

DavZim commented 5 years ago

The documentation of the 4.1 protocol mentions only nanoseconds afaik. The buf[0] & 0xFFFFFFFFFFFF0000 >> 16 part disregards the last 2 bytes of the 8 byte/64 bit value, thus effectively reducing it from an 8 byte value to a 6 byte.

macdeutsche commented 5 years ago

Yeah, that's where I am stuck. For example, if I look at "P" (non-cross trade), the only information is timestamp-nanoseconds, Nanoseconds portion of the timestamp. If this is true, I don't know how to sort the trade, since I am missing second. Msgtype "T" says it has seconds, but it's difficult to understand what they meant. I am not sure. maybe I should dig in further on how this "T" message data looks like. Would it require merging? not sure. Even if it requires merging, I don't know how to match (match with what?) And on top of it, in count message in R, no "T" was pulled.

BTW, there are some ITCH 4.1 on nasdaq, my coauthor asked for the data. It's only for 5 days.