Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Ixel]

Another update, I found in amongst all my spare bits and pieces that I had a rather long shielded RJ11 to BT cable, not desirable as it's quite long but I thought I'd try it anyway.

In terms of FEC errors per minute, so far I'm only getting what seems to be 250-350 on average, with a spike so far around 500. Before I was getting around 1000 per minute on average, sometimes spiking to 3000 or so. Attainable virtually the same, just 1 megabit less on the downstream mainly (probably due to the length of this cable). QLN overall however looks quieter and more flat than bumpy, with the exception for the ADSL2+ tones which is probably understandable. D3 in particular seems better with the spikes near the end no longer being there.

QLN comparison: https://imgur.com/a/BnPjQ

It's not had a lot of uptime yet, only 16 minutes at the time of posting this, so maybe it's a fluke. Looks better without a filter though.

Can't wait to see how AAISP's cable will perform.

EDIT: QLN graph might mean nothing, as I had D3 without the spikes in the past it seems. However FEC errors per minute are lower currently.

EDIT 2: The average after roughly 9 hours is about 20000 FEC errors per hour (or around 333 FEC errors per minute). That's a considerable drop compared to the average of roughly 60000 FEC errors per hour I was originally getting according to DSLstatsw. AAISP's cable is due to arrive this morning, Royal Mail just emailed me.

[Chrysalis]

Dont you have "unshielded" twisted cables? as shielded cable can make noise worse.

Ideally extremely short cable, twisted no shielding.

If the engineer stopped the errors by removing the faceplate then didnt he try to reattach your modem with that faceplate removed and then you leave it like that? why was the faceplate put back on?

It seems as if your engineers keep running out of time so stop before they finish.

For a line of your spec, on interleaving I would expect maybe a 100 or so FEC a day if its not too noisy or maybe a few thousand or even 5 digits for one day if its noisy, the amount you getting still seems way out of spec.

[Ixel]

Dont you have "unshielded" twisted cables? as shielded cable can make noise worse.

Ideally extremely short cable, twisted no shielding.

If the engineer stopped the errors by removing the faceplate then didnt he try to reattach your modem with that faceplate removed and then you leave it like that? why was the faceplate put back on?

It seems as if your engineers keep running out of time so stop before they finish.

For a line of your spec, on interleaving I would expect maybe a 100 or so FEC a day if its not too noisy or maybe a few thousand or even 5 digits for one day if its noisy, the amount you getting still seems way out of spec.

I have an unshielded twisted pair cable although I think it's over 2 meters long, I was using that. Yesterday night I was using the long shielded RJ11 to BT/LJU cable I found spare. About 30 minutes ago I plugged in the unshielded flat RJ11 to BT/LJU cable that AAISP sent and rate of FEC errors per minute so far seem a little higher than the cable I was using overnight. It's not enough time to really know for sure though. I've asked if it's possible to get DLM reset however so the test and comparison is fair.

It does seem as if the engineer ran out of time. Engineer notes were also interesting I think, see below.

Engineer notes from yesterday:
===Point Of Intervention notes===
At this point...
Plant details...
- Plant affected: PC100
- Plant type: PC
- Multiple Intervention?: N
===Point Of Intervention notes ends===
Is the fault caused by damage to BT plant within the customer's curtilage? - No
EU Setup ok modem (VDSL Modem connected to SSFP)? - Yes
VDSL modem powered up on arrival at EU premises? - Yes
Drop wire/lead-in testing ok to entry point? - Yes
Internal wiring testing ok? - Yes
SSFP Changed? - No
Service meets assured limits (speed up/down)? - Yes

Faulty dslam pairs causing high amount of errors on up and downstream. Possible split pair. Lift and shift to clear. Also d side changed out. Now speeds of 80/20. Jdsu has died so unable to Pqt, line was Pqt passing yesterday though ogea test shows nff Issue.

Following from TTB I think:
No errors yesterday evening and no data on Yukon for today yet. We will monitor further. Can you also please monitor and advise.

Although speeds are now 61/19 thanks to DLM. Yes of course errors aren't showing because INP 4 in both direction... lol.

As for the engineer and the faceplate, I suggested connecting it directly to the socket but I got the impression he didn't seem to think that was possible (or I'd need to buy a cable to do this perhaps?). I agree though, the amount of FEC errors per minute seem to indicate something is still there. I'll give it an hour or so and if the higher rate of FEC errors persist then I'll switch back to the cable I was using overnight, despite it being longer and shielded.

[Chrysalis]

So he is saying faulty tie pairs, interesting.

You can still monitor FEC when interleaved to have an idea of how well its working, the numbers you posted are extremely high.  I would say a DLM reset right now is fruitless.

Although interleaving may have fooled ttb into thinking its all good? as they have commented "no more errors"?

If you want a comparison, check skyeci's line back in october when he was interleaved and his FEC error rate.

I do agree tho there is a definite improvement on your FEC since the last visit.  The issue seems to be thats its a constant stream of noise, rather than occasional bursts.

Comparing to ronski's work line tho you could argue its ok. That work line has also a very high amount of FEC. But it is a much longer line.

[Ixel]

So he is saying faulty tie pairs, interesting.

You can still monitor FEC when interleaved to have an idea of how well its working, the numbers you posted are extremely high.  I would say a DLM reset right now is fruitless.

Although interleaving may have fooled ttb into thinking its all good? as they have commented "no more errors"?

If you want a comparison, check skyeci's line back in october when he was interleaved and his FEC error rate.

I do agree tho there is a definite improvement on your FEC since the last visit.  The issue seems to be thats its a constant stream of noise, rather than occasional bursts.

Comparing to ronski's work line tho you could argue its ok. That work line has also a very high amount of FEC. But it is a much longer line.

Yeah, true. They are high still yeah. I might put the long shielded wire back on since I think it performed a little better regarding FEC errors maybe, then again it's daytime now so maybe that's why the wire I'm currently using is now showing a slightly higher FEC error rate.

I mentioned the possibility of a DLM reset but AAISP want to leave things as they are for now. TTB won't see a problem I expect as I think Yukon and the GEA FTTC test don't show FEC errors and if they don't then that's probably intentional. I think I'm close to the point where everything possible that could be done has been done and will have to accept this is the best I'm going to get. I just hope DLM relents a little as I don't need interleaving on the upstream and I could probably do fine with INP 3 on the downstream (returning me some sync speed again). However the DrayTek historically has kept fastpath and somehow ignored the errors I've had or am still getting, so it might also be wise to go back to that router/modem eventually.

Things have definitely improved though, less errors and higher sync rate (well above the estimate). My neighbour also told me his speed increased from 45Mbps to 55Mbps this morning, apparently, perhaps his line has improved due to mine getting changes?

Depending on what FTTPoD turns out to cost next year then I might get it and my problems would be over for sure, but if it turns out to still cost thousands potentially then I won't touch it as I don't own the property I live in. It also depends if AAISP will sell it, as after being with them I don't think I'd touch another ISP again unless something radically went downhill.

I'll compare ronski's and skyeci's connection when I'm home a little later today, I'm curious to see.

[WWWombat]

While I'm still curious to understand why using a filter might actually make matters worse,

In the end, a filter is an electronic circuit, that attempts to tune a bigger electronic circuit (ie the copper wire, with its inherent resistance, capacitance and inductance, plus a master socket with resistor and capacitor) into behaving a certain way with RF signals.

If there is something wrong with one of the components in the filter, or in the wire, or in the master socket, then that tuning might result in strange effects.

Filters themselves come with all sorts of components...
https://www.adslnation.com/support/filters.php

[Ixel]

In the end, a filter is an electronic circuit, that attempts to tune a bigger electronic circuit (ie the copper wire, with its inherent resistance, capacitance and inductance, plus a master socket with resistor and capacitor) into behaving a certain way with RF signals.

If there is something wrong with one of the components in the filter, or in the wire, or in the master socket, then that tuning might result in strange effects.

Filters themselves come with all sorts of components...
https://www.adslnation.com/support/filters.php

True. Well I'm going to keep it unfiltered as it seems to work better that way .

DLM has relaxed the error correction just a few minutes ago thankfully, maybe a few more days and downstream might see fastpath again.

Upstream changed from INP 4 delay 8ms to fastpath.

Downstream changed from INP 4 delay 8ms to INP 3 delay 8ms.

AAISP are going to follow up next week, or I will, whoever's first. I'm hoping by midday Monday I can say to them that fastpath is back and the excessive errors I was having are now gone.

I've left them an excellent review for their efforts and service ( https://www.ispreview.co.uk/review/reviews/6797.html ). The opposite for Zen too.

[Ixel]

To provide an update, DLM hasn't completely removed interleaving yet. I'm hoping it will in a few days. I'm well within the green threshold for ES+SES and re-syncs, I've not re-synced at all since the last DLM intervention, ES is 9 on the downstream for the last few days and 1 on the upstream, SES is 0 for both. Average downstream FEC errors per hour is under 10000 (less than 166 per minute) at the moment.

https://pastebin.com/raw/YCUVkcsV for some more recent stats from my DrayTek Vigor 2860Vac.

If nothing happens in a few more days I might nudge the SNRM target offset up a little and wait a few more days.

EDIT: Here's some more information about the connection.

https://pastebin.com/raw/5xethk9f

SNRM delta 9 means +0.9 dB on top of the current 6 dB target SNRM, so 6.9 dB is the actual SNRM target right now. Sadly the router rounds the SNRM down so 6.9 will show as 6 dB on the statistics still. Also oddly the INP shown as half the true value, I don't know why. For example it says 15 symbols (1.5), but it should be 30 symbols (3.0).

[skyeci]

I waited 5 weeks. No lifting of interleaving and delay despite being green and No es. The only way to shift it was a temporary manual cap on the ds. After 8 days it returned the line to fast path.

[Ixel]

I waited 5 weeks. No lifting of interleaving and delay despite being green and No es. The only way to shift it was a temporary manual cap on the ds. After 8 days it returned the line to fast path.

Ouch, I see, I wonder why. I guess I might have to do the same then. I'll try nudging up the SNRM target offset if nothing happens in the next two days or so, otherwise I'll temporarily switch to the Zyxel and apply banding to the downstream.

[skyeci]

I was 70/20 pre int and delay. Then 66/20 with int and delay. I capped it to 54/20. Then rebooted after return to fastpath and back to 70/20...been fine since

[Ixel]

I've bumped my SNRM target offset up to +3.0 dB (which makes it 9.0 dB) now based on your experience with DLM sticking until manual banding was applied. I'm hoping this will work the same in helping DLM restore fastpath sooner rather than later or never. I'll post another update when I have something. Thanks .

AAISP also noticed the nice review I left them hehe , thanking me for it.

The only anomaly remaining is the slightly higher than expected ping, which hopefully once fastpath is back I can see whether it was just interleaving causing a weird anomaly or indeed some kind of odd routing taking place (which I think it is). My ping last I checked was 24ms, but I normally and used to have 8ms on fastpath but when I had fastpath sometimes I connected with a 16ms ping via TTB. Right now I only have 8ms delay on the downstream and fastpath on the upstream so really it should only be 16ms or so and not 24ms.

[Ixel]

Still no movement from DLM yet so I've bumped SNRM delta up to the maximum possible value of 50 (+5.0 dB), making the SNRM target now 11.0 dB. I'll leave it for a few more days and if there's no movement still then I'll switch to the Zyxel and temporarily apply a banded sync rate. I'm currently at 57.5 megabits so might try setting 40-45 megabits if I have to do that.

EDIT: DLM has just restored fastpath, I guess it just needed time. Looks like about two days for the first improvement and I think a further six days for the final improvement. Errors appear to be virtually non-existent on the DrayTek currently. I'll post an update in a few days (probably a final update) and may briefly try the Zyxel again later on, if it produces the problem again I'll switch back to the DrayTek fast. For now I'll let things settle.

[burakkucat]

Thank you for the update.

For now I'll let things settle.

That is a sensible choice of action.

[Ixel]

Posting an update sooner than I expected mainly as my ping anomaly is gone now too (was 16ms on fastpath, basically 8ms higher than it should be), after switching to the 'new TalkTalk network' (https://aastatus.net/2454).

My DrayTek stats so far (just over 3 hours of uptime again as I had to do some changes here to switch over to the new TalkTalk network as a trial/beta tester). Yesterday however I can say was clean too with a low amount of errors . I'm confident the problem is resolved, even if not going via a filter was the final solution to eliminating whatever's causing the previous amount of continuous trickling and excessive errors. I'm connected directly into the test socket with a shielded RJ11 to BT LJU cable.

DrayTek stats are here: https://pastebin.com/raw/FwamDa3m

I've changed the SNRM target to 9 dB today and will lower it again soon to the default 6 dB which I imagine should easily give me the full 80 megabits downstream with a bit spare. Given my line I think is around 400-450m I'm definitely pleased with the speeds I'm able to get on the new line compared to the old line, credit to the engineer who spent a while finding me the best possible pair at each section along the route the line takes.

I had some issues initially switching over to the 'new TalkTalk network' but now that I'm connected I'm getting a nice low ping of 7-8ms (or just under 5ms according to the CQM graph) which is wonderful! AAISP are currently looking into a minor issue I'm having with the line rate and MTU or such not being  passed on to them since switching to the new TalkTalk network. I had to enable baby jumbo frames in order to be able to connect correctly in the end even though that still took a while to PPP connect for some reason. So, while I'd like to a speed test at my new sync rate I can't yet as it's still seeing my old sync rate for now haha.

Next week I will briefly try the Zyxel just to see if the statistics are also clean like they are on the DrayTek now. Fingers crossed. I'm confident the problem is resolved. I still find it disappointing that Zen didn't even send out one SFI engineer but on the other hand for a long time I've wanted to go to AAISP and this I guess was the motivation I needed . Expect a final update next week (and perhaps some stats on MDWS).

EDIT 11/11/2017 09:05: Pings are super nice on the new TalkTalk network! I've never seen a ping this low, just under 6ms to YouTube!

https://i.imgur.com/1HphQOt.png is a ping graph for the last 3 hours at time of this edit.