Where to start?
In regards to the link to your house.
The DSL modem is running at a far higher data rate than is allotted to your internet access.
A DSL modem can not shift on the fly depending on how much (fill in the blank) needs.
To change speeds, it needs to reboot and re-establish the connection.
The balancing/partitioning of data flow from the static pipe is software based.
With DSL there is always transmission errors, that require error correction or retransmission of data.
If noise increases, and you have to have more retransmissions, then those retransmissions cut into the available downstream bandwidth.
You have a choice. Do you have the bandwidth management software take the reduction in available bandwidth from the internet side, or the DTV side.
If the DTV side has some spare link capacity then you can use that for retransmissions of DTV data that had uncorrectable errors.
And in that choice, you don’t really have a choice, if the DTV pipe is already full. DTV is a real time continuous data stream. You can’t pause
it. The internet side is interactive. It can handle slow downs. So it is the internet side that gets throttled back to deal with transmission link
problems.
On the backbone issue
There is on network, an off network.
The DTV services are located on the network you are on.
They are being provided to you by pioneer.
The internet access is off network.
The connection to that relies on the bandwidth they purchase from upstream providers to support the load.
If you are having high latency and poor internet connectivity at peak times, they are not purchasing enough bandwidth from their upstream provider.
Depending on how many GB per second the projected peak is verses the limited amount, you can calculate how much they are saving a month by letting
capacity hit the hard limit instead of having enough extra capacity to have spare capacity during the peak times.
Example: If they need an additional 5GB per second to have headroom during the highest peaks, they may be saving $25,000 a month by not buying that
capacity.
If the first tracert you posted.
1 13 ms 11 ms 12 ms 10.11.0.1
2 14 ms 11 ms 17 ms 208-117-3-209.block5.gvtc.com [208.117.3.209]
3 12 ms 12 ms 12 ms 208-117-3-198.block5.gvtc.com [208.117.3.198]
4 11 ms 10 ms 12 ms 208-117-2-5.block5.gvtc.com [208.117.2.5]
5 14 ms 15 ms 12 ms 208-117-2-18.block5.gvtc.com [208.117.2.18]
6 324 ms 333 ms 339 ms 12.116.42.213
7 391 ms 406 ms 383 ms tbr2.hs1tx.ip.att.net [12.123.134.46]
That looks line the provider is not purchasing enough capacity form upstream.
In the second tracert.
51 ms 50 ms 50 ms 65-255-64-1.dyn.hsi.pldi.net [65.255.64.1]
2 192 ms 243 ms 355 ms docgw-portchan10.pldi.net [64.250.192.1]
3 88 ms 86 ms 86 ms so-10-3.hsa1.Dallas1.Level3.net [209.246.148.185]
4 81 ms 94 ms 88 ms vlan52.csw2.Dallas1.Level3.net [4.68.122.62]
5 203 ms 318 ms 234 ms ae-23-79.car3.Dallas1.Level3.net [4.68.19.69]
6 79 ms 81 ms 81 ms level3-gw.dlstx.ip.att.net [192.205.34.137]
There is no problem.
That 203 to 318 on the second hop isn’t actual time. Notice the hop after it is returning at around 81 ms It can’t get to point six without
passing point 5 first. The reason for the 200 to 300 ms hop is the router is just being a bit slow at returning pings, it isn’t actually taking that
long to pass traffic. When ever you see a downstream hop returning faster than the closer hop, then you can ignore the time on the closer hop because
the router is not returning pings in a timely manner.
In the third tracert, I can’t tell because he didn’t include enough jumps.