Support Board
Date/Time: Tue, 03 Nov 2026 16:44:33 +0000
Real-time NQ/MNQ data fell minutes behind on Rithmic Direct - DTC (2 Nov 2026)
View Count: 26
| [2026-11-03 14:30:08] |
| ARBOMONT JEAN-CHRISTIAN - Posts: 4 |
|
Hello, On 2 November 2026, real-time NQZ6.CME and MNQZ6.CME data in Sierra Chart fell several minutes behind the market. I would like help finding out whether the delay arose before the data reached Sierra Chart or inside Sierra Chart. Setup: - Sierra Chart 2913, 64-bit, Windows 11 - Service: Rithmic Direct - DTC - Server on 2 Nov: Rithmic Paper Trading - Chicago Area - Non-Aggregated - Location: United Arab Emirates, ping to rsc.rithmic.com about 214 ms Timeline (UTC): - 14:53-14:54: NQ and MNQ history downloads current - 15:22: real-time delay about 371 s - 15:34: about 403 s - 15:38: about 492 s on MNQ, then back to 3-18 s after all Sierra Chart sockets were replaced. I do not know what caused that reconnection. - 16:04: about 111 s with the same sockets. TradingView, which does not use Rithmic, was showing the current minute. - 16:13-16:21: about 2-11 s, with no reconnection - 16:21-16:25: rising again to a peak of 87 s, with no reconnection How I measured it: true UTC minus the timestamp of the last record in the .scid file, with the PC clock corrected against time.windows.com. The file is written about every 5 s, so readings of only a few seconds are not meaningful. Local checks during the delay: total CPU 32%, 15.6 GB of RAM free, Sierra Chart primary thread at 73.5% of one core, Wi-Fi signal 100%, 135 TCP retransmissions out of about 205,000 segments, no loss on ping. Since 3 Nov I have been using the Chicago Area - Aggregated server, which I selected myself. In a quiet market the delay is 0.5-2.5 s right after each file write, but I have not yet tested it during the US session. Data also stopped at 00:03 UTC on 3 Nov because my license expired, which I consider unrelated. Questions: 1. Do the attached logs show whether the data was arriving late from Rithmic, or whether it was queuing inside Sierra Chart? 2. Could Non-Aggregated data, my chartbook or my custom studies cause a backlog like this, with the primary thread at about 73%? 3. If it happens again, what should I check or capture while it is occurring to identify the source? 4. Would testing with a different data feed help isolate the cause, and if so, which one do you recommend for my account? Attached: Message Log, evidence report, and lag measurements (CSV). Thank you. |
Private File Private File Private File |
| [2026-11-03 15:34:53] |
| John - SC Support - Posts: 48402 |
|
You can not look at the data in the .scid file, as that is not valid. Not to mention that you are not allowed to access the data in the .scid files. Refer to the following for why you can not access the files directly: Sierra Chart License Agreement: DATA LICENSE You need to look at the "Data Delay" value that is shown in the Chart Header. It has a prefix of "DD:" when displayed. Refer to the following for how to add this to the Chart Header or move it so it is visible: Working With Charts: Region Data Line / Chart Header The Data Delay that shows in that item is the difference in the timestamp of the most recently received data against the time of your computer. Therefore, in order for this to be comparable, you do need to ensure that your computer clock is synchronized to a national standard, as that is the time that is used by the exchange. There definitely not an issue with the processing of data within Sierra Chart. So any delays you see would be to your Internet connection, your distance from the exchange, or the provider of the data (Rithmic in this case). For the most reliable, advanced, and zero cost futures order routing, use the Teton service: Sierra Chart Teton Futures Order Routing |
To post a message in this thread, you need to log in with your Sierra Chart account: