Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Register

Quick Links


Categories

In this Discussion

› › Online.net packet loss
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Online.net packet loss

hawchawc Moderator, LIR
edited January 2016 in General

Hi all,
A few people in the Online.net IRC are currently reporting packet loss. Just wondering if anyone else is seeing the same right about now? If so, please open a ticket so they have more evidence to take a look. I am seeing well over 20% loss on my box.

Edit: Seems to be outbound loss the most

Thanks
Harry.

«1

Comments

  • TrafficTraffic Member

    You can get tons of MTRs from many locations at ping.pe

    Thanked by 1Shade
  • doughmanesdoughmanes Member

    MTR to your server and MTR from your server will show this

  • hawchawc Moderator, LIR

    I have done that, and mailed support with it. I was wondering if anyone else was seeing the same.

  • NeoonNeoon Community Contributor, Veteran

    No Packetloss at my Kidichre.

  • GM2015GM2015 Member

    Maybe your server's around mine?

    ifconfig
eth0 
          RX bytes:86983861289506 (79.1 TiB)  TX bytes:533645888045 (496.9 GiB)
          Interrupt:28

    uptime
 14:04:42 up 28 days,  3:20,  2 users,  load average: 1.08, 1.15, 1.08
    Thanked by 1GCat
  • JWU42JWU42 Member
    edited January 2016

    No packet loss from server to home but seeing packet loss from home to server occurring in New York.

    EDIT - no issues from delimiter (ATL) to online.net in either direction.

  • doughmanesdoughmanes Member

    JWU42 said: No packet loss from server to home but seeing packet loss from home to server occurring in New York.

    One hop or from New York to the complete end? If it's one hop, it means the traffic is being deprioritized

  • GM2015GM2015 Member
    edited January 2016

    according to http://ping.pe, I get 19% packet loss from Romania. 1% from Litvania, others are all with 0% loss.

  • JWU42JWU42 Member

    @doughmanes - two specific hops ...

    9. if-26-2.tcore2.NTO-New-York.as6453.net 77.3% 22 122.8 118.4 115.1 122.8 3.6
    11. if-1-3.thar1.NJY-Newark.as6453.net 55.2% 30 115.9 118.6 112.2 130.8 5.4

  • GCatGCat Member

    @GM2015 said:
    Maybe your server's around mine?

    > ifconfig
> eth0 
>           RX bytes:86983861289506 (79.1 TiB)  TX bytes:533645888045 (496.9 GiB)
>           Interrupt:28
> 
    > uptime
