Kitz ADSL Broadband Information
adsl spacer  
Support this site
Home Broadband ISPs Tech Routers Wiki Forum
 
     
   Compare ISP   Rate your ISP
   Glossary   Glossary
 
Please login or register.

Login with username, password and session length
Advanced search  

News:

Pages: 1 ... 5 6 [7] 8 9 ... 11

Author Topic: My line might have issues?  (Read 39697 times)

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: My line might have issues?
« Reply #90 on: October 22, 2017, 07:09:36 PM »

Without looking at all the stats and graphs, would you actually notice any problem?

If it resulted in fairly moderate to heavy interleaving being enabled such as INP 4 and delay 12ms or worse (like my first line), yes. Speed probably a bit less and ping would definitely be higher. Not preferable. I can tolerate INP 3 delay 8ms, but anything more aggressive than that is not nice. If I was just a simple web surfer sure, I wouldn't care at all either way, but I'm not just someone who does simple browsing to places like Facebook or just check emails.

If I had the choice to keep fastpath without DLM meddling with my line, I would also be fine with that, but DLM is like some kind of secret locked down box that nobody can open up except OR.

I realise OR probably has the understanding of generally accepting interleaving as a solution to some broadband issues, but in reality it's something used to mask a problem and a quick and sloppy workaround.
« Last Edit: October 22, 2017, 07:11:55 PM by Ixel »
Logged

ejs

  • Kitizen
  • ****
  • Posts: 2078
Re: My line might have issues?
« Reply #91 on: October 22, 2017, 07:39:07 PM »

but in reality it's something used to mask a problem and a quick and sloppy workaround.

This seems to be a fashionable opinion to state and copy, but I think in reality it's that broadband technologies use a lot of complicated processing tricks to make it work over some bits of wire that really weren't designed for it, and error correction is a part of that. The error correction capabilities of FEC/interleaving are not always a bad or unwanted aspect. People seem to assume that the level of FEC errors is going to directly equate to the level of CRC errors if the FEC were removed, and the overhead used to carry the FEC data is all wasted bandwidth that you'd get to use if the FEC were taken away. But it doesn't quite work like that.

The solution to DLM adjusting your line seems to be to adjust your line even more than the DLM would do yourself. For another solution that's worse than the problem, how about ordering a 40/10 service instead of 80/20?
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: My line might have issues?
« Reply #92 on: October 22, 2017, 10:23:06 PM »

Interleaving is a useful technology, but I think we all not going to agree on how it should be implemented.

My personal view is it should be used as a temporary means of masking a problem until a proper solution is put in place (generally fixing line issues, implementing crosstalk prevention etc.), interleaving could also be useful for seeing if the line itself is the cause of problems such as if problems go away if interleaving is applied.  I dont think it should ever be used as a long term solution to problems like openreach use it for.  Openreach seem to use interleaving as a tool to "hide" line problems, very likely for financial reasons.  Openreach is the service provider so ultimately what they set as the spec is what we have to deal with.

For this reason we cannot simply say that if a line is using interleaving then its a faulty service because it is not.  My issue with ixel's line is when he last posted his fast path stats, he was exceeding the daily ES rate in one single hour, and to boot this is happening on a moderately short line as well.  There is something somewhere injecting some serious noise onto that line. 

For me personally interleaving is service affecting, web browsing is noticeably slower, services like netflix take longer to hit max resolution and download speeds are reduced.  But again we have to look at what openreach considers service affecting, if things are "slower" then they wont consider it service impacting unless the sync speed is extremely low (yes I consider the handback threshold extremely low, its a very lowballed figure).  But of course many people are just used to interleaving for several years so dont notice it or are perhaps less sensitive than myself to performance issues.

All this seems to come back to the way the UK market has gone, its a market where operating costs are aggressively been minimised to support the type of price levels that ofcom want in the market. Openreach especially has been squeezed as their revenue for each line has actually gone down in real terms over the past 5 years.

