Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[adslmax]

Hi can someone explain to me why is full fibre getting lots of packet loss as I am pretty sure that my previously FTTC and G.fast never get anything like this. The full fibre packet loss are pretty bad one.  Don't know if it was down to router or ont or exchange issues.

[tubaman]

Hi can someone explain to me why is full fibre getting lots of packet loss as I am pretty sure that my previously FTTC and G.fast never get anything like this. The full fibre packet loss are pretty bad one.  Don't know if it was down to router or ont or exchange issues.

What symptoms are you experiencing from this, because if the answer is none then just turn off the monitor and forget about it.

[Alex Atkin UK]

QoS in router?

Is your daughter noticing any issues when gaming, if not then I wouldn't really worry about it.

[kitz]

As I explained just a few days ago in another thread, using ping monitoring for FTTC/FTTH is often a red herring.
Many of todays routers have ICMP deprioritsation - meaning that the type of monitoring tools such as TBB which use ICMP ping can cause misleading results.

ICMP ping and tracert are meant to be diagnostic tool - not monitoring.  It sending requests asking your router "are you there?2". If busy doing something else.. or in some routers not even doing anything, the router always gives ICMP the lowest priority.  Its a good thing in that it ensures type 1 gets highest priority.  To save me retyping something out I repeat what I posted elsewhere

When you perform a tracert data packets are sent to the end point destination.
As the data packet moves along the pathway A <--> B,  at each hop a request is made to send a reply back to you informing you its IP address and that it is alive. The hop time is calculated as when you get back notification of the "is alive" message.

However some routers can (and do) get very busy.  When a router (hop) is very busy ICMP traffic has low priority and gets delayed compared to other types of traffic such as UDP and TCP. Most web traffic is TCP or UDP

TCP traffic : HTTP web browsing, web applications, SMTP email, FTP transferring files, SSH encryption, secure remote access.
UDP traffic : DNS, DHCP, VoIP voice and video traffic, streaming, online gaming

UDP traffic is time critical.  You physically notice if applications in this layer lose packets.  Telephone voice becomes sturrery, videos become pixelated and gamers scream. As such this type of traffic usually always gets priority.
TCP type traffic can sustain some error loss. Its connection oriented and can make use of error correction algorithms to recover a certain amount of data.
ICMP traffic is diagnostic used to check network and report destination unreachable errors.

By default, the vast majority of routers are configured to give ICMP type traffic the lowest priority.  This gives to situations where the data packet could have reached its final destination, but the hop which is busy still hasnt responded to its 'is alive' message. There is good reason to give ICMP low priority - some routers have ICMP totally blocked.  If you have a busy network of course you would want customers using it for a video chat with the grandkids to get priority over and above what are basically probes from an outside source wanting info about the router.

[kitz]

As mentioned by tubaman and Alex is it actually causing any problems?
By deprioritising ICMP monitoring - gaming is UDP and gets highest priority.

Can you perform a tracert to BBC so that we can see which hops may be either getting slowed down or prioritising traffic.

[adslmax]

Martin say there lots of issues in Telford at the moment as the work still ongoing for full fibre working in my area as this is the reason for my full fibre losing connection (loss of service in couple of days)

Using Linux Mint x64

Code: [Select]

traceroute to bbc.co.uk (151.101.64.81), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.233 ms  0.346 ms  0.493 ms
 2  lns1-ld8.lon.veloxserv.net (195.191.219.8)  6.821 ms  6.926 ms  6.964 ms
 3  xe4.core1-ld8.lon.as3170.net (103.141.25.204)  7.053 ms  7.677 ms  7.751 ms
 4  et-2-1-5.core1-ixn.lon.as3170.net (195.191.219.52)  22.901 ms  22.943 ms  22.982 ms
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

Code: [Select]

traceroute to sky.com (90.216.128.5), 30 hops max, 60 byte packets
 1  _gateway (192.168.1.1)  0.243 ms  0.356 ms  0.474 ms
 2  lns1-ld8.lon.veloxserv.net (195.191.219.8)  6.915 ms  7.329 ms  7.403 ms
 3  xe4.core1-ld8.lon.as3170.net (103.141.25.204)  7.513 ms  7.632 ms  7.670 ms
 4  et-2-1-5.core1-ixn.lon.as3170.net (195.191.219.52)  8.174 ms  8.831 ms  8.723 ms
 5  be1061.er13.thlon.isp.sky.com (5.57.81.128)  9.035 ms  9.327 ms  9.230 ms
 6  be1.ar0.gyhhe.isp.sky.com (2.120.9.1)  11.548 ms  11.238 ms  8.445 ms
 7  2.127.241.61 (2.127.241.61)  8.026 ms  8.189 ms  8.637 ms
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

[bkehoe]

What is the problem with these trace routes? There’s no packet loss or ping spikes between you and the internet. Looks very stable.

[adslmax]

I just saw the engineer working nearby underground full fibre chamber this morning and spoken to them is that my full fibre issues and he say yes he going to get it fixed but can't tell when it will be resolved.

