Field techs and their support lack basic tech skills and company knowledge

[miken]

Latency and bandwidth throughput have nothing to do with eachother.

For example, on the post with traceroutes you put a wget to cdimage where speeds are fast (100MBp/s+). When I traceroute that address the response time is 3 times worse than Phobrain while the speed is way faster. If the slow ping response to 4.14.98.38 was indicative of an actual problem, you would be having even worse connection issues to cdimage.

To clarify, I am not telling you that server *isn't* a problem. I am telling you it's one of 6 that could be the problem and there is no reason that you should believe it more likely of a problem than any of the other 5 servers. Since the information you got last time you called the owner's of the end server is wrong (i.e. reading a traceroute) maybe you should reconsider calling them to see if you can get some better information from them.

[waxriot]

Thanks for the overview, however long experience has left me focusing on anomalies to be careful, e.g. in this case the IP lacked a name too, another suggestion of misconfiguration.

Logically, the first server to show a slowdown is independent of servers further down the chain. E.g. since I'm on comcast these days (while I think about my taste in routers), you can see how the delay is there for the next named server:

-- to phobrain.com

6 lag-14.ear3.sanjose1.level3.net (4.68.72.105) 15.396 ms 16.389 ms 15.637 ms
7 * * *
8 4.14.98.38 (4.14.98.38) 86.513 ms 82.464 ms 83.717 ms
9 e3.1.cr02.iad01.mtsvc.net (70.32.64.110) 84.737 ms 83.843 ms
e3.1.cr01.iad01.mtsvc.net (70.32.64.102) 83.273 ms

-- % traceroute 4.14.98.38

6 * lag-14.ear3.sanjose1.level3.net (4.68.72.105) 17.631 ms 14.603 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * *
^C

-- traceroute to 70.32.64.110 (70.32.64.110), 64 hops max, 52 byte packets
1 10.0.0.1 (10.0.0.1) 7.435 ms 4.296 ms 4.975 ms
2 96.120.89.205 (96.120.89.205) 14.380 ms 14.399 ms 19.821 ms
3 po-101-rur01.sfgeary.ca.sfba.comcast.net (68.86.248.37) 14.848 ms 16.104 ms 13.281 ms
4 162.151.78.89 (162.151.78.89) 13.894 ms 18.334 ms 14.873 ms
5 be-299-ar01.santaclara.ca.sfba.comcast.net (68.86.143.93) 15.061 ms 13.544 ms 14.910 ms
6 lag-14.ear3.sanjose1.level3.net (4.68.72.105) 15.577 ms 15.677 ms 15.620 ms
7 * * *
8 4.14.98.38 (4.14.98.38) 86.468 ms 82.153 ms 83.486 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * *^C

In my ideal world, you'd have he phone number of someone at Level3, and after my initial 30 sec support call, someone would call Level3 tech and say, "Yaaa, looks like you might have a config problem with x.x.x.x, are you able to get a window on it?"

Further thought: it's the last non-Media Temple host on the way to Media Temple, so your instincts to push it their way are good, and I'll ask them about it again, tho from what the tech said, they just have to sit it out, so that's where I'm hoping Sonic as my ISP and net neutral knight in shining armor might have some ability to talk to Level3 as a peer, plus help me nail down the culprit to Level3 in the first place. I'd call it a 30-60 minute ticket in my old support days.

[sysops]

I'm not sure how this is a Sonic issue, nor that there's much they can do about it.

