Support Board
Support Board
Search Board
Control Panel
View My Posts / Threads
Direct MessagesDate/Time: Wed, 24 Apr 2024 16:45:44 +0000
Surge causes data feed lag?
View Count: 3019
| [2013-08-30 17:04:47] |
| 9baller - Posts: 38 |
|
Crude oil surge today at 12:57 EST....caused major lag (20-30) ticks between data feeds I use 1 computer with multicharts and zenfire feed for charts...2nd computer is SC with CTS feed for execution only (DOM).... CTS lag significantly....CTS says SC problem....what you all say?....same troubles? Date Time Of Last Edit: 2013-08-30 17:05:33
|
| [2013-08-30 18:38:45] |
| |
|
Refer to help topic 4 here about this: Http://www.sierrachart.com/index.php?l=doc/helpdetails4.html Data feed lags almost always have external causes. 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 |
| [2013-08-31 08:06:45] |
| |
|
If the data feed lag is due to too much processing load upon the CPU, you would clearly be able to determine that through the Windows Task Manager. You need to look at the CPU load from Sierra Chart. Is it using nearly or close to 100% of one of the available CPU cores? No need to answer this for us. This is only for your own information. Even if a large portion of a core is being used, this should not cause a significant lag. At best a few hundred milliseconds. We believe this is a server side problem or a problem with not enough network bandwidth. We are going to add an option in the CTS settings to choose among different market data feed options: Data Throughput and Buffering Levels
The T4 FIX API offers several levels of data throughput. The market data subscriber can control the number of quotes and the throughput rate (received by a client application). The T4 FIX API buffers streaming market data flow and disseminates quotes at the throughput level requested by the API client. Smart Buffering is recommended. The following T4 buffering levels are available: SlowTrade: Same as SlowSmart buffering plus every individual trade is received as well. It should be used sparingly due to high bandwidth and potentially large number of messages being received during busy market periods. SmartTrade: Same as Smart buffering plus every individual trade is received as well. It should be used sparingly due to high bandwidth and potentially large number of messages being received during busy market. SlowSmart: Slowed down version of Smart buffering for lower bandwidth usage. This produces depth updates about once per second per market if changes have occurred. Smart: Smart buffering (Recommended), depth is sent out on different buffering intervals dependent on what has changed in the depth. Changes to the best bid, offer or last trade are sent out frequently, changes that are off the market are sent out less frequently. FastSmart: Faster version of Smart buffering. It sends out changes to best bid or offer prices more frequently. Much higher bandwidth usage. All: All depth updates, no buffering. Not supported by API applications. Specifying this subscription level in the API will result in Smart buffering level. Same as FastSmart buffering plus every individual trade is received as well. It should be used sparingly due to high bandwidth and potentially large number of messages being received during busy market periods. FastTrade: Same as FastSmart buffering plus every individual trade is received as well. It should be used sparingly due to high bandwidth and potentially large number of messages being received during busy market periods. TradeOnly: Every individual trade is received, but nothing else - no depth, settlement, highlow, price limits etc. 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: 2013-08-31 08:08:27
|
| [2013-08-31 14:24:13] |
| 9baller - Posts: 38 |
|
I run SC on a dedicated PC....DOM ONLY...1 symbol CORE I5 @3.9GHZ w16gb ram...CPU USAGE is < 2% at peaks....usually <1% Date Time Of Last Edit: 2013-08-31 14:24:45
|
| [2013-08-31 23:19:19] |
| |
|
The problem must be server side or with network bandwidth. We are going to be implementing the option we mentioned in post #3, this week. We recommend using "Smart" when this becomes available this week. 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 |
| [2013-09-01 02:58:38] |
| 9baller - Posts: 38 |
|
ok will do that... could synergy program possibly be causing bottleneck? I use synergy to connect both PC's together so that I can use 1 mouse and 1 keyboard...been using it about a year with out problems in NT...but sometimes different software reacts differently? otherwise network should be fine: 18ms PING....57mbps up....12mbps down |
| [2013-09-01 13:34:17] |
| Al SC Developer - Posts: 434 |
|
In ver 1020, there will be a new option in the Data/Trade Service Settings called "Data Throughput and Buffering". The option includes the values in the previous post, with the default being "Smart".
|
| [2013-09-01 21:23:10] |
| |
|
We see no reason why your synergy program would cause a problem. Our concern is that the issue has to do with FIX and there is too much server-side processing and bandwidth being involved. This is why there is now an option to control the amount of data from the server. If efficiently implemented, FIX can be very efficient. It is very efficient on the Sierra Chart side. Sierra Chart can process FIX messages extremely fast. 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: 2013-09-01 21:24:07
|
| [2013-09-02 01:18:05] |
| 9baller - Posts: 38 |
|
when I contacted CTS about this they suggested that the problem was due to your new FIX protocol versions...and that the API versions run very efficiently...(I may be inadvertently misquoting a bit) suggested I get a copy of the last API version number 997 or something of the that number... I will look for the update and keep you apprised of any similar behavior.... |
| [2013-09-02 06:22:46] |
| |
|
Will contact them and see how the delivery of the data can be made more efficient. All Sierra Chart versions can be found here: https://www.sierrachart.com/index.php?l=doc/download.php 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: 2013-09-02 06:23:24
|
To post a message in this thread, you need to log in with your Sierra Chart account: