Ii seems it's an ISP issue, but from what I see, from different IP sources (so different routes are taken), the last ISP before CQG servers is always Qwest. Maybe they only have one ISP, which is not, at least now, a good one ?
Usually in trading, those who know don't talk, and those who talk don't know. (Al Brooks)
success requires no deodorant! (Sun Tzu)
The following 3 users say Thank You to sam028 for this post:
It is understandable. Thank you and the team for the efforts to solve this issue too.
Sorry to ask again, if NT will not report lost connection, will the user somehow know about delayed/filtered/packaged connection state?
Will the mentioned ignorance of slow connection state affect only CQG-based connections, or others too?
Would be there an option within NT to return the strict use of the connection state?
- User will not know if slow, I would not equate slow to meaning delayed or filtered, please keep this in mind that slow in our experience is far and few between and when it happens it returns to normal in seconds, its a temporary state
- The quality of your internet connection to the trading servers is not CQG specific and can effect all electronic trading providers
- No option to return to strict use of connection state
The following 2 users say Thank You to NinjaTrader for this post:
I am going to move from CQG back to rithmic. I can live without server side OCO. Even if NT fixes the disconnect sensitivity there does seem to be some system wide issue with the route that has nothing to do with NT. There are times one hop is over 100ms and I am sitting on a server in Chicago. I may not be able to report back because I think I am going to try and get in Aurora CME Data center as well as move to rithmic (I can report on how that goes but won't help those still on CQG). Will cost more than what I am doing now but less hops means less issues and even lower latency. Should pay for itself.
I will say my experience with CQG feed has basically stunk. No other way to say it. Whose fault who knows? It's not ready for primetime imo and has cost me valuable ticks.
"The day I became a winning trader was the day it became boring. Daily losses no longer bother me and daily wins no longer excited me. Took years of pain and busting a few accounts before finally got my mind right. I survived the darkness within and now just chillax and let my black box do the work."
The following user says Thank You to liquidcci for this post:
Platform: "I trade, therefore, I AM!"; Theme Song: "Atomic Dog!"
Favorite Futures: EMD, 6J, ZB
Posts: 798 since Oct 2009
Thanks: 216 given,
trace route command shows how many hops, pings and dinks inbetween the client pc and the host receiving server,
those collectively when added together are latency
slow in this context means bandwidth issues, clogged pipes, bursts of data exceeding the mean average capacity of the outbound pipes from the data server to the entire populace of subscribers
slow also has much to do with one's ISP SLA and in-bound speeds.
slow also has much to do with one's CPU, motherboard and chipset, operating system HDD / SSD and other active processes running on the platform at the time "it (slowness)" is observed
futures.io (formerly BMT) has a thread regarding speeding up one's platform, whether using Ninja, or any other trading application. In essence the suggestion is to initially increase to maximum one's DRAM slots; implement some sort of VRAM / Ramdisk; allocate priority to your trading architecture through your QOS Router features and de-prioritize everything else.
Eddie and his crew at EZTradingComputers.com are some awesome guys that have really run the gambit on this issue and can take this conversation further, provided one's glasses stop fogging over from the details...
good trading to us all!
The following user says Thank You to kronie for this post: