Support Board
Date/Time: Wed, 27 Nov 2024 02:30:37 +0000
CTS disconnections
View Count: 1814
| [2014-07-14 17:55:12] |
| T44 - Posts: 363 |
|
CTS support have asked me to use the T4 desktop application and leave it logged in to see if I am still getting the disconnections. They have asked me to check with you that Sierra Chart is set up correctly. My FCM has confirmed that no other CTS customers are reporting issues. Would it be possible for you to work directly with CTS support to resolve this issue? I cannot determine whether this is a CTS or Sierra issue, or a problem with my hardware/connection. |
| [2014-07-14 18:26:32] |
| |
|
There is nothing in Sierra Chart you can do setup wise which would cause this problem. So Sierra Chart is definitely set up correctly. The probability of it being an issue within Sierra Chart is very very low. We do not believe that is the case. If no one else is experiencing it, then it would be a network issue that is affecting you. The way that we can help with this, is to send us a Message Log again at the time you have the problem. Let us know when you do that and then we will look at a very specific incident and find out from CTS what they see on their side. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2014-07-14 19:05:22] |
| T44 - Posts: 363 |
|
I have looked at logs back to May. Sierra Chart "unexpected disconnects" in the T4 logs: $wc -l *log 229 july-disconnects.log 217 june-disconnects.log 327 may-disconnects.log That is 773 total disconnects ignoring the header lines of the logs. During this time, my main ISP has changed peering, so it is unlikely that any hop on my/my ISPs side of the network is at fault. This leaves the various physical/virtual machines I have been using, and the plurailty of these suggests that the issue is elsewhere than my hardware, network, or ISP. Account numbers, IP addresses and unique hardware ID's redacted. Times are EST. Edit: I cannot upload these either as extension log or extension tbz2. I shall submit another message log when I see the issue next, however it is clear there is a problem here. |
Attachment Deleted. Attachment Deleted. Attachment Deleted. Attachment Deleted. |
| [2014-07-15 11:39:30] |
| T44 - Posts: 363 |
|
Edit: Disconnections also being experienced on earlier versions of Sierra.
Date Time Of Last Edit: 2014-07-15 14:42:00
|
| [2014-07-15 14:41:24] |
| T44 - Posts: 363 |
|
From CTS Support: the user must pinpoint a specific
recent session. He needs to describe the dynamics of the disconnection. If available, he must also send us his FIX logs - including the FIX Login message that started the session. How do I do this in Sierra Chart? |
| [2014-07-15 17:13:07] |
| |
|
Here are the instructions to access the FIX logs: Providing FIX Log to Support The FIX log though will not contain any heartbeat messages in order to reduce the amount of space taken. And it will not contain any market data messages for performance reasons. At this point it appears as though you are handling the problem direct with CTS? Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2014-07-15 17:19:46
|
| [2014-07-15 22:02:39] |
| T44 - Posts: 363 |
|
Here is what our FIX team said:
Most of the sessions reported as "UnexpectedDisconnects" were actually normal FIX sessions. Take for instance, today's (7/14) T4CHART1 session reported in their July-disconnects log. Here is their log entry: VARacctnumber Yes ChartData SierraChart UnexpectedDisconnect 14 Jul 2014 11:12:38.883 AM 2 14 Jul 2014 11:11:39.000 AM 14 Jul 2014 11:12:38.883 AM VARipaddress:56013 VARhardwareID T4CHART1 4.2.0.0 FIX42 None False 0-0 0-0 0-0 0 0 3 2 2 0 0-0 0-0 0 0 0 0.0 0.0 1.0 In this chart data FIX session, our trace logs indicate that the user was logged on, heart-beated and successfully logged out per his request. Here are the corresponding FIX messages we received from the user: 1 - LOGIN (in 1) [14-Jul-2014] 11:11:39.6504284 [SenderCompID] 49 = SierraChart [TargetCompID] 56 = Dorman [MsgSeqNum] 34 = 1 [SendingTime] 52 = 20140714-16:11:39.597 [EncryptMethod] 98 = 0 (NONE) [HeartBtInt] 108 = 30 [ResetSeqNumFlag] 141 = Y (YES) [SecureDataLen] 90 = 36 [SecureData] 91 = //redacted [UserName] 553 = //redacted [Password] 554 = *** [DefaultApplExtID] 1407 = //redacted [NoMsgTypes] 384 = 1 [RefMsgType] 372 = V (ENABLE_CHART_DATA_SESSION) 2 - LOGIN (out 1) [MsgSeqNum] 34 = 1 [SenderCompID] 49 = Dorman [TargetCompID] 56 = SierraChart [SenderSubID] 50 = T4FIX [SendingTime] 52 = 20140714-16:11:39.712 [EncryptMethod] 98 = 0 (NONE) [HeartBtInt] 108 = 30 [UserName] 553 = //redacted [Password] 554 = *** [DefaultCstmApplVerID] 1408 = 4.3.8.0 3 - HEARTBEAT (in 2) [SenderCompID] 49 = SierraChart [TargetCompID] 56 = Dorman [MsgSeqNum] 34 = 2 [SendingTime] 52 = 20140714-16:12:09.641 4 - HEARTBEAT (out 2) [MsgSeqNum] 34 = 2 [SenderCompID] 49 = Dorman [TargetCompID] 56 = SierraChart [SenderSubID] 50 = T4FIX [SendingTime] 52 = 20140714-16:12:09.696 5 - LOGOUT (in 3) [SenderCompID] 49 = SierraChart [TargetCompID] 56 = Dorman [MsgSeqNum] 34 = 3 [SendingTime] 52 = 20140714-16:12:38.313 6 - LOGOUT (out 3) [14-Jul-2014] 11:12:38.3689316 [MsgSeqNum] 34 = 3 [SenderCompID] 49 = Dorman [TargetCompID] 56 = SierraChart [SenderSubID] 50 = T4FIX [SendingTime] 52 = 20140714-16:12:38.368 [Text] 58 = Successful logout upon request There are also other sessions disconnected per a dropped socket - most likely, a networking issue. So my question for Sierra Chart support would be why is Sierra Chart requesting to drop the FIX connection with CTS when I have active symbols in the intraday update list and when I am running several charts of live markets? The second issue appears to be a network issue - dropped sockets which I understand Sierra Support (and possibly even CTS) may not be able to help with. I am going to try the FIX logging instructions tomorrow although without heartbeat information I'm not sure how helpful this will be to CTS support. Thanks. |
| [2014-07-15 23:36:48] |
| |
|
It is completely normal for connections to fix-chart.t4login.com which is used for historical chart data to be closed on the CTS side after 30 seconds of inactivity. That connection is not used for real-time data. Any log entries on either side for historical chart data, are not relevant to the problem. In your particular case, one reason why Sierra Chart would log off the chart data connection on its own is if the main connection use for trading and real-time data, gets disconnected, then chart data connection will be disconnected as well. But this is only a side effect and not relevant to the main issue. "dropped sockets" is an imprecise term. The only proper terminology would be the actual specific socket errors that occur. Based upon your logs, there are plenty of cases, where the connection is clearly getting closed on the remote side and for those connections we need to know the reason why. The most relevant way to track this down, is to find out why the server stops sending the data when you see this in the Sierra Chart log: The data feed was lost. There was no activity for at least
That must be the focus. In the minutes around that message, why is the server not sending data. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2014-07-15 23:39:13
|
| [2014-07-16 08:26:58] |
| T44 - Posts: 363 |
|
There appear to be different sorts of disconnections occurring. Here is an example from this morning. It does not include the message you quoted above, but still results in a disconnection from CTS then a reconnection: CTS FIX socket (1760) - Closed. Windows error code 10053: An established connection was aborted by the software in your host machine. | 2014-07-16 04:11:11 CTS FIX socket (1760) - SSL shutdown indicates not able to send 'close notify'. | 2014-07-16 04:11:11 CTS FIX socket (1760) - SSL has been shut down. | 2014-07-16 04:11:11 CTS FIX socket (1760) - SSL object has been freed. SSL state is now disconnected. | 2014-07-16 04:11:11 CTS FIX socket (1760) - Shutdown and closed. | 2014-07-16 04:11:11 CTS FIX: Socket connection was closed without any logout messages sent or received. | 2014-07-16 04:11:11 Connection to the external service has been lost. | 2014-07-16 04:11:11 CTS FIX: Disconnected. | 2014-07-16 04:11:11 Will reconnect to the server in 3.0 seconds Select File >> Disconnect to prevent further connection attempts. | 2014-07-16 04:11:11 CTS FIX - Connecting to CTS Live server fix.t4login.com:10443 | 2014-07-16 04:11:14 CTS FIX - Firm: Dorman | 2014-07-16 04:11:14 CTS FIX socket (0) - Resolved address fix.t4login.com to IP 208.116.215.102 | 2014-07-16 04:11:14 CTS FIX socket (1416) - Connected. | 2014-07-16 04:11:15 CTS FIX socket (1416) - Starting SSL connection. | 2014-07-16 04:11:15 CTS FIX socket (1416) - SSL connection established. | 2014-07-16 04:11:15 CTS FIX: Sending the Logon message. | 2014-07-16 04:11:15 CTS FIX: Connected to data and trade server. FIX version: 4.3.8.0 | 2014-07-16 04:11:16 I'll attach the FIX log from this session. Description: Sierra Chart disconnects, immediately tries to reconnect. The description of the "There was no activity for at least" would be no incoming ticks for the better part of a minute before Sierra Chart reconnects. I have now enabled FIX logging, so will be able to see more information from both types of issue. CTS seem to have FIX logs at their end and the easiest thing for me to do would be grep for "There was no activity" and produce a list of timestamps for the last week that this has been occurring. Unfortunately I do not have a copy of all my message logs, and wonder if you could send the ones containing "there was no activity" direct to CTS? Date Time Of Last Edit: 2014-07-16 08:33:37
|
Private File |
| [2014-07-16 08:44:54] |
| |
|
We see no reason at this time of day for there to be a disconnection based on the number of symbols being subscribed to in the FIX log. First check with your ISP to see if they are performing any throttling on this port: 10443 Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2014-07-16 09:03:41] |
| T44 - Posts: 363 |
|
Edit: ISP confirm no throttling or shaping. Recent occurrence of second issue: The data feed was lost. There was no activity for at least 60.0 seconds. | 2014-07-16 05:00:32 (EST) FIX Log: (different timezone...09:00 = 05:00 EST) I've sent this to CTS support to learn why there "was no activity". Date Time Of Last Edit: 2014-07-16 09:15:40
|
Private File |
| [2014-07-16 10:05:35] |
| T44 - Posts: 363 |
|
CTS FIX Historical Data: Disconnected. | 2014-07-16 05:01:53
The data feed was lost. There was no activity for at least 60.0 seconds. | 2014-07-16 05:51:22 Connection to the external service has been lost. | 2014-07-16 05:51:22 CTS FIX: Sending a Logout message. | 2014-07-16 05:51:22 CTS FIX: Disconnected. | 2014-07-16 05:51:22 I have forwarded these details to CTS support also. Interestingly, I was logged on to both my CTS accounts. At 05:51:04 my other account printed "There was no activity for at least 60.0 seconds". So it appears that there is something occurring to disconnect both sessions. They are running on different hardware, different operating systems, but the same Internet connection. I shall do some testing later with two different ISPs. Date Time Of Last Edit: 2014-07-16 10:09:08
|
Private File |
| [2014-07-16 13:59:53] |
| T44 - Posts: 363 |
|
There appears to be an issue with packet loss at my ISP. Using a connection quality monitor from http://www.firebrick.co.uk my line is showing intermittent 10-20% packet loss. The line is idle except for the Sierra/CTS connections. http://www.thinkbroadband.com/ping/share-large/d77a769885ae82d99ecb863892085649.png Switching to an alternative ISP on one of my CTS logins, the platform has been stable for 90 mins pre US open. I added some depth of market windows to push more data ahead of the US open, and the platform didn't disconnect over the US open. The platform attached to the faulty ISP lasted 30 mins through the open but has just disconnected again. Anything else I should check at my end? |
| [2014-07-16 17:06:03] |
| T44 - Posts: 363 |
|
Latest from CTS: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. That is, the server transport indicated that the physical connection was dropped as no data could be read from the session socket. This is a typical behavior of a client socket drop. In the same time frame, other connected users did not disconnect. This appears to be a networking issue somewhere in my ISP. |
| [2014-07-16 19:30:21] |
| |
|
We have read through all of your postings, using your other Internet connection, are you still able to maintain a stable connection during the trading day? The FIX logs do not need to be provided to us. For us, our Message Log is more than sufficient. Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2014-07-17 07:40:25] |
| T44 - Posts: 363 |
|
using your other Internet connection, are you still able to maintain a stable connection during the trading day?
Yes, thank you. |
| [2014-07-17 08:05:16] |
| |
|
OK shall we consider this resolved?
Sierra Chart Support - Engineering Level Your definitive source for support. Other responses are from users. Try to keep your questions brief and to the point. Be aware of support policy: https://www.sierrachart.com/index.php?l=PostingInformation.php#GeneralInformation For the most reliable, advanced, and zero cost futures order routing, *change* to the Teton service: Sierra Chart Teton Futures Order Routing |
| [2014-07-17 08:15:05] |
| T44 - Posts: 363 |
|
I'd still like to see if CTS support have any further comments. They sent me a FIX analysis session which said I'd placed a trade in the GCQ4 contract yesterday and showed the FIX logs to prove it. Yet I had not placed any orders yesterday, and was able to verify this with my clearing firm. The logs seemed to suggest that sessions were being dropped from their side, and I've currently no choice but to assume that this was due to my side timing out owing to the network issues/ packet loss. If there are any other issues arising on a stable line I'll open another issue, but for now I think we can consider it resolved. Thanks for your help. |
To post a message in this thread, you need to log in with your Sierra Chart account: