vraag

Packet Loss met Glasvezel

  • 13 mei 2020
  • 19 reacties
  • 323 keer bekeken

Reputatie 1

--- dreamchip.de ping statistics ---
196 packets transmitted, 164 received, 16.3265% packet loss, time 196095ms
rtt min/avg/max/mdev = 19.517/19.700/21.892/0.202 ms

--- google.com ping statistics ---
729 packets transmitted, 714 received, 2.05761% packet loss, time 729387ms
rtt min/avg/max/mdev = 3.812/343.109/25103.560/2531.361 ms, pipe 25

--- 195.190.228.38 ping statistics ---
980 packets transmitted, 980 received, 0% packet loss, time 203516ms
rtt min/avg/max/mdev = 0.395/0.543/4.358/0.271 ms

 

Ip 195.190.228.38 is the first router outside my house, thus belonging to Telfort/KPN. This proves indirectly that there is nothing wrong with my PC and my fiber connection.

Any idea what is happening?

 

Best regards,

Octavian

P.S. This situation appeared several months back.

 

 

 

 


19 reacties

Reputatie 8

P.S. This situation appeared several months back.

What is the situation today?

Reputatie 1

Situation today:

 

traceroute to dreamchip.de (217.160.0.254), 30 hops max, 60 byte packets
 1  ns1.linux.private (192.168.1.1)  0.122 ms  0.073 ms  0.090 ms
 2  195.190.228.38 (195.190.228.38)  1.598 ms  1.639 ms  1.764 ms
 3  * * *
 4  rt2-rou-1022.nl.eurorings.net (134.222.129.238)  2.385 ms  2.378 ms  2.938 ms
 5  ldn-s2-rou-1101.uk.eurorings.net (134.222.48.200)  9.907 ms  9.891 ms  9.883 ms
 6  * * *
 7  ae-4.bb-b.bap.rhr.de.oneandone.net (212.227.120.49)  24.637 ms  19.910 ms  21.684 ms
 8  port-channel-3.gw-distd-sh-1.bap.rhr.de.oneandone.net (212.227.122.3)  21.354 ms  21.411 ms  21.589 ms
 9  * * *
…...
30  * * *

7 and 8 do not reply to ping. 1 is mine.

2, 4 and 5 ping results does and the results are below:

--- 195.190.228.38 ping statistics ---
297 packets transmitted, 297 received, 0% packet loss, time 303097ms
rtt min/avg/max/mdev = 0.403/0.654/6.380/0.722 ms

--- 134.222.129.238 ping statistics ---
914 packets transmitted, 914 received, 0% packet loss, time 914031ms
rtt min/avg/max/mdev = 4.084/4.559/22.577/0.977 ms

--- 134.222.48.200 ping statistics ---
391 packets transmitted, 378 received, 3.32481% packet loss, time 391053ms
rtt min/avg/max/mdev = 10.215/508.030/18827.370/2566.972 ms, pipe 19

--- dreamchip.de ping statistics ---
302 packets transmitted, 250 received, 17.2185% packet loss, time 302754ms
rtt min/avg/max/mdev = 19.528/19.938/25.672/0.827 ms

 

It looks like more and more packets are lost.

 

P.S. For consistency here is also the google result

--- google.com ping statistics ---
304 packets transmitted, 304 received, 0% packet loss, time 303325ms
rtt min/avg/max/mdev = 3.805/4.080/8.864/0.670 ms

 

 

 

 

 

 

Reputatie 8

“Between” servers often do not reply to ping requests, but still packets are send forward.
So look to the last hop and total amount of send packages.

Test yesterday 13-05-2020
Ping test to dreamchip.de    directly    during about 2.5 minutes sending pings
Round trip 21-22 ms

 

Ping traceroute yesterday 13-05-2020 (using other tool)  -  sending 100 packets:
(100 packets received at the end).

 

Ping traceroute today 14-05-2020  -  first attempt  -  sending 100 packets:
(100 packets received at the end).

 

