The definition of unstable is: There were multiple instances of higher than expected latencies recorded when simultaneously seeing very little actual traffic on the line. This is unusual, and typically indicates a problem that should be looked into. The count of these instances is the last column, labeled 'Unstable Count'.
Here is how to interpret this section of the Customer Dashboard report:
The goal is to communicate the dates on which you line was flagged as 'unstable', as shown in the first column with a 'No', and when it was returned to a 'stable' status as indicated with a 'Yes' in the first column.
This is usually an indication that something upstream from the IQrouter is experiencing some issue and adding unnecessary latencies that are uncorrectable by the traffic manager. As noted in the initial summary, quite often this is due to traffic bypassing the IQrouter through the ISP-Supplied modem/router/WiFi box. So, if WiFi pops back on (or was never turned off), clients might be bypassing the IQrouter and causing bloat on the line. The fix is to ensure nothing but the IQrouter is connected to that box.
Otherwise, this is either a line issue or a modem issue. But it could also be further upstream in the backhaul (the link between the local DSLAM/CMTS and the central office). Here is the break-down of possibilities:
Modem: A failing modem will occasionally cause these high-latencies as the modem is having to constantly re-sync to the local DSLAM/CMTS. This can occur after thunderstorms or other electrical disturbances. Or sometimes, just a device going bad.
Special case: Bonded DSL, one of the DSL lines is weaker than the other, forcing frequent re-syncs to bring them both back into balance. The imbalance can be caused by any one of the line issues described below.
Line - Local: The wiring between a modem and the external demarcation point from the ISP on the side of the house. Loose connections, bad wire, moisture entering connections and causing temporary noise on the line can all make the modem have to resend or re-sync, adding latency.
Line - Link to DSLAM/CMTS: The wiring from the demarcation point on the home to the concentrator box down the road is experiencing an issue and again, forcing re-sends or re-syncs. On coax cable, it can be weak connections in the long run (can be multiple miles, with hundreds of taps), On DSL, it can be due to 'bridge taps' put in places where the wire has been previously cut and patched. Often, those splices induce signal loss when weather is wet or cold.
ISPs have tools to check for these issues, but care needs to be done to ensure they test under similar conditions. If it's raining and there are unstable line events, and then when dry and clear there are none, it's usually a sign of moisture affecting the link and should be tested by the ISP under similar conditions. Or they can accept the results of this report as evidence of a problem (many do).
Backhaul: Sometimes the link between the DSLAM/CMTS will experience a problem and cause all traffic to experience unexpected delays. Some DSLAMs use multiple individual lines to link back, and if one or more of them is having an issue, it causes this. Only the ISP can correct that.
Modems typically have a page to display the line statistics, showing the number of errors, how often, etc. that can be used to determine if it's the local loop (modem + line to the DSLAM/CMTS) or a backhaul issue (CMTS to the central office). So if few or no errors logged by the modem, then it's likely a backhaul issue.
So the sequence of rows in this report is usually an alternating pattern of Stable = No, followed by Stable = Yes, but occasionally will show Yes in succession, indicating that there were some higher-than-expected latencies, but not severe enough to flag the line as unstable. The metrics are recorded and reported to add to the data set and report. These are useful in seeing when problems are occurring, even if not severe.
Note that the system will send you an email if you have a valid email registered. If you do not yet have one registered, you can click the 'update registration' button on the overview page.
Also, these unstable events can be transient, and last a few hours to a few days, then stop. Usually, because the ISP is working on the line, or noticed the problem and went out and fixed it.
The rest of the columns are as follows:
Baseline latency: this is the lowest ping latency the IQrouter has measured through the line. It's not necessarily the average, that is shown on the Ping Stats report.
Actual Latency: this is the average latency measured during the period that it was above the threshold for stability. So across the Unstable count number of events logged for this entry, this was the average. Meaning the peaks could be much higher.
Actual Upload: is the amount of upload traffic (on average) seen during the high-latency events. The number usually a very low amount, never enough to itself be the cause of the issue.
Actual Download: Same as for upload, but reflecting download data volume.
QoS Up and QoS down: These are the then-current values set for the Traffic Manager. These are the 'speed limits' to prevent latencies due to congestion. While typically they are your max settings, they could be lower if the Dynamic adjustment or schedule had indicated lower values were in place at that time.
Server Date: this is the date of the occurrence per the server that logs the events (using UTC time-zone).
Local Date: this is the date of the occurrence per the IQrouter reporting the events (using the configured time-zone of the IQrouter).
Unstable Cnt: The count of low-level events in which the latencies exceeded the threshold to be considered for the login of this event. For rows listed as Stable line = No, it's how many times the IQrouter logged high latencies. A high number here indicates persistent modem and or line issues as discussed above.
For Stable Line = Yes, how many times the IQrouter saw reasonable values before determining the line can be qualified as stable.