12,270
edits
This is the support site for Andrews & Arnold Ltd, a UK Internet provider. Information on these pages is generally for our customers but may be useful to others, enjoy!
(10 intermediate revisions by 3 users not shown) | |||
__NOTOC__<indicator name="Diagnostics">[[File:menu-spanner.svg|link=:Category:
The
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
#Clicking on the graph again will show
==How does it work?==
Our router sends an LCP echo (a bit like a ping) every second while a line is active. Your router replies. We track how long it takes for each reply to arrive, and how many are lost. These results are collated into 100 second samples and shown as a graph like the one on this page. The graph shows us lots of information about the line, and gives a history covering the last 24 hours.
==What information is on the graph?==
[[File:Cqm-screen-shot-notes.png|
Each column (pixel) represents 100 seconds of samples. The hour of day is shown at the bottom, and the day and date shown next to midnight in the graph. There is additional text superimposed on the graph such as a circuit ID. There are 8 pieces of data shown for each 100 second sample as follows:-▼
▲Each column (pixel) represents 100 seconds of samples. The hour of day is shown at the bottom, and the day and date shown next to midnight in the graph. There is additional text superimposed on the graph such as a circuit ID.
===A note on Tx/Rx download/upload===
===Pins===
=ICMP Graphs=
(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]]
Here is another, an FTTC line filling the up link whilst doing a backup (
[[File:CQM-FTTC-upload.png|none|frame|Lots of upload in the morning - a backup without any traffic shaping on the client end]]
[[File:CQM-FTTC-DIS-in-one-leg.png|none|frame|FTTC running on just a single leg/wire]]
Here we have a perfectly good FTTC, running at 80M. However, in the evening the line goes rather crazy! Here is what happened:
*18:20 End user was doing some tidying up of wiring and accidental disconnected
**The line dropped a few times and reconnected, but the sync speed dropped to from 20M up and 80M down to 600K up and 23M down!
*The line continued working for a short while, up until:
===Affect of adjusting the 'rate' setting===
[[File:Cqm-ratedrop.png|none|frame|Example of changing the line rate from 100%-95% reduced average latency when filling the link when downloading]]
===Running a speed test every 15 minutes===
[[File:Cqm-speedtest15mins.png|none|frame|Running an automated speed test every 15 minutes - not a fault, but the test fills the link and causes loss so will be service affecting]]
==Other Examples==
|[[File:Cqm-dropping.png]]
|Going off line is shown in purple, and this is often associated with packet loss (red). Where a line has occasional drops they are shown as purple lines. However, in some case a line can deteriorate over a period of time, staying on line less and less until solid purple (off line). On the live graphs a line that is currently off line has a red square in the bottom right corner where as a line that is on-line has a green square.
|-
|[[File:Cqm-congestion.png]]
|
edits