Welcome to NexusFi: the best trading community on the planet, with over 150,000 members Sign Up Now for Free
Genuine reviews from real traders, not fake reviews from stealth vendors
Quality education from leading professional traders
We are a friendly, helpful, and positive community
We do not tolerate rude behavior, trolling, or vendors advertising in posts
We are here to help, just let us know what you need
You'll need to register in order to view the content of the threads and start contributing to our community. It's free for basic access, or support us by becoming an Elite Member -- see if you qualify for a discount below.
-- Big Mike, Site Administrator
(If you already have an account, login at the top of the page)
I am experiencing ongoing (over 2 months) Rithmic data latency issues. I'm currently doing an evaluation with Apex trader funding. At the open of RTH every day, the latency sometimes gets over 200,000ms. I've been in contact with Rithmic and Apex about the issues but there doesn't seem to be any solution thus far. Trading platform is Quantower. Here's what I've done from my end:
New CPU (i7 -7700k). The switch from my old CPU made no difference at all.
New SSD hard drive
Sync time zone regularly.
I have 100mbps internet connection with a 10ms ping.
Not running any superfluous programs. Only 2 charts and 1 indicator.
This has been driving me crazy lately. Would love to know if anyone can suggest a solution or has dealt with a similar issue.
Can you help answer these questions from other members on NexusFi?
Thanks for your reply. I'm in Korea and I've tried Chicago, Seoul, Tokyo, Singapore.
When it's working (outside of RTH and at less volatile times), Seoul seems to have the best ping.
At the current moment, I can't even log in to RTrader pro successfully on Chicago, or Seoul.
I have frequent connection/delay issues with them as well, including orders that are sent but not processed. Frustrating and dangerous. You're not alone.
200,000 ms delay is often a signal of server-side TCP buffering because the client is not consuming the data fast enough.
Check with Rithmic if you're receiving data from them via TCP transport. If so, consider ways to optimize this, e.g. significantly increase the size of your TCP receive buffer, or ensure no slow application logic is creating backpressure or blocking your dispatcher from reading off the TCP socket.
>>For example, for a connection that has a latency of 10 ms, the total achievable throughput is only 51 Mbps. This value is reasonable for a large corporate network infrastructure. However, by using autotuning to adjust the receive window, the connection can achieve the full line rate of a 1-Gbps connection.<<
>>To review the current settings, open a Command Prompt window and run the following command:
cmd
Firstly Ninja Trader is not fit for purpose, and neither is the rithmic data feed. I have had multiple order rejections and slow downs, failed orders, and positions that can not be exited. I passed this on to Apex and rithmic with no solution or answers.
I have videos of orders being rejected and positions stuck until exited for account stop loss being breeched.This has had on a few occasions and no solutions have been found. APEX seem to ignore the issue only once rectifying the problem.
Another issue is trading the open is practically impossible. Your orders will freeze and data feed will getting to a halt. This seems to Happen at the time the order is filled. Abd I assume its a messaging issue.
IF you have been having Rithmic data issues - read this and weep.
: Rithmic slowdown July 8, 2022
All times are US Central time on 08 Jul 2022.
Around 10:44 we began to receive reports from customers and users of our paper trading environment that traders could not get out of trades or log in.
At 11:55 we identified that programs running on a server that handles traffic between our Aurora center and our Chicago data center were unable to access additional memory.
At 14:48 we determined that that server had run out of memory and rebooted that server.
By 14:57 that machine had completed its reboot, all its programs recovered and all service was restored.
Some of our servers increase their memory consumption as the week moves from Sunday to Saturday.
Between 01 Jul and 05 Jul the volume of user traffic increased significantly.
Between the normal increase in memory usage as the week moves on and the noticeable increase in user traffic of the system, it seems that the server that handles the traffic between our Aurora data center and our Chicago data center reached its memory limit. As we generally configure our machines to have memory far in excess of its expected need, it is extremely unusual for any of our machines to ever run out of memory. Additionally the server that handles the traffic between these 2 data centers was not part of a redundant set which meant that a machine failure (out of memory is such a failure) could not be handled gracefully without an outage.
Over this coming week:
We will be increasing the amount of memory of this and other servers.
We will be watching memory consumption in real-time ready to take any of the following actions:
Reduce memory consumption of programs that show excess memory consumption (trim their excess memory usage);
Stop and start such programs if they consume excess memory quickly after they are trimmed;
Reboot the machine if its memory consumption approaches the limit of its installed memory.
We will also reconfigure our system, which may require us to purchase additional equipment, to have the traffic that moves between our Aurora and Chicago data centers transit across multiple redundant servers which will reduce or eliminate any downtime if a single server handling such traffic fails.
It might, and probably does. The quote from Rithmic has the server in question down from 10:44 to 14:57, over four hours. Given how many brokers use Rithmic for their live trades, I would expect this to have been an industry-wide disaster if live trading had been involved. But I don't believe this to have been the case (anyone who knows differently, please respond.)
Still, Rithmic should not have been vulnerable to this. It is basic in production systems to have redundancy and to not have a "single point of failure," where a system can go down because one component or link in the chain fails. They do mention that they "may" purchase additional equipment to prevent this failure in the future. I assume that "may" is actually "will," or that they will otherwise eliminate this weakness using existing equipment to provide redundancy. If not, it will bite them again at some point.
Bob.
When one door closes, another opens.
-- Cervantes, Don Quixote
