미시간주 사우스필드의 123Net DC1에서 제공하는 실시간 지연 시간, 라우팅, 대역폭 데이터
미시간주 사우스필드 데이터센터 기준 왕복 지연 시간입니다. 테스트할 때마다 자동으로 갱신됩니다.
| 위치 | 국가/지역 | 제공업체 | RTT | 품질 |
|---|
미시간 데이터센터에서 전 세계 어떤 대상으로든 ping, traceroute, MTR을 실행하세요.
미시간 데이터센터에서 사용자 회선까지의 다운로드 속도를 측정합니다.
파일은 미시간주 사우스필드 시설에서 직접 제공됩니다. 속도는 사용자의 경로와 라스트마일 회선 상태를 반영합니다.
The tools above run from our side of the connection, in Southfield, Michigan, which
answers a different question than running them from yours. Internet paths are frequently
asymmetric: the route your packets take to reach us is often not the route ours take to
reach you. Testing in both directions is what separates a problem on your access network
from a problem in transit. Run the diagnostics here against your own address, then run the
same tests from your own machine against 23.170.200.100, and compare the two.
Ping sends ICMP echo requests and reports the round trip time of each reply. The useful
signal is the distribution, not the average: min, avg,
max and mdev together tell you whether a path is stable or
bursty. A 40 ms average with 2 ms of deviation is a clean path. The same average with
30 ms of deviation means something is queueing, and interactive traffic will feel it
even though the average looks identical.
Packet loss reported at the destination is real. Loss reported against an intermediate hop usually is not. Most routers rate limit the ICMP responses their own control plane generates while forwarding transit traffic untouched, so a middle hop showing 20 percent loss with a clean endpoint is a router protecting itself, not a broken link.
Traceroute maps the forward path by sending packets with incrementing TTL values and recording which router returns each expiry message. Two things routinely mislead people reading the output. First, hop latency is not cumulative: hop 8 showing 90 ms after hop 7 showed 20 ms does not mean hop 8 added 70 ms of delay. It means the reply from hop 8 took that long to come back, and the return path from that router may be completely different from the forward path your traffic actually takes.
Second, hops inside an MPLS tunnel may not decrement TTL at all, so a path can appear shorter than the physical route. A row of asterisks is almost always a router configured not to answer rather than a dead link: if later hops still respond, traffic is passing through that point fine. The place to look is where the reverse DNS suffix changes, since that is usually where the path leaves one network and enters another.
MTR runs traceroute continuously and aggregates the results, which is the only practical way to catch intermittent problems a single traceroute run will miss entirely. Read it from the bottom up. The loss figure on the final hop is the one that describes your actual connection. Loss on intermediate hops that does not persist to the destination is the ICMP rate limiting described above and can be ignored.
Loss that appears at one hop and continues through every subsequent hop is a genuine problem at or before that point. Latency that jumps at one hop and stays elevated for the rest of the path indicates congestion there. Latency that jumps at one hop and returns to normal on the next is that single router deprioritising its own replies, and says nothing about the traffic passing through it.
The quality labels in the latency table above are fixed thresholds applied to round trip time measured from our Southfield facility. They describe the path, not the health of the destination host.
| Band | Round trip time | What it means in practice |
|---|---|---|
| Excellent | Under 60 ms | Regional or well peered continental path. Interactive work feels local. |
| Good | 60 to 150 ms | Typical transcontinental or transatlantic. Fine for most workloads, noticeable on SSH. |
| Fair | 150 to 300 ms | Long haul, or a suboptimal path. Worth a traceroute to see where the time goes. |
| Poor | 300 ms and above | Satellite, heavy congestion, or routing well off the direct path. |
| Timeout | No reply | Usually ICMP filtering at the destination rather than unreachability. |
As a rough sanity check, a well routed path out of Detroit lands near 10 to 20 ms to Chicago and Toronto, 20 to 30 ms to New York, 30 to 40 ms to Dallas, 55 to 70 ms to the west coast, and 95 to 115 ms to London. The live table above is the authoritative figure, since it is measured rather than estimated.
The test server sits in the 123Net DC1 facility in Southfield, Michigan, on a 1 Gbps uplink. Detroit-IX is on-site in the same building, and RackWorks reaches the wider internet through a Detroit-IX connected upstream. That geography is what keeps hop counts to regional destinations short: traffic destined for networks present at the exchange can hand off inside the building instead of transiting to Chicago and back.
It is also why round trip times from Detroit to Toronto, Chicago and the eastern seaboard tend to come in lower than raw map distance would suggest, and why a traceroute from here to a Midwest or Ontario destination often shows fewer transit hops than the same test run from a coastal facility. The Detroit-IX peer list linked above is live data from detroitix.com and shows which networks are present at the exchange. The measurements on this page come from the same network and the same uplink that serve VPS hosting from this Detroit facility.
Testing this network because you are evaluating it?
Everything measured on this page is the same network our customer VMs sit on, in the same facility, behind the same uplink.