ejs, a 40/10 fast path service is actually faster than a interleaved 80/20 service for most activities due to the lower latency, dns lookups are quicker, tcp sessions establish quicker, and speeds ramp up quicker.

If my own line ever hit the problem ixel has and I hit a brickwall getting it back to fast path I would very likely downgrade the product just to get it back on fast path.
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: My line might have issues?
« Reply #93 on: October 23, 2017, 10:25:30 AM »

This seems to be a fashionable opinion to state and copy, but I think in reality it's that broadband technologies use a lot of complicated processing tricks to make it work over some bits of wire that really weren't designed for it, and error correction is a part of that. The error correction capabilities of FEC/interleaving are not always a bad or unwanted aspect. People seem to assume that the level of FEC errors is going to directly equate to the level of CRC errors if the FEC were removed, and the overhead used to carry the FEC data is all wasted bandwidth that you'd get to use if the FEC were taken away. But it doesn't quite work like that.

The solution to DLM adjusting your line seems to be to adjust your line even more than the DLM would do yourself. For another solution that's worse than the problem, how about ordering a 40/10 service instead of 80/20?

G.INP for example, which I think many Huawei DSLAM's have had the fortune of having for a long time now, is a good technology. I don't mind traditional interleaving if it's just INP 3 delay 8ms at most but even then I notice the effect it has. Some people don't notice it, some do. So like Chrysalis said, I too feel it's service affecting and should only be used as a temporary means of keeping a connection stable but not as an actual solution which OR appear to be relying on it for sometimes.

AAISP doesn't offer a 40/10 service on Soho::1 2TB from what I can see, but even then I would like to keep the upload speed. I could however artificially cap the connection via the modem, e.g. 60/20, 55/20, or whatever speed shows more stability on fastpath when using a modem other than the DrayTek currently.

Interleaving is a useful technology, but I think we all not going to agree on how it should be implemented.

My personal view is it should be used as a temporary means of masking a problem until a proper solution is put in place (generally fixing line issues, implementing crosstalk prevention etc.), interleaving could also be useful for seeing if the line itself is the cause of problems such as if problems go away if interleaving is applied.  I dont think it should ever be used as a long term solution to problems like openreach use it for.  Openreach seem to use interleaving as a tool to "hide" line problems, very likely for financial reasons.  Openreach is the service provider so ultimately what they set as the spec is what we have to deal with.

For this reason we cannot simply say that if a line is using interleaving then its a faulty service because it is not.  My issue with ixel's line is when he last posted his fast path stats, he was exceeding the daily ES rate in one single hour, and to boot this is happening on a moderately short line as well.  There is something somewhere injecting some serious noise onto that line. 

For me personally interleaving is service affecting, web browsing is noticeably slower, services like netflix take longer to hit max resolution and download speeds are reduced.  But again we have to look at what openreach considers service affecting, if things are "slower" then they wont consider it service impacting unless the sync speed is extremely low (yes I consider the handback threshold extremely low, its a very lowballed figure).  But of course many people are just used to interleaving for several years so dont notice it or are perhaps less sensitive than myself to performance issues.

All this seems to come back to the way the UK market has gone, its a market where operating costs are aggressively been minimised to support the type of price levels that ofcom want in the market. Openreach especially has been squeezed as their revenue for each line has actually gone down in real terms over the past 5 years.

ejs, a 40/10 fast path service is actually faster than a interleaved 80/20 service for most activities due to the lower latency, dns lookups are quicker, tcp sessions establish quicker, and speeds ramp up quicker.

If my own line ever hit the problem ixel has and I hit a brickwall getting it back to fast path I would very likely downgrade the product just to get it back on fast path.

I agree. I can't downgrade the speed from what I can see however, but I could always artificially cap the speed via the modem itself if I want to use something other than the DrayTek currently. This isn't the real solution though of course.

The Zyxel VMG1312-B10A is arriving this morning so we'll see what that does. I'll also inform AAISP shortly, just giving them some time to possibly get back to me regarding the data I sent on Saturday.

