Trading Terminal Disconnection and Latency
Trading terminal disconnection- whether manual or algo-should not happen in the ideal situation. Yet it happens with everyone. It is like getting sick or being caught in accident, everyone faces it.
When the market particular moves uni-directional with high volume, trading terminals may particulary face such issues. There are multiple versions of these problems:
- Terminal may get disconnected for a short-time
- Scrip rates get stuck or do not refresh for 5-30 seconds
- High Latency- it may take 2-3 seconds for the time it takes for you to place and order and the time when order confirmation arrives
This leads to trader wondering whether it is just another manipulation by broker. Professional Traders often encounter loss in such scenario. Complaints to SEBI/NSE in this regards do not help either because the brokers strongly confirm terminal disconnection in indemnity clause in the broker-client agreement.
Contents
Problematic Scenarios
Consider this: you identify once-in-a-month trading opportunity and want to buy shares with all your margin. As soon as you press F1 to place order, the terminal gets hung. You nervously wait and try starting the Task Manager, but no help. Finally you force close the application and login again. By this time the market could have already moved significantly and your reward/risk screwed.
Another example: When in a trade you decide to exit a trade gone wrong earlier than its stop loss. Just when you are about to modify order, the application hangs. By the time you kill its process and restart, the SL is already hit.
Chasing the prices: there is earnings announce in your favorite stock and prices starts rising madly. You punch an order close to the best seller price but do not get fill. You cancel the order, and punch a fresh order 10 ticks better than best seller, still no fill. You cancel again the pending order, and punch another order 20 ticks better than best seller. You can clearly see that the best seller price is far better than your order price, but the terminal does not fill your order. Frustrated, after some time you realize that terminal was broadcasting stale prices. The terminal may be broad casting prices with latency of 4-5 seconds, and in fast moving market it can make a big impact.
Solutions suggested by Broker
All Indian brokers invariably blame the client’s USP, antivirus, firewall and ISP settings for such issues. The interesting part is, when you switch from one broker to another, the issues may resolve. When all system variables at client’s end remain same and only change is broker, you are likely to notice a significant change in the frequency of disconnection issues. Also, you may notice that your friend trading with same broker is able to trade smoothly while you are facing problem.
In the real world, the broker’s technical staff is often not qualified to resolve such queries. Also they are biased to admit any fault from their side. Stringent guidelines favoring the trader and penalizing the broker makes the brokers staff adamant about the problem being at clients side.
Solutions for the Trader
As per Algoji’s experience, the problem is more often at the client’s end. Sorry for the disappointment. There is an easy quantitative way to find out whose fault is it. The following diagnostics should be performed when you are trading (in live market)
Step 1: Open the Command Prompt. It can be found in the All Programs->Accessories menu. You may need to right-click and open it with admin rights if there are multiple user accounts in your windows computer.
Step2: Type “CD\” and hit enter. This will bring you to the root directory.
Step3: Type the command “ping facebook.com -t>fb_ip_logs.txt” and hit enter. This will start recording a text file in C: drive with detailed ping diagnostics. Since facebook has state-of-the-art servers, you can use this file as a reference for your own internet connectivity.
Step4: Open another window (Step1&2). Record your broker server’s ping diagnostics. To find out your broker server’s IP, go to Nest->Help->NEST Diagnostics. For other terminals you can also ask your broker the IP in written email. The ping command will be: “ping <broker ip> -t>broker_ip_logs.txt
Keep both the command prompt-windows open for atlead one hour or as long as you wish. Longer times will help in better diagnostics.
Comparing your connectivity versus broker’s server
The typical content (in Indiaah!) of fb_ip_logs.txt is like:
Pinging facebook.com [173.252.74.22] with 32 bytes of data: Reply from 173.252.74.22: bytes=32 time=332ms TTL=77 Reply from 173.252.74.22: bytes=32 time=337ms TTL=77 Reply from 173.252.74.22: bytes=32 time=330ms TTL=77 Reply from 173.252.74.22: bytes=32 time=330ms TTL=77 Reply from 173.252.74.22: bytes=32 time=340ms TTL=77 Reply from 173.252.74.22: bytes=32 time=330ms TTL=77 Reply from 173.252.74.22: bytes=32 time=330ms TTL=77 Reply from 173.252.74.22: bytes=32 time=331ms TTL=77 Reply from 173.252.74.22: bytes=32 time=330ms TTL=77 Reply from 173.252.74.22: bytes=32 time=330ms TTL=77 Request timed out. Reply from 173.252.74.22: bytes=32 time=331ms TTL=77 Reply from 173.252.74.22: bytes=32 time=331ms TTL=77 Reply from 173.252.74.22: bytes=32 time=329ms TTL=77
The most important factor is to look for RTOs (Request Timed Out). If you see more RTOs in broker_ip_logs.txt then fb_ip_logs.txt, it is a serious concern. An RTO indicates disconnectivity. The disconnectivity may be either caused by your ISP (recorded in fb ping) or by your brokers server infrastructure (recorded in broker ping).
The “time” is the measured time (in milliseconds) for a packet to reach the FB’s server. The time can also be used as an indicator of latency. The time should be ideally under 100ms. If it is more than 500ms, your ISP is bringing a serious disadvantage.
If the time in broker_ip_logs.txt is more than twice the time in fb_ ip_logs_txt, you have a recorded proof to point fingers at your broker. The two simple checks of latency and connectivity can help rip part your brokers claims about it’s infrastructure.