IB server ping time

Discussion in 'Retail Brokers' started by x-or, Jan 18, 2003.

  1. x-or


    Every morning I do a "ping" command to the IB server (gw1.ibllc.ch) to get an idea of the delay that my orders can get to be filled.
    Last fews months, i had some time response around 140 ms and quite often under 100 ms. But lately, it has been around 200 ms.
    (Too bad, i should have done a "traceroute" command to see where do the delay increase come from)

    However, I don't have to complain about that because my orders are still well filled.
    But I'd like to have an idea of what kind of time delay do others traders have (with IB or other brokers).
    What kind of time response should I expect ? Is 200 ms still acceptable ?
  2. impetus


  3. Moa


    From Spain:
    IB ch around 125 ms
    IB us around 190 ms
  4. Ninja


    Some months ago Def said that TWS allways connects through the .com server regardless of your settings...

    However when I ping gw1.ibllc.ch it takes 172 ms from Germany and the .com today needs 170 ms which is good, because on weekdays I usually have about 250 ms. Thats with DSL. ISDN is usually a bit faster, but I haven't used it since I have my DSL flat rate.
  5. nitro


    A ping is not the correct way to measure latency, as you have no idea if the route that is being taken is what is slowing you down or the response of the server itself.

    The correct tool is traceroute (tracert in windows systems.) Further, unless you have some statistics to compare it with, you have no idea what part of the system is the one that changed and is causing the slow down.

    Therefore, I suggest you tracert for a month every day, and pipe the output of the traceroute to a file. Then use excel (or something that will display the stats graphically) to dig for problems. Also, keep track to see if your route has changed and caused it to slow down.

  6. CalTrader

    CalTrader Guest

    As stated earlier you can use tracert.

    Another point to consider is that no matter what the statistics show, you may have little or no recourse to change the results unless you have some type of service level guarantee and static route in place with your network services provider. These agreements come with a price ....
  7. SubEtha


  8. x-or


    www.visualroute.com (good soft) confirms what traceroute tells me.

    That's too bad : I live in France and my signal is crossing the ocean two times before reaching Switzerland :
    Me -> Paris -> NY -> Washington -> Philadelphia -> NY -> Switzerland

    I lose about 150 ms with that.

    It seems that it is my cable provider that drives the signal through the US. Don't know why and don't know if it has always been like this. I'll check it in the future.
  9. Ninja


    So with this trace route why do you want to use the swiss server anyway? Just use the .com server and you will cross the ocean only one time.
  10. Bsulli


    Another couple of freeware products that work well are pingplotter.com and analogx.com Both are continous trace products. The problem with pings is being part of the ICMP protocol within IP is it's treated as very low priority by routers and switches per the IETF)Internet engineering task force) RFC(Request for comment) that it comes from. You can have heavy traffic running across the router but if it's busy it isn't required to respond to pings at all if the service window is missed. I leave pingplotter running most of the time in the background. I cross one of ATT's peering routers in Dallas to get out and on any given evening there are times that traceroute will show period of 2500miliseconds getting across it when it's heavily loaded but won't respond to pings and traceroute is flowing across it(Thank goodness it's not like that during trading hours). Pings was always intended to be a simple alive or dead tool for basic time measurements. Also many websites and routers are set to filter pings and not respond. Also something to keep in mind is many preformance problems on your ISP connection can be DNS lookup problems as well.


    #10     Jan 18, 2003