pieter_rtm
Member
- Joined:
- Jul 2024
- Posts:
- 195
- From:
- Rotterdam, NL
- Ashburn: 1ms to DC, actual
- Newark: 8ms to DC, plausible "East"
- Toronto: 18ms to DC, not US
My test: 50 ICMP samples, 100 byte payload, weekday 14:00 UTC. As said, numbers do not lie. Marketing does.
The "US" server I got was 206.x.x.x geolocating to Montreal. Latency to Chicago: 22ms. Latency to actual Chicago box: 4ms.
Dry humor: at least it was not "US Central" meaning Mexico City.
Containers before it was cool
tallinnying
Member
Night Shift
- Joined:
- Aug 2024
- Posts:
- 268
- From:
- Tallinn, EE
Lol I only care if AD replication works IIS enjoyer here, my DCs need to sync regardless of whether the box is in Iowa or Ontario. Active Directory handles site links fine. That said, if their "US East" is actually Canada, my CAL licensing gets weird. Active Directory doesn't care but Microsoft audit might.
builds at 3AM, sleeps at noon
hankels
Member
52 VPS and counting
- Joined:
- Jun 2024
- Posts:
- 301
- From:
- Phoenix, US
I checked 12 of em 😂
"US East" breakdown:
- 6 Ashburn (correct)
- 4 Newark (ok fine)
- 2 Montreal (nope)
$/GB/RAM still decent at $2.50/GB but false location = false latency promise = my Plex users in Florida getting routed through Toronto for "local" cache
List of IPs and actual geolocs attached, someone make a spreadsheet
seedbox, NAS, tape, and three offsite
bellaauc
Member
3-2-1 Believer
- Joined:
- Jun 2024
- Posts:
- 190
- From:
- Auckland, NZ
Did you test your restore before chasing latency?
Important checklist:
- 3-2-1 rule still applies regardless of which country your bits sleep in
- Backup location documentation matters for compliance
- Test restore from "US East" that turns out to be CA = potential PIPEDA issue
I keep secondary backups in a second provider entirely. Location truth matters for my restore testing schedule.
Cheers and test those restores!
3-2-1 or you're already dead