Latest from Network Reliability/Testing & Assurance/Cybersecurity/Safety

ISE Columnist Don McCarty, OSP Expert

What Is a Good DSL Circuit?

July 1, 2016
This month’s OSP Expert is written by guest author and DSL expert Vernon May. I work with Vernon, of Vernon May Solutions, providing training and consulting services. A while ago, […]

This month’s OSP Expert is written by guest author and DSL expert Vernon May. I work with Vernon, of Vernon May Solutions, providing training and consulting services. A while ago, we began discussing the parameters for defining a good DSL circuit. We hope you find this month’s column helpful — and please, please, please, send us any follow-up questions or comments.

Don and I get a skewed view of the DSL troubles encountered in the field. Often, we are called in as the last resort. Therefore, we work with the most difficult troubles (and the smartest technicians). Granted, these troubles are pretty rare, but when they happen, they can be an expensive fix. This is not because the fix itself is expensive. It is because the steps to find the root cause are expensive. This includes the failed experiments with modem, port, and cable pair replacement.

We believe that these oddballs have to be accounted for in the test criteria, and that requires us to use different data points than most people do. In our classes, we show how to use these data points in real-world applications. This subject matter is too broad to cover in this column, but it does beg the question: What really is a good DSL Circuit?

My background is approximately 20% lab and 80% field evaluation. It is my belief that labs let you compare one technology to another very well because they deliver constants. However, they only offer clues toward determining how the technology will actually work under field conditions because constants are so rare. Therefore, "Good" and "Bad" have to be determined using live network data that include the impact of OSP conditions.

These conditions are changing all day and every day. That makes traditional fixed thresholds too narrow to be accurate. The response has been to add more fixed thresholds, with the end designs being still too narrow and now too complicated. We saw a recent example of how focusing on 1 threshold can fool us.
• DSL Bit Rates and signal-to-noise ratio margin or SNRM were good at time of testing.
• Service would degrade to very slow Bit Rates over time and then improve later.
• Copper looked good (not all McCarty tests were performed).
• Forward Error Correction (FEC) was high, but no other errors.
Naturally, the technician was focused on the FECs. I was thinking impulse
• We did find some impulse noise when the water pump and refrigerator came on, but only 3 to 5 hits per instance with the threshold being -45 dBm.
• There is a 66 block in the house. BTW: DSL and 66 blocks are not friends. Cut them out. We did.
• The power ground and telco ground were not bonded, so we ran a temporary on the ground, but using the proper hardware.
• Then, the modems would not sync. The handheld tester would not sync and the customer modem would not sync.
• We went back to the NID, tugged on the drop wire (which had not been redone during the grounding change, but had almost certainly been touched) and it broke off in our hand, so that connection was redone.
• The FEC count was not impacted.

Two days later, the FECs had gone above 9,000,000, but the service never became slow. I believe that the FECs were a red herring. I am convinced that the high resistance open in the drop wire was the root cause of the bit rate slow down.

How does the high resistance open cause these symptoms? First of all, this type of fault changes with temperature changes. Also, that circuit is ADSL2+ and therefore compensating for the changing circuit conditions. Seamless Rate Adaptation (SRA) reduces the bit rate per second in order to stabilize the circuit. This happens without the modems being forced to re-sync (unlike ADSL1).

Note: a gentle tug on every wire when you are testing is a good practice. We work with very small conductors and our wire stripping practices are often ignored.

What about the FECs? There were no uncorrected blocks, so the circuit is handling field conditions just fine. OSP variables alone preclude the expectation of perfection. Throw in the fact that the "5 DSL circuits per binder group" rule was shattered before the ink was dry. With up to 25 DSL workers in a binder group (and yes, we have seen it) and all of the circuits impacting one another, reliable service is our best hope.

Because of variable power, variable attenuation over all of the DSL frequencies, variable DSL crosstalk and SRA, DSL circuits have to be judged over 24-hour periods, and with floating comparative thresholds.

A Good DSL ADSL2+ Circuit
1. Is the circuit in sync? (duh)
2. Has not dropped sync more than once within the past 24 hours. WARNING! Customers often have a habit of resetting the modems when they have chronic trouble.
3. Bit Rates never drop below 80% of target, and hover between 95% and 100% in a 24-hour period.
4. SNRM never drops below 4 dB, and hovers around 8 dB in a 24-hour period.
5. SNRM does not vary more than 15% in a 24-hour period.
6. Unavailable Seconds (UAS) less than 80 in a 24-hour period.
7. Severely Errored Seconds (SES) less than 300 in a 24-hour period.
8. Has maintained the 24-hour criteria above for 7 days.

There are as many theories on this subject as there are experts to ask, but I would feel comfortable with any circuit meeting this criteria being the lifeline for my mother.

What if we see a circuit that meets all of the other criteria in a 24-hour period, but there are 302 SES? Well, a little common sense goes a long way in the circuit evaluation process. We might look at the other days for trends in this data point, but we don’t call the circuit "bad" because one reading is slightly out of line. Naturally, dropping sync more than once a day should be taken more seriously than a slight SES overage.

How can we get away with using only 8 data points for the "good/bad" determinations? We are focusing on how the DSL circuit is reacting to field conditions and not individual data points. However, it must be said that we use up to hundreds of data points during the trouble-root-cause analysis process, if the circuit is "bad". So, we don’t disregard the traditional data points — we simply use them differently.

We often adjust our positions when new information becomes available. Still, our definition of "good" had held up to scrutiny for several years now, so we feel comfortable with sharing it. Please, inform us of any indications that you see to the contrary.

Signing Off
Vernon and I are presenting at ISE EXPO 2016 (formerly OSP EXPO) Sept. 20-22 in San Antonio, TX, On Tuesday, Sept. 20, we are providing an IPTV Workshop from 10 a.m. to 12:00 noon. On Wednesday, Sept. 21, at 9:15 a.m., we are presenting a DSL seminar. So watch for these and many more fantastic events and keynotes. Do you want to meet up with Vernon or me at ISE EXPO? Let us know: text or call 831.818.3930 or email [email protected].

Vernon May has created and implemented telecommunications technology on 6 continents for over 35 years, and has leveraged his service provider and vendor experience into that of trainer/coach, inventor, systems designer, program manager, product manager, and plant operations expert. He currently holds 2 US Patents, including #8,027,807 B2 on Remote DSL Circuit Evaluation. If you have questions about your DSL, you are welcome to contact him at your convenience at 254.979.4749 or email [email protected]. For more information about Vernon May Solutions LLC, please visit

About the Author

Don McCarty

Don McCarty is the OSP EXPERT columnist for ISE magazine, discussing the issues around provisioning, testing, and maintaining copper for all services from POTs to IPTV. Don is also president of and the lead trainer for McCarty Products, a technical training and products company training field technicians, cable maintenance, installation repair, and Central Office technicians and managers. For more information, email [email protected] or visit