Does anyone know why Alpaca changed their data server from Google’s Leesburg, VA. data center to Google’s data center in west Atlanta, GA.(Douglas County)? My strategy is heavily dependent on ultra-low latency. It was previously less than <1ms and now at 17 ms, and my dedicated server in under a long contract. Will the stream.data (for both/sandbox as well). alpaca.markets location change be permanent, or will it go back to Google’s Leesburg, Va. data center ?
@jferrer84 The Alpaca servers are still hosted at Google US-east4. It shows up as located in Ashburn, Virginia, Loudoun County and sometimes Washington DC. There was a change a few months ago that the streaming endpoints https://stream.data.alpaca.markets changed IP address (38.122.35.99 → 34.145.195.91) to match the REST endpoints. This appeared in a status update here.
What are you seeing which makes you feel the location is Atlanta, GA? Also, are you streaming data or using the REST APIs? How are you measuring latency?
Hi Dan,
Thanks for the reply and information. The company that handles my server in the datacenter sent me the following information using a traceroute showing that the ip moved to google’s data center to west Atlanta (Douglas County). You can see the change from Ashburn (ash) to Atlanta (atl). This also makes sense why my latency changed:
"The IP address 34.145.195.91 is now in Atlanta, not Ashburn. Please see attached traceroute:
traceroute to 34.145.195.91 (34.145.195.91), 30 hops max, 60 byte packets
1 45.67.15.1 (45.67.15.1)
2 * * *
3 unn-37-19-193-212.cdn77.com (37.19.193.212) 0.361 ms 0.382 ms 0.421 ms
4 ash-b2-link.ip.twelve99.net (62.115.10.97) 0.793 ms 0.851 ms 0.847 ms
5 ash-bb2-link.ip.twelve99.net (62.115.123.124) 2.146 ms rest-bb1-link.ip.twelve99.net (62.115.123.122) 1.145 ms *
6 atl-bb1-link.ip.twelve99.net (62.115.138.71) 16.274 ms 16.200 ms 16.984 ms
7 atl-b24-link.ip.twelve99.net (62.115.134.247) 16.149 ms 16.307 ms atl-b4-link.ip.twelve99.net (62.115.134.227) 13.477 ms
8 atl-b4-link.ip.twelve99.net (62.115.134.227) 16.193 ms 16.655 ms 13.701 ms
9 192.178.68.246 (192.178.68.246) 16.802 ms 16.876 ms 91.195.145.34.bc.googleusercontent.com (34.145.195.91) 13.700 ms
"
I have a screenshot to send you that displays both ip latency results (using windows command) displaying side-by-side yesterday’s test of < 1ms and todays test showing 13-17ms.
Please find the screen shot below:
Is this change temporary? Will it go back to Google’s data center in Ashburn that has a direct fiber line to exchange center in Secaucus, NJ? What should we that have established servers in Ashburn do?
Hi Dan,
I rant a traceroute on my dedicated server.
The first traceroute is for “stream.data.alpaca.martkets”
The second is for “live.data.alpaca.markets”
My server is in Ashburn. It is so strange that in now doing my own test the stream.data.alpaca.markets shows “atl” for Atlanta as well which the ping makes sense vs the live.alpaca.markets (I believe Alpaca’s accounts server) remains low and in Ashburn. So strange, it’s as if it is hopping my over to “atl” Atlanta instead of Ashburn.
@jferrer84 Nothing has changed with where Alpaca is hosted and certainly not in the past day or two.
Line 8 in the first screenshot above showing the routing to 34.145.195.91 simply means that was the last IP address (router/hop) before the final destination. It doesn’t imply that is where the final destination is (ie it doesn’t imply the Alpaca server is in Atlanta). As an example, I am in Madison, WI. When I do a traceroute, the last IP before the final destination is in Chicago, IL.
dan@DanWhit22W1Q6LR ~ % dan@DanWhit22W1Q6LR ~ % traceroute 34.145.195.91
traceroute to 34.145.195.91 (34.145.195.91), 64 hops max, 40 byte packets
1 dsldevice (192.168.1.254) 34.328 ms 4.607 ms 4.170 ms
2 76-250-40-1.lightspeed.mdsnwi.sbcglobal.net (76.250.40.1) 174.276 ms 156.766 ms 20.614 ms
3 76.229.12.29 (76.229.12.29) 155.692 ms 22.327 ms 21.259 ms
4 * * *
5 32.130.91.19 (32.130.91.19) 28.313 ms 26.350 ms 26.257 ms
6 12.255.10.44 (12.255.10.44) 32.559 ms
12.255.10.56 (12.255.10.56) 26.723 ms 28.788 ms
7 91.195.145.34.bc.googleusercontent.com (34.145.195.91) 42.961 ms 47.305 ms 44.177 ms
The intermediate IPs aren’t as descriptive as yours but if I run ipinfo 12.255.10.56 to find out where it is located I get this
{
"ip": "12.255.10.56",
"city": "Chicago",
"region": "Illinois",
"country": "US",
"loc": "41.8500,-87.6500",
"org": "AS7018 AT&T Services, Inc.",
"postal": "60666",
"timezone": "America/Chicago",
"readme": "https://ipinfo.io/missingauth"
}
Chicago makes sense for me. It’s close to Madison and then a single hop to the Alpaca server (probably on a high speed fiber connection). Here is the ipinfo for the Alpaca server 34.145.195.91
{
"ip": "34.145.195.91",
"hostname": "91.195.145.34.bc.googleusercontent.com",
"city": "Washington",
"region": "Washington, D.C.",
"country": "US",
"loc": "38.8951,-77.0364",
"org": "AS396982 Google LLC",
"postal": "20004",
"timezone": "America/New_York",
"readme": "https://ipinfo.io/missingauth"
}
As mentioned, the location of us-east4 sometimes shows up as Washington?
To verify this is us-east4, I can launch a google server in the us-east4 region and run a ‘local’ ipinfo command (ie without specifying the IP address) I get this
{
"ip": "34.48.71.110",
"hostname": "110.71.48.34.bc.googleusercontent.com",
"city": "Washington",
"region": "Washington, D.C.",
"country": "US",
"loc": "38.8951,-77.0364",
"org": "AS396982 Google LLC",
"postal": "20004",
"timezone": "America/New_York",
"readme": "https://ipinfo.io/missingauth"
}
Notice the IP address is some random address assigned to my instance (ie 34.48.71.110) but it shows up as the Washington location the same as the Alpaca server.
What seems to have changed for you is the routing for your requests. I’m sure the final Alpaca destination hasn’t changed.
this is more likely throttling on the isp side of your hosting provider or dynamic price matching control
https://www.reddit.com/r/programming/comments/ano6rs/physical_rate_limiters_slowing_down_a_stock/
This is great information that I will relay back to tech support for my server. In the mean time, any suggestions to help steer them the right way?
Thank you so much for the info as well kris. Do you have any suggestions to the tech support team as well? Any and all advise would be most helpful.
Thank you both!