EDIT: B10A plugged in and should be uploading to MDWS now. Errors are through the roof and QLN looks rather interesting. I'm using the supplied RJ11 cable just as further elimination of doubt that any of my cables are damaged. QLN hasn't uploaded though so I'll post it here.

https://i.imgur.com/pq3NYgZ.png
« Last Edit: October 23, 2017, 01:13:04 PM by Ixel »
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: My line might have issues?
« Reply #94 on: October 23, 2017, 02:10:48 PM »

I've been told another SFI engineer will be coming tomorrow, fingers crossed they can identify the problem this time.

Apparently service test passed fine but there are errors on Yukon (DSL diagnostics facility?). TTB tried to escalate but couldn't as service is too new I think, but contacted the OR SMC and want the D side investigated by the engineer, the errors to be cleared and a co-op with TTB's assurance team. In the meantime I've left the Zyxel connected for collecting statistics, no doubt interleaving will say good morning to me again tomorrow :P.

For the SFI engineer I will also leave the Zyxel in place as the only modem on display. I'll pack up the DrayTek, ECI /r and HG612 and put them in a cupboard.
Logged

burakkucat

  • Respected
  • Senior Kitizen
  • *
  • Posts: 38300
  • Over the Rainbow Bridge
    • The ELRepo Project
Re: My line might have issues?
« Reply #95 on: October 23, 2017, 05:44:43 PM »

I've just taken a quick look via MDWS (both QLN & Hlog are now visible) and noticed that the high frequency tail-end droop of the Hlog plot has returned. It is an enigma and only seems to appear on circuits connected to an ECI Hi-FOCuS Mini-Shelf M41 MSAN.
Logged
:cat:  100% Linux and, previously, Unix. Co-founder of the ELRepo Project.

Please consider making a donation to support the running of this site.

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: My line might have issues?
« Reply #96 on: October 23, 2017, 06:28:09 PM »

I've just taken a quick look via MDWS (both QLN & Hlog are now visible) and noticed that the high frequency tail-end droop of the Hlog plot has returned. It is an enigma and only seems to appear on circuits connected to an ECI Hi-FOCuS Mini-Shelf M41 MSAN.

Are you certain? I still see my old QLN when I check. I also see the date/time say 'as of 12 Oct 2017 23:57'. Maybe my browser is caching the 'current' output somehow? But yeah, the tail-end droop is there on the latest Hlog when I check DSLstats.

AAISP also told me to call them tomorrow if I want them to discuss this matter with the engineer when he/she is here. I'll probably do that if I find the engineer can't find a problem on his/her tester (which I expect) and isn't 'co-op' with TTB as TTB requested. However fingers crossed things will go better this time and some progress will be made, even if it's not fixed tomorrow I'll just be happy if the engineer agrees there's a fault somewhere on Openreach's network and that they need to arrange for a fix. I'm just hoping I don't get the same SFI engineer again, god help me if I do haha. Fortunately I've not been handed any SFI related charges yet and AAISP are staying on top of this matter unlike Zen.
Logged

tbailey2

  • Kitizen
  • ****
  • Posts: 1245
Re: My line might have issues?
« Reply #97 on: October 23, 2017, 08:11:26 PM »

If you look closely at your SNRM plot then you'll see that you are not uploading anything at 57m to the hour which is when the various tone related files are uploaded. This is usually due to a timeout in DSLStats. Anything in the Event Log? Your uploads take place currently at 20s past the minute which should be fine. It's also unusual on a Windows machine and more common on an RPi.

So what has possibly changed since the last okay upload on 12 Oct?

You could try stopping the current upload and then restarting at about 50s to the minute so it pauses and restarts early in the minute offering maximum processing time.
Logged
Tony
My Books!
Plusnet 80/20 - DSLstats - HG612/TG582n - ECI

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5717
Re: My line might have issues?
« Reply #98 on: October 23, 2017, 08:19:18 PM »

Few things you could maybe mention to the engineer, to show you know your stuff kind of thing  ;)

Ask him/her to run the 'Auto-protective PQT test', this will highlight a potential HR fault that a 'Standard PQT' may miss.

Ask what the leg-balances are from that same test (A very good circuit will be within 3ohms of each other).

Ask the same about the AC Balance figure ...... anything over 55dB is ok, if it's in the 60's it's great. Bear in mind, it depends on the cable make-up (Ali or Copper)  as to what this figure will be ??.

After they have performed their mandatory 'DSL Close out test', ask if they wouldn't mind running the basic xDSL test whilst using the landline on 'Quiet Line Test' and again whilst ringing the landline number.
Personal experience shows that there is more chance of seeing errors when just connected to the DSLAM in the Exchange (xDSL test), than connected to the RAS (DSL Close out test).

Of course, they don't have to do any of the suggestions I've made .... but any engineer worth his salt will generally listen to the EU and try to satisfy their requests, so long as it isn't silly and massively time-consuming, (we are after all monitored on task-times, although not as harshly these days).

My suggestions above (the xDSL test to DSLAM only) will add approximately 10 more mins over and above the mandatory PQT and DSL Close out tests.

Hope this helps ??.  :)



Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: My line might have issues?
« Reply #99 on: October 23, 2017, 09:38:23 PM »

If you look closely at your SNRM plot then you'll see that you are not uploading anything at 57m to the hour which is when the various tone related files are uploaded. This is usually due to a timeout in DSLStats. Anything in the Event Log? Your uploads take place currently at 20s past the minute which should be fine. It's also unusual on a Windows machine and more common on an RPi.

So what has possibly changed since the last okay upload on 12 Oct?

You could try stopping the current upload and then restarting at about 50s to the minute so it pauses and restarts early in the minute offering maximum processing time.

I've started and stopped DSLstats a few times lately so maybe something's got confused. I'm running DSLstats from a Docker container on my Synology NAS. Perhaps something has just got confused and I need to restart the container itself. I'll restart the container and if not then also try what you suggested. Thanks!

EDIT: QLN and Hlog have now uploaded and show for me.

Few things you could maybe mention to the engineer, to show you know your stuff kind of thing  ;)

Ask him/her to run the 'Auto-protective PQT test', this will highlight a potential HR fault that a 'Standard PQT' may miss.

Ask what the leg-balances are from that same test (A very good circuit will be within 3ohms of each other).

Ask the same about the AC Balance figure ...... anything over 55dB is ok, if it's in the 60's it's great. Bear in mind, it depends on the cable make-up (Ali or Copper)  as to what this figure will be ??.

After they have performed their mandatory 'DSL Close out test', ask if they wouldn't mind running the basic xDSL test whilst using the landline on 'Quiet Line Test' and again whilst ringing the landline number.
Personal experience shows that there is more chance of seeing errors when just connected to the DSLAM in the Exchange (xDSL test), than connected to the RAS (DSL Close out test).

Of course, they don't have to do any of the suggestions I've made .... but any engineer worth his salt will generally listen to the EU and try to satisfy their requests, so long as it isn't silly and massively time-consuming, (we are after all monitored on task-times, although not as harshly these days).

My suggestions above (the xDSL test to DSLAM only) will add approximately 10 more mins over and above the mandatory PQT and DSL Close out tests.

Hope this helps ??.  :)

Many thanks for the suggestions! I'll try to mention this if they seem to be having issues finding a fault again. I don't know about all of the above, but I think the engineer last Friday did one of the suggestions you mentioned (xDSL test while running Quiet Line Test). I recall him, well, sort of complaining about how the AAISP's landline QLT just cuts off after around two minutes. Unlike how other landlines usually run, AAISP's landline is just an automated message that happens shortly after you pick up the phone and lasts around two minutes with a man saying "quiet line test".
« Last Edit: October 23, 2017, 10:07:00 PM by Ixel »
Logged

Chrysalis

  • Content Team
  • Addicted Kitizen
  • *
  • Posts: 7382
  • VM Gig1 - AAISP L2TP