Ping traceroute today 14-05-2020  -  second attempt  -  sending 100 packets:
(100 packets received at the end).

 

And now, what do you want to do or what is your expectation?

Reputatie 1

What I see is that you also have packet loss for dreamchip.de from 1% to 6%.

More interesting is that the in-between server 134.222.48.200 shows 3% loss for me but 0% for you.

 

So somewhere, some server until 134.222.48.200 is dropping some packets.

 

You do have a different first router 195.190.228.157 while I have 195.190.228.38

 

So would be nice to see who is dropping the connection….

 

139.156.98.101 is suspicious. It drops quite a lot of packages

 

My expectation is that I have no packet loss at least for the main servers (like google/etc.)

 

 

Reputatie 8

As written more early:

      “Between” servers often do not reply to ping requests, but still packets are send forward.
     So look to the last hop and total amount of send packages.


As seen in the third picture, IP address 139.156.98.101 even didn’t respond to any ping request.
In spite of it all 100 packets are forwarded and reached to the very end.

Question for you again:
What do you want to do or what is your expectation by these results?

Reputatie 1

      “Between” servers often do not reply to ping requests, but still packets are send forward.
     So look to the last hop and total amount of send packages.

I am aware of this. But if the servers reply, there should be no packet loss, shouldn’t be?

The routing (between) servers are found by sending ping packets with short TTL to the destination server. Since the TTL is decreased each hop, when TTL reaches zero the “inbetween” server replies instead of the destination server.

 

To find the first hop a TTL=1 is set for the ping packet. For the second hop a TTL=2 and so forth. 

The traceroute/tracepath is using TTL to determine the routing servers from source to destination.

 

Some “inbetween” servers indeed do not reply at all, but when reply they should reply always. Either 100% packet loss or no packet loss.

In your graph some of the ones which reply show packet loss<100%. Anything less than 100% is a concern. If there is 100% packet loss then I know the server is most likely ignoring the ping. But if packet loss is 99% or 75% or 6% I am worried.

 

What do you want to do or what is your expectation by these results?

My expectations is: no packet loss 0% or 100% (if the server is not replying).

Reputatie 8

Some “inbetween” servers indeed do not reply at all, but when reply they should reply always.
Either 100% packet loss or no packet loss.

Also that is not truth.  At least as by the explanation of KPN / Telfort itself.
Often written about comparable issues in past.
 

My expectations is: no packet loss 0% or 100% (if the server is not replying).

And now that it is NOT, what are you doing about it??
Nobody is listening or changing it.

Reputatie 1

 or 100% (if the server is not replying).

And now that it is NOT, what are you doing about it??
Nobody is listening or changing it.

Said isn’t it? Would be nice if they would guarantee < 1% packet loss... for example.

Few years back I did not have such issues.

I now wonder if this is due to some “new technique” of bandwidth increase by dropping packets…especially UDP ones.

Anyway I wrote the post, if somebody from Telfort is curious enough they will do some research.

The fact that nobody from Telfort answered is also an answer in itself.

 

Thank you for your time again.

Octavian

Reputatie 8

Said isn’t it? Would be nice if they would guarantee < 1% packet loss... for example.

Few years back I did not have such issues.

Aside from measuring it by some utilities / tools, did you ever feel you had real difficult issues in normal daily speed internet connection?

A few days ago I did a Ping Plotter to the US: It did take  91-92 milliseconds  back and forth

Some centuries ago it did take many months to have “some” comparable “human connection”. :wink:

Reputatie 1

Aside from measuring it by some utilities / tools, did you ever feel you had real difficult issues in normal daily speed internet connection?

 

Yes, MS Teams drops every minute of so. This is how I started the investigation.

Reputatie 8

I wonder if it has something to do by packet loss?? As by normal internet connections there is a control system for lost packages, and shall be sent again if not received.

What kind of internet connection do you have “copper” or glass fibre?  Specially “copper” is prone to failures by often bad used “telephone” cable, instead of good quality shielded cables with twisted cores inside.  (“Telephone”cable is prone to electromagnetic interference).