Martin are saying he was seeing few customers has the same issues in my area and openreach inform him that's the full fibre ongoing work isn't completed yet.

[kitz]

It looks ok to me.

For comparison one done using an FTTC

Code: [Select]

Tracing route to bbc.co.uk [151.101.64.81]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    11 ms    11 ms    11 ms  254.core.plus.net [195.166.130.254]
  3    12 ms    12 ms    11 ms  213.120.163.16
  4    12 ms    12 ms    12 ms  217.32.240.95
  5    12 ms    12 ms    12 ms  core3-te0-12-0-13.faraday.ukcore.bt.net [213.121.192.102]
  6    13 ms    12 ms    16 ms  peer2-et4-0-5.slough.ukcore.bt.net [194.72.16.216]
  7     *        *        *     Request timed out.
  8    12 ms    15 ms    12 ms  151.101.64.81

and also if I do a tracert to you, it looks perfectly fine

Code: [Select]

Tracing route to 185-253-xxx-xxx.static.aquiss.com [185.253.xxx.xxx]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1
  2    11 ms    11 ms    12 ms  254.core.plus.net [195.166.130.254]
  3    12 ms    11 ms    12 ms  213.120.163.4
  4    11 ms    12 ms    12 ms  217.32.240.91
  5    12 ms    12 ms    12 ms  core1-hu0-15-0-6.ukcore.bt.net [213.121.192.80]
  6    12 ms    12 ms    12 ms  peer7-et-4-0-2.telehouse.ukcore.bt.net [194.72.16.124]
  7    12 ms    12 ms    12 ms  et-0-0-0.core2-thn.lon.as3170.net [195.66.227.195]
  8    13 ms    13 ms    13 ms  et-0-0-2.core1-thn.lon.as3170.net [195.191.219.46]
  9    12 ms    12 ms    38 ms  et-0-0-1.core2-ixn.lon.as3170.net [195.191.219.37]
 10    12 ms    12 ms    12 ms  te0-0.lns1-ixn.lon.as3170.net [103.141.25.207]
 11    18 ms    17 ms    18 ms  185-253-124-204.static.aquiss.com [185.253.xxx.xxx]

Trace complete.
These hops:

Code: [Select]

et-0-0-1.core2-ixn.lon.as3170.net [195.191.219.37]

VeloxServ Communications

et-2-1-5.core1-ixn.lon.as3170.net (195.191.219.52)
It looks like some of the core routers are occasionally being a bit slow to respond, but this is perfectly fine because hops after are showing no delay.
It would appear that these VeloxServ core routers de-priotorising ICMP. I stress that this is normal and you should not be worried about it. Normal TCP and UDP traffic passes through fine.  They are working exactly as designed.   To the un-experienced it might look like there is a problem when there actually isn't.  It's a good example of why ICMP ping and tracert can sometimes give a false impression of actual performance. 

[kitz]

I am concerned that now you have FTTH you are now fixating on ICMP ping based graphs.   I really can't stress hard enough just how unreliable these graphs can be becuase of ICMP deprioitisation.  They are good to perhaps help with network issues, but not always the best way to monitor actual connection performance.   

Are you actually having a problem with your connection that is noticable in real time..  OR is it that you think there is a problem just because the TBB monitor is showing ICMP delays? 

[adslmax]

OR working on the chamber got nothing to do with TTB monitor. We have lots of disconnected lately as Martin telling me I am not the only person other person in my area have the same issues. This is probably why the engineer working on the nearby full fibre chamber. 


So far since January 9th my full fibre has loss of connection 9th times now.


I leave my BMQ live here so you can see if there anymore loss of service
https://www.thinkbroadband.com/broadband/monitoring/quality/share/9db7eed163f0bf782da6cfea952cc9f359c020f1

[meritez]

Have you got an ipv6 address or just ipv4?

[adslmax]

Have you got an ipv6 address or just ipv4?

both

[tubaman]

You still haven't told us what actual problems you are seeing. Is your daughter seeing lag with gaming or are you seeing streams buffering for example? It appears that once again you are fixated on stats that as @kitz has said may not represent the actual performance of the connection. You have said you have had nine connection losses since you went live but if the one on your BQM is an example then it was few minutes in the middle of the night so hardly anything to get upset about, especially as they are still configuring the network in your area.

[jelv]

I have two tbb BQM's running, one to the router and one to my NAS box via it's IPv6 address which is connected to my router by cable.

The router's BQM consisistently has dripping blood. The only reason I have it running is so that I can see if the router is down (i.e. solid red) when I am away from home. 9/10 it means the power distribution box has tripped so anything in our freezer will perish. I ring the neighbour who has a key and ask him to check/reset the circuit breaker. The BQM to the router is of no use whatsoever other than showing me if it's down, and when it went down.

The BQM to the NAS box has not had a single drop of blood for the last week (other than when I restarted the router for another reason).