Re: My line might have issues?
« Reply #100 on: October 24, 2017, 02:12:07 AM »

22k plus errored seconds in 11 hours on a line with 18db attenuation, absolutely crazy.  Never seen such a thing on any line before.

Black Sheep seems to have offered some very good advice as well, I think I will keep the notes from his post for if I ever need a engineer in future.
« Last Edit: October 24, 2017, 02:17:47 AM by Chrysalis »
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: My line might have issues?
« Reply #101 on: October 24, 2017, 10:35:59 AM »

22k plus errored seconds in 11 hours on a line with 18db attenuation, absolutely crazy.  Never seen such a thing on any line before.

Black Sheep seems to have offered some very good advice as well, I think I will keep the notes from his post for if I ever need a engineer in future.

Indeed it is, well hopefully the engineer will find something this afternoon. If they appear to be struggling I'll try Black Sheep's useful suggestions first and if not then I'll call AAISP and ask them to talk with the engineer (as they offered to do so). Something's wrong but it's a matter of it being 'detected'. I'm sure the engineer's tester modem will once again show a normal/fair amount of error seconds and CRC errors again, but as soon as I plug in the HG612, Zyxel VMG1312-B10A or the ECI /r with LEDE I'll see them back again in huge amounts. It's a day of fine rain today by the looks of it so maybe that'll help highlight a problem. It was also raining yesterday but only light rain.

I was on the AAISP IRC recently and one or two members were of the opinion that I should just stick to the DrayTek and accept things as they are as it's a 'best efforts' service. Just a nice excuse if you ask me. However if the second visit fails to find a fault then I will probably do that unless AAISP still wish to chase this matter further. They're aware of the DrayTek and engineer's tester modem working fine as I've explained this to them and they're still chasing to get this matter resolved, so I have a feeling they won't give up easily :).
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: My line might have issues?
« Reply #102 on: October 24, 2017, 02:24:50 PM »

Few things you could maybe mention to the engineer, to show you know your stuff kind of thing  ;)

[truncated]

Engineer's been, he was a very talkative and helpful person unlike the one I had last Friday. He actually did pretty much all of what you suggested too and gave me the information from the auto-protective PQT test :).

AC DC Voltage (all legs) 0v

Insulation Resistance (A to B?) 11.08 Mohm

A to E 3.89 Mohm

B to E 3.02 Mohm

Disc Comp (forgot what the full wording of this one was, something capacitance?) 150 nf

A to E 202 nf

B to E 100% capacity

Loop Resistance A to B 504

A to E and B to E 427

AC Balance 68.5 dB


Sorry if some information is confusing, I had to write it down fairly fast :P.

Which from what you said and what the engineer said this afternoon indicates a very good quality?

He couldn't find a fault but agreed that the CRC errors and error seconds I've accumulated on fastpath on both the HG612 and Zyxel VMG1312-B10A are ridiculous. He agreed about the junction on the main road but it's a matter of 'when it breaks or enough people report problems' from what I was told. He also agreed that interleaving is just masking a problem and isn't a solution. He offered to try to do a pair swap but given some other neighbours (I informed him) also told me they've had some kind of an issue with their broadband connection then the chances are that a pair swap will just make matters worse, so we both agreed not to do that. He's going to highlight the junction on the main road to Openreach as he suspects the previous SFI engineer didn't even highlight it. I've also emailed AAISP about what happened, will wait to see what they say.
Logged

Black Sheep

  • Helpful
  • Addicted Kitizen
  • *
  • Posts: 5717
Re: My line might have issues?
« Reply #103 on: October 24, 2017, 03:11:05 PM »

Hi ....

Yeah, the figures there aren't 'uniform' in the way they are presented ...... but I totally get the gist of what they are saying and yes, as far as the auto-indicative PQT test goes ... you have a damned good pair of wires !!

In a nutshell, working down the list ..........

Your circuit has no 'battery contact' issues and obviously not connected to the mains voltage either  ;).

