Support Board
Date/Time: Mon, 08 Sep 2025 10:31:22 +0000
Post From: Prop firms moving away from Rithmic
| [2025-09-03 16:03:55] |
| Sierra_Chart Engineering - Posts: 20832 |
|
No it is a video that we made from the US Midwest. We have been meaning to follow-up in this thread. Explaining Internet connectivity. When data delivered using the TCP/IP protocol and sent over a long distance, inevitably the number of updates per second goes down. Still fast, but not as fast as potentially 50 times a second. It will be less. Maybe less than 10 times a second. For example, in New Zealand we do notice fewer number of updates per second, but there is no delay beyond the introduced latency due to the distance and there is no stopping of the data feed. It is very good. We are not totally sure of the reason for the fewer updates per second but it just must have to do with the high latency between the two locations and the extra time for acknowledgments to get through to the sender/server. If the data is delivered with UDP, we would expect probably faster updates per second but there will be data loss. This is why we would not use UDP. And it also needs to be understood for every packet that is sent from our servers in the Midwest, each has to be acknowledged, by the user's computer through the operating system. If any those acknowledgment packets get lost, it results, and data retransmission resulting in delays or if there is enough retransmission going on, the data feed just stops for a period of time and that it eventually catches up all at once. The illusion is that something is wrong with the data feed. No it is not. It is simply the transmission control protocol, doing this.: https://en.wikipedia.org/wiki/Transmission_Control_Protocol Acknowledgments (ACKs) are sent with a sequence number by the receiver of data to tell the sender that data has been received to the specified byte. ACKs do not imply that the data has been delivered to the application, they merely signify that it is now the receiver's responsibility to deliver the data.
Reliability is achieved by the sender detecting lost data and retransmitting it. TCP uses two primary techniques to identify loss. Retransmission timeout (RTO) and duplicate cumulative acknowledgments (DupAcks). When a TCP segment is retransmitted, it retains the same sequence number as the original delivery attempt. This conflation of delivery and logical data ordering means that, when acknowledgment is received after a retransmission, the sender cannot tell whether the original transmission or the retransmission is being acknowledged, the so-called retransmission ambiguity.[38] TCP incurs complexity due to retransmission ambiguity.[39] However, we are still not getting to the important point here. If we put a server in Asia, it should not make any difference at all and should be completely unnecessary. And this is an actual fact. Whatever we are able to accomplish by having good connectivity between the the US Midwest, and a server in Asia, you should be able to accomplish as well. And once again we are going to reaffirm, that the problem does relate to degraded Internet connectivity somewhere from with the user's computer, all the way to the server. There is no problem with the Denali Exchange Data Feed. The updating is very fast, there is no data feed stopping and no unreasonable delays. There is always some amount of delay due to data processing. But these delays, will be under 100 milliseconds normally. Could be higher during big bursts of activity. If you have good Internet connectivity within North America, or in Europe, not all of Europe is going to be good, then the data feed will work very well for you. We do not deny that some users may have a problem. But it is due to the Internet connectivity. Anyway we are still not getting to the main point here. If we put a server in Asia, to receive data, from the US Midwest, where the data originates out of, then all of the same potential problems that someone in Thailand would have, still exist. If we are delivering that data using the TCP protocol, all the potential problems, of lagging data, fewer updates per second, and data stopping still exist. The difference is that, we could use a virtual circuit, providing dedicated bandwidth, or we would be using better quality Internet connectivity, the data centers will have or we could obtain (although not necessarily). So the reason why a server in Asia could potentially help, is that we will have very reliable Internet connectivity as compared to a user, possibly, between the server in Asia and America. But inevitably it is not going to be perfect and it will have its problems at times. You would be able to establish a more reliable connection, possibly but not necessarily, due to the shorter distance between this server in Asia , and your location in Asia. Where there is a much lower latency, for return packets So this is why, a server closer to your location may help and likely would some users but not all. However, we have no plans to add servers closer to Asia anywhere outside of what we already have in NZ. We are just not going to do that. We have no physical presence in Asia, and we trust absolutely no one, with server Infrastructure other than ourselves. Just never going to happen. And we mean never. However, all of the latency, and all of the distance between the data feed origin still exist. So all of the potential problems can and will exist, at times. And if we are able to, establish good connectivity, between Asia, and the Midwest United States, you can too. That is the point. It should not help for us to put an intermediary server in Asia. You should be able to establish a reliable direct connection. If we can do that, and provide better connectivity then you can as well. However the high latency still exists. And there will be fewer updates per second. So there is no need to rely on us. Improve your Internet connectivity between your location and the US midwest. No need to put any reliance on us whatsoever. Rather than complaining about your own Internet connectivity and expecting us for a solution. That is wrong. 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, use the Teton service: Sierra Chart Teton Futures Order Routing Date Time Of Last Edit: 2025-09-03 19:55:59
|