Read the forum guidelines
I've had a technician come in he did nothing, then he said he'd send out a field expert. Of course this did nothing as well. I have been wrestling with this issue for almost 3 months now please help!
There's a ping plotter from my modem
I believe it is connected with AWS, here is a tracert to AWS west (188.8.131.52)
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms 192.168.1.1 2 16 ms 9 ms 10 ms 10.71.32.1 3 18 ms 9 ms 9 ms 100.120.104.132 4 11 ms 12 ms 25 ms 100.120.104.12 5 36 ms 12 ms 19 ms 184.108.40.206 6 10 ms 11 ms 14 ms 220.127.116.11 7 36 ms 20 ms 25 ms 18.104.22.168 8 10 ms 19 ms 13 ms 22.214.171.124 9 36 ms 35 ms 39 ms 126.96.36.199 10 * * * Request timed out. 11 48 ms 53 ms 38 ms 188.8.131.52 12 35 ms 44 ms 49 ms 184.108.40.206 13 58 ms 60 ms 75 ms 220.127.116.11 14 38 ms 36 ms 37 ms 18.104.22.168 15 37 ms 54 ms 36 ms 22.214.171.124 16 * * * Request timed out. 17 * * * Request timed out. 18 * * * Request timed out. 19 * * * Request timed out. 20 * * * Request timed out. 21 * * * Request timed out. 22 * * * Request timed out. 23 * * * Request timed out. 24 * * * Request timed out. 25 * * * Request timed out. 26 * * * Request timed out. 27 * * * Request timed out. 28 * * * Request timed out. 29 * * * Request timed out. 30 * * * Request timed out.
So can you explain why this fix goes away when i go to a iphone hotspot or go to a friends house with cox and I don't get packet loss there?
In Ping Plotter, you can adjust the trace route protocol. Try switching from normal "ping" requests to UDP packets.This can be found under "Edit" --> "Options" --> "Packet" - change the "Packet Type" option to "UDP Packets".
Cox likes to deflect blame when packet loss is occurring by arguing that normal trace route data is invalid because some hops drop normal ping requests due to them being low priority. While is can be true, changing the packet type will avoid this blame game entirely.
UDP packets are usually connectionless packets in that they do not return a reply. However, when UDP packets are sent to a normally unused UDP port number, the system sending the UDP packet will receive a reply from the destination server essentially saying "UDP packet recieved, but invalid port" - thus showing accurate, non-deprioritized packet travel and undoubtedly showing valid packet loss data.
Long story short, change your packet type in Ping Plotter, restart your test while wired into your router, and if you get the same results you can be assured that it is most likely routing problems by Cox or infrastructure problems. I've been seeing infrastructure problems for the last 4 months on another thread here - amazingly, they have not been able to fix my packet loss - which looks a lot like the data you posted above - even though this has been an ongoing officially reported issue for 1/3 of a year.
So you can't fix this problem cox?