Your circuit has no short circuit/resistive short circuit condition, and neither any kind of 'Earth contact fault', as the IR (Insulation Resistances) are all mega-ohm values.

The "Disc Comp" is actually 'Dis Capacitance' and I can tell you now, there's not many circuits that get tested will have a perfect 100% value !!

The only thing I don't understand (and I appreciate you had to write them down hastily), is the 'Loop resistance' value and subsequent A to E ... B to E values.
The loop resistance of 504ohms, should then see a perfect circuit being A to E at 252ohms, and B to E at 252ohms ..... in other words each 'leg' or each wire if you will has the same resistance value for the entirety of its length. Again, something as rare as Unicorn sh1t for the most part !!But fear not, the 'Dis Cap' test mentioned above is as good an indicator as the 'Loop res' test.

An AC Bal of 68.5 is very, very good.

So, all-in-all ...... I wouldn't want that pair of wires swopping going off those results. As mooted previously though, there are a tiny percentage of lines that still error even on lines like yours. Did the engineer perform the xDSL test and run a 'QLT' at the same time ?? That really is the only way left to try and force the circuit to error ??

 
Logged

Ixel

  • Kitizen
  • ****
  • Posts: 1282
Re: My line might have issues?
« Reply #104 on: October 24, 2017, 03:54:40 PM »

Hi ....

Yeah, the figures there aren't 'uniform' in the way they are presented ...... but I totally get the gist of what they are saying and yes, as far as the auto-indicative PQT test goes ... you have a damned good pair of wires !!

In a nutshell, working down the list ..........

Your circuit has no 'battery contact' issues and obviously not connected to the mains voltage either  ;).

Your circuit has no short circuit/resistive short circuit condition, and neither any kind of 'Earth contact fault', as the IR (Insulation Resistances) are all mega-ohm values.

The "Disc Comp" is actually 'Dis Capacitance' and I can tell you now, there's not many circuits that get tested will have a perfect 100% value !!

The only thing I don't understand (and I appreciate you had to write them down hastily), is the 'Loop resistance' value and subsequent A to E ... B to E values.
The loop resistance of 504ohms, should then see a perfect circuit being A to E at 252ohms, and B to E at 252ohms ..... in other words each 'leg' or each wire if you will has the same resistance value for the entirety of its length. Again, something as rare as Unicorn sh1t for the most part !!But fear not, the 'Dis Cap' test mentioned above is as good an indicator as the 'Loop res' test.

An AC Bal of 68.5 is very, very good.

So, all-in-all ...... I wouldn't want that pair of wires swopping going off those results. As mooted previously though, there are a tiny percentage of lines that still error even on lines like yours. Did the engineer perform the xDSL test and run a 'QLT' at the same time ?? That really is the only way left to try and force the circuit to error ??

Hi,
Thanks for the feedback! That's good to hear I have an excellent pair of wires and am glad I didn't go ahead with trying a pair swap. No way will I be letting this pair be swapped then :P.

Yes, the engineer did perform an xDSL test and QLT and like my DrayTek router for some reason it handles the problem and shows no real indication of a fault as such, where on my HG612, ECI /r with LEDE firmware and finally a brand new Zyxel VMG1312-B10A I see thousands of error seconds in a short timeframe (approximately 1 error second for every 5 seconds of uptime). The engineer agreed that the chances of all the other devices I tried showing excessive errors actually being faulty is very unlikely. I'm just stumped. I mean I could always just only use my DrayTek and I'll probably have few issues, it's just a bit frustrating to know there's something not right somewhere but there's no test which can identify the cause currently.

I'll leave it up to AAISP as to decide what to do next as I realise this is going to be very tricky. I know they've tried so I won't blame them in the slightest if they say to me that there's nothing more they can do at this time. They're currently waiting for the engineer notes before deciding on how it's best to proceed. Once again thanks for the feedback and suggestions :).
Logged
Pages: 1 ... 5 6 [7] 8 9 ... 11