Forum Discussion

5 Replies

Sort By
  • sjo102784's avatar
    sjo102784
    Contributor
    6 years ago

    romanpat I tend to see the same results when running Ping Plotter to AWS nodes, they do drop ICMP requests at a 100% rate due to them being "low priority".  What I normally see when I'm seeing severe packet loss is packet loss percentages on each of the hops that are reporting between my modem and the destination:

    That image shows 13% packet loss at each of the hops between my modem and the destination. 

    A few things to try when testing from your location:

    • If you can, try having a dedicated system run the testing 24/7.  I have a system hard wired to my router/modem all day, every day as a check for outages. 
    • If you can't test 24/7, I would suggest having a test running during peak times (nights/weekends) and/or when you're trying to play games/stream/etc.
    • Try changing the packet type from normal ICMP (ping - which is typically dropped by servers as low priority) to either UDP or TCP port 80 packets.  If nodes between you and your destination are dropping UDP or TCP packets, there is an inarguable problem as they are not treated as low priority packets. 
    • RomanPat's avatar
      RomanPat
      Contributor
      6 years ago

      In the video above I specifically in the packet selection selected UDP. Now in the video above there is packet loss before the packets reach the final hop where of course it would be 100%. 

      So the fact is I need to document this more and more over this weekend and try to provide this to cox.

      And again the above was UDP and thus they can't give me the run around that its ICMP

      As in respect to this"

      • If you can, try having a dedicated system run the testing 24/7.  I have a system hard wired to my router/modem all day, every day as a check for outages. 
      • If you can't test 24/7, I would suggest having a test running during peak times (nights/weekends) and/or when you're trying to play games/stream/etc."

      Is there a way I can capture my pings with ping plotter while actually playing the fortnite on my PC instead of just pinging a server?

      If there is can you help me with setting the test up. And if not would my best bet be to run UDP specifically to all different sorts of servers then test the aws ones to isolate the issue.

      • sjo102784's avatar
        sjo102784
        Contributor
        6 years ago

        As far as I know, you're only able to ping specific server hosts/IPs - not a specific Fortnite server.  The Fortnite servers may all fall under an umbrella IP (load balancing maybe) - if Epic can provide a server IP to use for network diagnostic purposes, I would suggest running Ping Plotter in the background at that IP while playing.  

        It really shouldn't be necessary, but if you record your session while running PP at an Epic server and can corroborate packet loss symptoms in game with the network diagnostic data, that would make the issue pretty evident.  

        I believe you can run PP to multiple targets simultaneously as well, which would be another way to demonstrate packet loss.  If you're seeing 10% packet loss to multiple targets at once and the PL%'s are all beyond your network, that would be obvious as a problem with either Cox's infrastructure or a partner's infrastructure (Level 3 for example, which I believe is owned by Century Link).

  • RomanPat's avatar
    RomanPat
    Contributor
    6 years ago

    Here is a tracert to the AWS West :

    Tracing route to ec2-52-42-109-244.us-west-2.compute.amazonaws.com [52.42.109.244]
    over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms 192.168.1.1
    2 9 ms 8 ms 8 ms 10.169.0.1
    3 18 ms 14 ms 13 ms 68.6.14.54
    4 22 ms 7 ms 8 ms 100.120.108.26
    5 14 ms 12 ms 12 ms 68.1.1.167
    6 12 ms 21 ms 11 ms 52.95.218.216
    7 35 ms 20 ms 32 ms 54.239.102.18
    8 46 ms 15 ms 15 ms 54.239.102.27
    9 37 ms 36 ms 36 ms 54.239.42.122
    10 * * * Request timed out.
    11 66 ms 72 ms 53 ms 52.93.12.162
    12 36 ms 37 ms 41 ms 52.93.12.145
    13 54 ms 55 ms 76 ms 52.93.12.36
    14 36 ms 39 ms 36 ms 52.93.12.59
    15 38 ms 42 ms 42 ms 52.93.240.59
    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.

    Trace complete.

    Look sketchy or anything lmk?

    • Becky's avatar
      Becky
      Moderator
      6 years ago
      Hi RomanPat, your PingPlotter video and traceroute seem to show normal ICMP deprioritization. Some servers may specifically block or down-prioritize ICMP echo requests. Corresponding traceroute hops might show 100% packet loss, or high packet loss and latency. You can tell it is just a case of the server in question taking its time to respond because true packet loss would impact all the remaining hops. The only hop that matters is the final hop. If the final hop is showing 0% packet loss and acceptable latency, then all the hops before that can show all kinds of errors and it doesn't matter. We know that some AWS servers block ICMP requests for security reasons, so the timeouts once the trace reaches the AWS network are to be expected. Your traceroute hits the AWS network at hop 6 (52.95.218.216). The traceroutes show no issues on the Cox network. -Becky, Cox Support Forums Moderator