CQM Graphs: Difference between revisions

Line 3:

The FireBrick 6000 routers we use provide us with Continuous Quality Monitoring of every broadband circuit. This allows us to track the quality of each and every connection in great detail. The router itself produces the graphs in real time, and can also provide csv files with accurate data for each graph.

Customers and ~~Staff~~ can view these graphs in near real time (updated every 100 seconds), and can view historical graphs.

Customers and staff can view these graphs in near real time (updated every 100 seconds), and can view historical graphs.

{{CPbox|#Click on the line you want to view

Line 24:

===Pins===

Staff are able to add '~~Pins~~' to graphs. This is a useful way of adding notes to particular times on a graph. We used to let customers add their own pins, but this feature has been removed for the time being.

Staff are able to add 'pins' to graphs. This is a useful way of adding notes to particular times on a graph. We used to let customers add their own pins, but this feature has been removed for the time being.

=ICMP Graphs=

Optionally, ~~Staff~~ can enable ICMP ping graphs, ~~these~~ will graph a normal ping to the customer WAN IP address. ~~These~~ tend to have a salmon ~~colour~~ background:

Optionally, staff can enable ICMP ping graphs. These will graph a normal ping to the customer WAN IP address. They tend to have a salmon coloured background:

[[File:Cqm-icmp.png|none|frame|An graph created from ICMP Pings to a WAN address]]

Line 39:

[[File:CQM1.png|none|frame|Lots of upload at the end of the day]]

(Not an ADSL ~~Fault~~.) The example above ~~show~~ a line with occasional short uploads causing spikes in peak latency, and then a sustained upload starting at around 6pm and causing high latency (queue in the router). At 8pm there was more upload filling the link causing higher latency still and some loss (normal when the link is full). This is normal. Also see: [[Packet Loss]]

(Not an ADSL fault.) The example above shows a line with occasional short uploads causing spikes in peak latency, and then a sustained upload starting at around 6pm and causing high latency (a queue in the router). At 8pm there was more upload filling the link causing higher latency still and some loss (normal when the link is full). This is normal. Also see: [[Packet Loss]]

Here is another, an FTTC line filling the up link whilst doing a backup (~~10Mbit~~/s)

Here is another, an FTTC line filling the up link whilst doing a backup (10 Mbit/s)

[[File:CQM-FTTC-upload.png|none|frame|Lots of upload in the morning - a backup without any traffic shaping on the client end]]

This line is doing a large backup from just before 6am. The dark red horizontal line shows the traffic, during this time there is lots of packet loss (red) and the light blue at the bottom is showing high latency. So, whilst the backup is happening the line has about 50% packet loss and around ~~300ms~~ of latency. Using the line for things like web browsing at this time will be slow and sluggish. However, this is not a fault per-se. It is normal for a line to appear slow when it's being filled with traffic. However, this traffic may be unknown, it may not be a backup, but could be a virus or peer-to-peer traffic. You can do a [[Traffic Capture]] to see what the traffic is, or ask Support to Help.

This line is doing a large backup from just before 6am. The dark red horizontal line shows the traffic, during this time there is lots of packet loss (red) and the light blue at the bottom is showing high latency. So, whilst the backup is happening the line has about 50% packet loss and around 300 ms of latency. Using the line for things like web browsing at this time will be slow and sluggish. However, this is not a fault per-se. It is normal for a line to appear slow when it's being filled with traffic. However, this traffic may be unknown, it may not be a backup, but could be a virus or peer-to-peer traffic. You can do a [[Traffic Capture]] to see what the traffic is, or ask Support to Help.

===Redcare===

Line 72:

[[File:Cqm-dropping2.png]]

This line does have a fault. It is dropping sync throughout the day. In this type of case, go through the usual checks, and AAISP will report a fault, which will probably need a BT SFI ~~Engineer~~ to atend site.

This line does have a fault. It is dropping sync throughout the day. In this type of case, go through the usual checks, and AAISP will report a fault, which will probably need a BT SFI engineer to atend site.

===Only Dropping during the day===

[[File:CQM4.png]]

(Probably not an ADSL Fault.) If a line is dropping during the day, and maybe just Monday to Friday, then it's probably not going to be an upstream problem. This could be caused by interference of bad wiring on site. Check things like the phone line and extensions. Put the router in master socket and to unplug all other phones. Maybe change filter.

(Probably not an ADSL Fault.) If a line is dropping during the day, and maybe just Monday to Friday, then it's probably not going to be an upstream problem. This could be caused by interference or bad wiring on site. Check things like the phone line and extensions. Put the router into the master socket and unplug all other phones. Maybe change filter.

===Interleaving being applied===