If I were a shady engineer at netflix who got oders from the top that they wanted to lower the overall cost of support, I would write a script that randomly throttles x percentage of speedtest clients, to offload the support request back onto the ISPs, knowing that netflix is now a life saving utility to be protected by god, ultimately providers will purchase more bandwidth or better pipes closer to netflix handoffs, lowering the corporate overall delivery costs. but then again, im kind of a dick
On Fri, Oct 7, 2016 at 12:17 PM, Paul Stewart <p...@paulstewart.org> wrote: > Or more importantly what DNS you are using vs your customers … that > doesn’t matter so much with streaming but might (not sure) with fast.com > speedtest > … I’ll have to look into that > > On Oct 7, 2016, at 1:01 PM, Robert Andrews <i...@avantwireless.com> wrote: > > Your GDNS entry at netflix is throwing you to the wrong server in the > wrong geographic area? Did you look at the traceroute to where the test > and netflix servers are going? > > On 10/07/2016 09:15 AM, Chris Wright wrote: > > I have a couple customers who are testing poorly at fast.com, yet their > speeds are great on speedtest.net servers. Naturally they claim Netflix > constantly buffers and accuse me of throttling Netflix � we�re doing no > such thing. For giggles I kicked their SM for a moment and put their > pppoe account in a laptop at the NOC, set the throttle exorbitantly high > (100mbps) and let it rip. 2mbps to fast.com, 99mbps everywhere else. > Testing an adjacent IP in the same subnet will do 99mbps at both > fast.com and speedtest.net. > > I would be on the phone with my upstream asking questions if other IPs > in the same subnet were experiencing the same results. This whole thing > feels like Netflix is targeting individual IPs with a throttle hammer. > Any ideas here? > > Chris Wright > > Network Administrator > > > -- If you only see yourself as part of the team but you don't see your team as part of yourself you have already failed as part of the team.
