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)
Anyone running CQG on a steadfast box and seeing periodic problems?
I'm running Multicharts 8 w/ CQG and am experiencing time outs per the logs that are shutting down the CQG datafeed without warning. Running a ping to the CQG servers in the command line shows consistent sub 1MS pings while the CQG API continues to print warnings about latency.
Last night was the 3rd time in the last 4 weeks I've lost the datafeed while in trades. I was actively RDP'd into the box when the feed stopped, so I know the box never lost full connectivity. Luckily its been in slow markets to date, but I fear getting caught in a fast market.
Would love to hear feedback of other members who may have seen similar issues. My setup is relatively new - I've only been running for 3 months.
Neither CQG or Multicharts support has been able to provide any answers other than suggesting that my box is losing connectivity.
Can you help answer these questions from other members on NexusFi?
I'm also running on Steadfast with MC/CQG and I looked in my logs and found the following:
Looks like I'm also having delays that I wasn't aware of. So far I haven't had CQG go belly up on me but I'd really hate to be delayed for 8 seconds in fast moving market...
Interesting, that is the exact time my logs show the long pings:
WARN [2012-10-02 08:13:39,561] - NETS: [01] A1001: ping reply is being delayed for 16240 ms
WARN [2012-10-02 08:13:55,832] - NETS: [01] A1001: ping reply is being delayed for 32510 ms
WARN [2012-10-02 08:14:28,358] - NETS: [01] A1001: ping reply is being delayed for 65035 ms
WARN [2012-10-02 08:15:33,410] - NETS: [01] A1001: ping reply is being delayed for 130085 ms
WARN [2012-10-02 08:17:43,499] - NETS: [01] A1001: ping reply is being delayed for 260171 ms
INFO [2012-10-02 08:20:52,696] - ASLU: ReportClientActivity(140877,*****) method calling at auth service
INFO [2012-10-02 08:20:52,712] - ASLU: ReportClientActivity method at returned request status: Success
WARN [2012-10-02 08:22:03,692] - NETS: [01] A1001: ping reply is being delayed for 520358 ms
WARN [2012-10-02 08:24:05,949] - NETS: [01] SUBS2(811ff002-edfc-4d84-83ee-0e2aea8c6d1d - Subsystem #02)-pro: subsystem is slow or hung: no response to test message for 1029 msec, queue: 32 bytes
WARN [2012-10-02 08:24:06,979] - NETS: [01] SUBS2(811ff002-edfc-4d84-83ee-0e2aea8c6d1d - Subsystem #02)-pro: subsystem is slow or hung: no response to test message for 2059 msec, queue: 64 bytes
WARN [2012-10-02 08:24:09,022] - NETS: [01] SUBS2(811ff002-edfc-4d84-83ee-0e2aea8c6d1d - Subsystem #02)-pro: subsystem is slow or hung: no response to test message for 4102 msec, queue: 304 bytes
WARN [2012-10-02 08:24:13,078] - NETS: [01] SUBS2(811ff002-edfc-4d84-83ee-0e2aea8c6d1d - Subsystem #02)-pro: subsystem is slow or hung: no response to test message for 8158 msec, queue: 432 bytes
WARN [2012-10-02 08:24:20,753] - NETS: [01] SUBS2(811ff002-edfc-4d84-83ee-0e2aea8c6d1d - Subsystem #02)-pro: subsystem is slow or overloaded: core->subsystem message delivery took 15845 msec, queue: 1008 bytes
WARN [2012-10-02 08:24:20,753] - NETS: [01] SUBS2(811ff002-edfc-4d84-83ee-0e2aea8c6d1d - Subsystem #02)-pro: subsystem is slow or overloaded: core->subsystem message delivery took 7686 msec, queue: 576 bytes
WARN [2012-10-02 08:24:20,753] - NETS: [01] SUBS2(811ff002-edfc-4d84-83ee-0e2aea8c6d1d - Subsystem #02)-pro: subsystem is slow or overloaded: core->subsystem message delivery took 3584 msec, queue: 272 bytes
WARN [2012-10-02 08:24:20,753] - NETS: [01] SUBS2(811ff002-edfc-4d84-83ee-0e2aea8c6d1d - Subsystem #02)-pro: subsystem is slow or overloaded: core->subsystem message delivery took 1525 msec, queue: 32 bytes
WARN [2012-10-02 08:30:44,062] - NETS: [01] A1001: ping reply is being delayed for 1040717 ms
ERROR [2012-10-02 08:30:44,062] - NETS: [01] A1001: pings are not answered, stopping pinging
17 minutes later is when the datafeed cut out entirely. So the question is was it Steadfast or CQG? Curious if anyone not on Steadfast has logs from the same time (timestamps are weird - it actually corresponds to around 3AM CST this morning)?
Curious to hear from any CQG/Multicharts users outside of Steadfast. Any issues or suspicious log entries around 3AM CST?
You'd know for sure if you went down - requires a restart to get reconnected. Looks like I went down while Nick did not even though we both suffered similar issues.
They have few facilities in Chicago, chi01/chi02/chi18, so if you have equipments hosted by them, you know where they are (which facility, row & rack, switches ports used, ...).
Maybe both of you were in chi01/chi02, but they didn't talk about any network issue today, so I think it's on CQG side.
When I ping CQG servers it's taking about 27ms when it should be sub 1ms.
Here is a tracert
Steadfast is aware of the problem and is trying to engineer around it. They have been very responsive and helpful on this issue I just hope they can solve it quickly.
Here is what they said:
I'm definitely not happy paying for a server in Chicago and my traffic is whizzing by my house in Colorado to Dallas and back to Chicago... but I'm hopeful steadfast will fix this soon. I'm curious if others on chi18 are having the same issue.