Level3 is peered directly to MediaTemple (https://bgp.he.net/AS31815#_peers)

Sonic does not peer with Level3 (https://bgp.he.net/AS7065#_peers)

You experience slowdown to the site from both Sonic and Comcast.

I tried from a Comcast business connection and barely get beyond 500K to that site after a brief burst but can get much faster speeds to other sites. From a Linode to the site (with a traceroute that does go over 4.14.98.38) I'm able to download the file at 25.5MB/s.

The issue doesn't seem isolated to Sonic so there's not much they can do. MT is the common denominator between testing on the Sonic and Comcast Network.

[waxriot]

Thanks, it sounds like I'm not being clear that I don't expect a fix from Sonic, just a quick informative response, and I finally have what I need. [Modulo hoping for contacting the culprit if relevant/possible.]

The critical info on the issue is the observation that Media Temple has a direct relationship with Level3 that Sonic does not, which helps me deal with Media Temple now.

It seems like that could have all been settled in one or at most 2 brief support calls, but, speaking as an engineer, perhaps the sense that it wasn't Sonic's fault overrode the ability to listen carefully and diagnose the problem, particularly in the face of way faster and much more informed (if not completely informational) support at the end point.

As I suggested, maybe this level of service belongs in its own business, but it used to seem like Sonic was more supportive, maybe it's just another kind of issue from what I had in (what happened to be) DSL days.

** Now digesting the Linode data rate, which seems to let everyone off the hook, in my tiny, anomaly-driven view. Can you post the Linode trace and wget rate for me to show MT?

Following the peering info shows multiple MT peers, wonder what's up with those relationships since I don't know the business,

https://bgp.he.net/AS31815#_peers

but looking deeper, here's a tool for ping/traceroute from Level3 sites around the world, with some results that are interesting tho not revelatory:

https://lookingglass.level3.net/

ATLANTA GA USA Traceroute results for:
70.32.90.126 (70.32.90.126)

Tracing route to 70.32.90.126
1 0.0.0.0 (0.0.0.0) * * ae-2-4.bear2.Washington111.Level3.net (4.69.210.170) 11ms
2 4.14.98.38 (4.14.98.38) 12ms 12ms 12ms
3 e3.1.cr01.iad01.mtsvc.net (70.32.64.102) 11ms 11ms 12ms
4 e1.4.as01.iad01.mtsvc.net (70.32.64.250) 11ms 21ms e1.4.as02.iad01.mtsvc.net (70.32.64.246) 11ms
5 vzs355.mediatemple.net (70.32.95.10) 13ms 21ms 22ms
6 70.32.90.126 (70.32.90.126) 23ms 23ms 23ms

LONDON ENGLAND Traceroute results for:
70.32.90.126 (70.32.90.126)

Tracing route to 70.32.90.126
1 0.0.0.0 (0.0.0.0) * * *
2 4.14.98.38 (4.14.98.38) 74ms 74ms 74ms
3 e3.1.cr01.iad01.mtsvc.net (70.32.64.102) 73ms 73ms 73ms
4 e1.4.as01.iad01.mtsvc.net (70.32.64.250) 711ms 172ms 87ms
5 vzs355.mediatemple.net (70.32.95.10) 73ms 73ms 73ms
6 70.32.90.126 (70.32.90.126) 73ms 73ms 74ms

TOKYO JAPAN Traceroute results for:
70.32.90.126 (70.32.90.126)

Tracing route to 70.32.90.126
1 ae-1-11.bear2.Washington111.Level3.net (4.69.210.178) 161ms 161ms 161ms
2 4.14.98.38 (4.14.98.38) 162ms 162ms 162ms
3 e3.1.cr02.iad01.mtsvc.net (70.32.64.110) 162ms 161ms 161ms
4 e1.4.as02.iad01.mtsvc.net (70.32.64.246) 170ms 161ms 161ms
5 vzs355.mediatemple.net (70.32.95.10) 161ms 161ms 161ms
6 70.32.90.126 (70.32.90.126) 161ms 161ms 161ms

A ray of yay-Sonic news: no trackers on this page.

Screen Shot 2018-05-25 at 4.12.25 PM.png (24.97 KiB) Viewed 2291 times

[waxriot]

Media Temple's download speed came back after about a month, as claimed, but I'm switching to inMotion, and here's a comparison of scp bandwidth over routerless Sonic fiber:

copy current site down to laptop:
web.tz 100% 1040MB 12.9MB/s 01:20
from laptop up to new site:
web.tz 100% 1040MB 45.2MB/s 00:23

And MT->InMotion, no Sonic, both in LA thay say:

web.tz 100% 1040MB 22.6MB/s 00:46

So from one angle, Sonic consumer bandwidth SF-LA is twice as fast as commercial bandwidth between these two hosts in the cloud in LA. Cool!