>  14:04:42 up 28 days,  3:20,  2 users,  load average: 1.08, 1.15, 1.08
>

    Could also be around one of mine, one of mine has pushed over 80 TB

  • GM2015GM2015 Member

    Yeah, I'm just curling a 1000GB file to /dev/null every 3 hours. I looked at the logs and it took about 2:45 hours to curl 1000GB.

    I'm sure online.net and the target host appreciates the traffic.

    GCat said: Could also be around one of mine, one of mine has pushed over 80 TB

    Thanked by 1GCat
  • hawchawc Moderator, LIR

    It seemed to drop for a few minutes, and now we are back at to 40 % loss. Great. Glad I cancelled this box

  • SpacedustSpacedust Member

    Rock stable for me ;)

    Thanked by 1doughmanes
  • GCatGCat Member
    edited January 2016

    @GM2015 past 24 hours:

    RX bytes:737269973540 (686.6 GiB)

    TX bytes:20199455301031 (18.3 TiB)

  • hawchawc Moderator, LIR

    Welp, I had a phone call from support which went like this "Its not our problem". Yay! Glad I have this box cancelled. They wont accept responsibility for packet loss in their own network...

  • doughmanesdoughmanes Member
    edited January 2016

    JWU42 said: two specific hops ...

    "Packet loss" would be that hop and all the way to your server with continuous packet loss.

    AS6453 = HE

  • doughmanesdoughmanes Member

    hawc said: They wont accept responsibility for packet loss in their own network...

    You sadly don't understand what packet loss is even when I've explained it.

    Thanked by 1ManofServer
  • netomxnetomx Moderator, Veteran

    GM2015 said: Yeah, I'm just curling a 1000GB file to /dev/null every 3 hours. I looked at the logs and it took about 2:45 hours to curl 1000GB.

    I'm sure online.net and the target host appreciates the traffic.

    Why? I just don't get it. Why abusing that way?

    Thanked by 2Darwin Amitz
  • doughmanesdoughmanes Member

    @jarland can we get a Packet Loss 101 tutorial for LEB

  • GM2015GM2015 Member
    edited January 2016

    There are a lot of other uses for the kidechire.

    Backup storage, the ftp(free 100GB) is used, mysql, nginx, php5-fpm, socks proxy, squid3 and openvpn.

    So it's used and I want to see what traffic it can use in a month.

    And the curl script hasn't been running all the time anyway.

    netomx said:

    Why? I just don't get it. Why abusing that way?

  • jarjar Patron Provider, Top Host, Veteran

    @doughmanes said:
    jarland can we get a Packet Loss 101 tutorial for LEB

    Actually not a bad idea. So very often misunderstood.

    Thanked by 4GM2015 doughmanes netomx GCat
  • KrisKris Member
    edited January 2016

    Unless it continues 'down the line' it means completely nothing. You are seeing routers de-prioritizing ICMP packets.

    Next, perform a reverse MTR, in addition to the inbound path to actually get an idea of what's going on.

    e.g:

    mtr -r --report-wide -c50 IP_ADDR

    Do this on both sides, source IP to server, server to source IP. Then you will have some useful information for support, and see if it's a false positive, or on their side. Working with CT and CU customers & explaining the nuances of congested peering and Mainland China on a daily basis, commonly had to explain the true source of congestion, on the reverse path, usually well within CT / CU.

    Source : https://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf

    Thanked by 2doughmanes GCat
  • doughmanesdoughmanes Member

    Trying to avoid a certain somebody doing a chargeback against Online like how he did to other providers. Granted, the response from Online probably wasn't great but 5+ minute MTRs confirm the "loss" at hops which is deprioritization with HE however if you run a MTR from a provider who connects to Cogent, there's no issue.

  • colingptcolingpt Member

    @GM2015 @Traffic @GCat

    anyone know who run the ping.pe? quite good site and I use it often, but I didn't see any ads or "about info" on it. curious about who is running it.

    GM2015 said: So it's used and I want to see what traffic it can use in a month.

    btw, good reason to do so as the bandwidth is shared by others, do share the result, so we don't need to do it everyone themselves each month. :P

  • KrisKris Member

    colingpt said: anyone know who run the ping.pe? quite good site and I use it often, but I didn't see any ads or "about info" on it. curious about who is running it.

    >

    I want to say IT7 / BandwagonHost owner, I think I've seen it in his signature.

    Quite a brilliant site. I use Pulse Turbobytes myself. 100 locations instant MTR.

    Thanked by 2colingpt doughmanes
  • IshaqIshaq Member

    Kris said: I want to say IT7 / BandwagonHost owner, I think I've seen it in his signature.

    Yeah, @dcc runs it.

    Thanked by 3Kris netomx vimalware
  • RolterRolter Member

    I was getting these last month, but things seems to have gotten fine now .

    What i have observed is , this is mostly happening with extremely busy servers of mine .

  • ManofServerManofServer Member

    Did a MTR test for you - 0% packet loss.

  • doughmanesdoughmanes Member

    I ran 3 tests for the folks new to understanding packet loss: Comcast (uses HE) = showed "loss" in the hops but not 'true packet loss', OVH (Telia) = no loss, low end provider using Cogent = no loss.

    Thanked by 1ManofServer
  • tr1ckytr1cky Member

    Ishaq said: Yeah, @dcc runs it.

    Awesome, as everything else he runs.

    Thanked by 1netomx
Sign In or Register to comment.