UPA Market Price trade data precision and latency

aross

Good morning,

I'm processing the MarketPrice Domain messages from UPA to get up-to-date market volumes for all symbols. I am using the "TRADE TIME" field to get the timestamps for ticks that I recieve. I noticed that the timestamps from messages with tick information are spaced exactly every 3 seconds. Additionally, I noticed that our system is receiving these messages on average 25 seconds and up to 70 seconds after the trade time.

1.) The trade timestamps are spaced exactly every 3 seconds. Should I expect to receive an update for every trade on this feed or is it consolidated?

2.) Is the "TRADE TIME" the most accurate field to be using to determine when the trade was executed on the market? Is there a different timestamp field that I should be using to get more precise timestamps?

3.) Is there a different data source or domain that I can use to get better latency and/or less consolidation on the trade data? Are there other parameters I can set to request more up to date data?

4.) Is 30 seconds of latency expected when receiving data from the UPA feed from the Market Price Domain?

Here is an example of how I am requesting market price data from UPA. I am setting the qos.rate field to tick-by-tick and the qos.timeliness field to realtime.

    RsslEncodeIterator encode_iterator = RSSL_INIT_ENCODE_ITERATOR;
    RsslBuffer rssl_buffer = RSSL_INIT_BUFFER;
    rssl_buffer.data = (char *) nsm_rssl_header->payload;
    rssl_buffer.length = NSM_PAYLOAD_SIZE - sizeof(struct nsm_rssl_data_header);
 
    RsslRequestMsg mkt_price_req = RSSL_INIT_REQUEST_MSG;
    mkt_price_req.msgBase.domainType = RSSL_DMT_MARKET_PRICE;
    mkt_price_req.msgBase.msgClass = RSSL_MC_REQUEST;
    mkt_price_req.flags = RSSL_RQMF_STREAMING | RSSL_RQMF_MSG_KEY_IN_UPDATES | RSSL_RQMF_HAS_QOS | RSSL_RQMF_HAS_PRIORITY;
    mkt_price_req.msgBase.containerType = RSSL_DT_NO_DATA;
    mkt_price_req.msgBase.streamId = data->stream_id;
    mkt_price_req.qos.dynamic = RSSL_FALSE;
    mkt_price_req.qos.rate = RSSL_QOS_RATE_TICK_BY_TICK;
    mkt_price_req.qos.timeliness = RSSL_QOS_TIME_REALTIME;

    RsslMsgKey *msg_key = (RsslMsgKey *) rsslGetMsgKey((RsslMsg *) &mkt_price_req);
    if (msg_key == NULL) {
        log_error(HPR_DARKHOLD, "%s(): Unable to get message key!", __func__);
        return DARKHOLD_DRV_APP_FAILURE;
    }

    msg_key->flags = RSSL_MKF_HAS_NAME | RSSL_MKF_HAS_NAME_TYPE | RSSL_MKF_HAS_SERVICE_ID;
    msg_key->serviceId = upa_ctrl->directories[upa_ctrl->directory_idx].service_id;
    msg_key->nameType = RDM_INSTRUMENT_NAME_TYPE_RIC;
    msg_key->name.data = data->name;
    msg_key->name.length = strnlen(data->name, DARKHOLD_SYMBOL_LEN);

    enum darkhold_internal_rc rc = rssl_initiate_encode(&upa_ctrl->rssl_channel, &encode_iterator, (RsslMsg *) &mkt_price_req, &rssl_buffer);
    if (rc < DARKHOLD_INTERNAL_RC_SUCCESS) {
        log_error(HPR_DARKHOLD, "%s(): Unable to initiate encoding of market price request. rc %d", __func__, rc);
        return DARKHOLD_DRV_APP_FAILURE;
    }

    RsslRet encode_rc = rsslEncodeMsgComplete(&encode_iterator, RSSL_TRUE);
    if (encode_rc < RSSL_RET_SUCCESS) {
        log_error(HPR_DARKHOLD, "%s(): Unable to complete market price request message encoding. rc %d", __func__, encode_rc);
        return DARKHOLD_DRV_APP_FAILURE;
    }

Gurpreet

Hello @aross

What source are you getting this data from - RTO Cloud or the deployed RTMDS? 3 seconds for trade messages seems to be a fixed rate conflated feed. In addition 30 seconds delay is unheard of. For real time feeds, depending on the where the app is colocated, the latency should be in the milliseconds range.

Regarding the trade time stamp - you can use fields which provide granular time information like SALTIM_MS etc.

Jirapongse

@aross

I reviewed the raw historical data for 000001.SZ and observed that the gap between SALTIM_MS values is consistently 3 seconds

I got the same results when using the Quote app on the LSEG Workspace.

You need to contact the content support team directly via LSEG Support to verify this.

Please include the URL of this discussion in your raised question to prevent it from being redirected back to this Q&A forum.