What kind of modem/router model?
Cable connection or WiFi?

In spite of also some packet loss I tested within the above examples I have no problems by conferencing comparable software (TeamViewer), or VPN connections etc. (I can stream movies for hours by VPN of many TerraBytes without loss or broken connections).

Reputatie 1

I wonder if it has something to do by packet loss?? As by normal internet connections there is a control system for lost packages, and shall be sent again if not received.

What kind of internet connection do you have “copper” or glass fibre?  Specially “copper” is prone to failures by often bad used “telephone” cable, instead of good quality shielded cables with twisted cores inside.  (“Telephone”cable is prone to electromagnetic interference).

What kind of modem/router model?
Cable connection or WiFi?

In spite of also some packet loss I tested within the above examples I have no problems by conferencing comparable software (TeamViewer), or VPN connections etc. (I can stream movies for hours by VPN of many TerraBytes without loss or broken connections).

  1. Glas fiber
  2. Gentoo Linux. running on Intel(R) Core(TM)2 Duo CPU E8500  @ 3.16GHz (PCI Realtek r8169 network card)
  3. Cable connection only
  4. (connection is stable until 3rd hop outside my house)
Reputatie 8

KPN/Telfort shall not do anything for 3rd hop.

Still strange that MS Teams doesn’t work properly / “drop” connection, as some congestion and / or packet loss always can happen by normal internet data connections. Software should correct it.

What kind of modem/router model?
Experia Box V8 is reaching its lifespan and is getting more and more troubles in general as can be found by many user messages at the forum. (You can try for a general reset for V8).

Reputatie 8
Badge +12

Have you already tried Babylonia's latest tips? 

Reputatie 1

Have you already tried Babylonia's latest tips? 

I can not do that since I have my own rooter Gentoo Linux running on Intel(R) Core(TM)2 Duo CPU E8500  @ 3.16GHz (PCI Realtek r8169 network card)

I think the key to this is
https://forum.telfort.nl/internet-267/packet-loss-met-glasvezel-87209?postid=733226#post733226

where more and more packets are lost on the route to dreamchip.de

Cam somebody have a look at 134.222.48.200 which is still in KPN hands?

Reputatie 8

Can somebody have a look at 134.222.48.200 which is still in KPN hands?


Ping round trip with some tiny “spikes” in it.  (Just a tiny bit slower 19 / 20 ms instead 12 ms).
Nothing to be worry about it.
 

 

Ping Plotter:
 

 

 

Using MS Team, much is done by TCP protocol (checking for sending data packets).
https://docs.pexip.com/admin/teams_planning.htm#ports

Check witch protocols are used or what is used for a reliable “hand shake” connection.

See also:
https://en.wikipedia.org/wiki/Transmission_Control_Protocol

https://en.wikipedia.org/wiki/User_Datagram_Protocol

Reputatie 8
Badge +12

In a ping trace it's normal that not every packet gets response. Just like Babylonia already said. And you are using your own router. If you replace it with ours. Does the problem still occurs? Only then I can help. 

Reputatie 1

In a ping trace it's normal that not every packet gets response. Just like Babylonia already said. And you are using your own router. If you replace it with ours. Does the problem still occurs? Only then I can help. 

See my comment.

https://forum.telfort.nl/internet-267/packet-loss-met-glasvezel-87209?postid=733313#post733313

 

all ping requests are working properly now. But in the past it did not:
See: https://forum.telfort.nl/internet-267/packet-loss-met-glasvezel-87209?postid=733226#post733226
 

--- dreamchip.de ping statistics ---
234 packets transmitted, 234 received, 0% packet loss, time 233313ms
rtt min/avg/max/mdev = 19.417/19.506/20.402/0.108 ms

--- 134.222.48.200 ping statistics ---
421 packets transmitted, 421 received, 0% packet loss, time 420499ms
rtt min/avg/max/mdev = 10.014/10.462/22.697/0.857 ms

 

Reputatie 8
Badge +12

So the problem is solved now al ping requests are working fine?

Reageer