CQM Graphs: Difference between revisions

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

[[File:Cqm-screen-shot-notes.png|80px|frame1200px|CQM Graphs]]

Staff are able to add 'Pinspins' 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.

Optionally, Staffstaff can enable ICMP ping graphs,. theseThese will graph a normal ping to the customer WAN IP address. TheseThey tend to have a salmon colourcoloured background:

Customers wouldmay need to allowset their firewall to allow ourpings LNSsfrom tous; sendcurrently we ping them, currentlyfrom 90.155.53.51 - 90.155.538.54

(Not an ADSL Faultfault.) The example above showshows 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 (10Mbit10 Mbit/s)

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 300ms300 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.

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 Engineerengineer to atend site.

(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 ofor bad wiring on site. Check things like the phone line and extensions. Put the router ininto the master socket and to unplug all other phones. Maybe change filter.

===Heavy Packetlosspacket loss===

[[File:Cqm-packetloss-contactfault.png|none|frame|This line has loss due to a Batterybattery Contactcontact Faultfault. A copper line test suggestsuggests that this should be reported to Openreach as a fault.]]

This is a rather strange one. There is packetlosspacket loss when downloading, however the download is not filling the link, but there is still loss,. thisThis is unusual. This turned out to be congestion on the Virtualvirtual Pathpath within BT, or it may have been miss-configuredmisconfigured. It took our escalation staff 3three months to convince BT that the fault was within their network.

*18:20 EndThe end user was doing some tidying up of wiring and accidental disconnected one of the wires that make up the pair used for the phone line

**The line dropped a few times and reconnected, but the sync speed dropped to from 20M20 Mbps up and 80M80 Mbps down to 600K600 kbps up and 23M23 kbps down!

**At thethis point, the end user noticed something was not right.