Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: boxhead on June 01, 2012, 12:01:26 AM
-
I had a FTTC install last week on a brand new master socket.
I am aout 100m from the wiring cabinet and the DSLAM (are they still called that?) is right next to it. The engineer found a fault with the port I was supposed to get - it tested slow at the cab - and arranged for a move. He waited there for 30 minutes and came back. I wandered down to see what was taking so long - that's why I know what happened.
Anyway, given that I am 100m from the cab I figured I should be getting excellent sync speed.
Speedtests indicate about ~50Mbps down and ~12Mbps up, both from BT and speedtest. The estimated speed at provisioning time was 68.1Mbps which is more realistic.
I've tried a number of routers and a direct connection - no difference.
I finally unlocked the modem and can see the following. Not sure where to look, but I'm sure there's still a fault somewhere, or does this look about right?
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 17383 Kbps, Downstream rate = 62092 Kbps
Path: 0, Upstream rate = 17804 Kbps, Downstream rate = 53233 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3959)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 17383 kbps 62092 kbps
Actual Aggregate Tx Power: 6.6 dBm 13.3 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 3.1 19.6 32.1 N/A 9.4 25.6 37.8
Signal Attenuation(dB): 8.1 18.5 31.3 N/A 9.4 25.6 37.8
SNR Margin(dB): 6.0 6.1 6.0 N/A 6.1 6.1 6.2
TX Power(dBm): -5.1 -23.9 6.4 N/A 10.4 7.9 6.9
# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 17350 Kbps, Downstream rate = 62532 Kbps
Path: 0, Upstream rate = 17804 Kbps, Downstream rate = 53233 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.3 6.0
Attn(dB): 0.0 0.0
Pwr(dBm): 13.5 6.6
VDSL2 framing
Path 0
B: 63 237
M: 1 1
T: 64 64
R: 16 16
S: 0.0382 0.4253
L: 16733 4778
D: 843 1
I: 80 127
N: 80 254
Counters
Path 0
OHF: 1931849 523623
OHFErr: 11 88
RS: 370963447 3426904
RSCorr: 68466 13816
RSUnCorr: 1109 0
Path 0
HEC: 366 0
OCD: 0 0
LCD: 0 0
Total Cells: 364324571 0
Data Cells: 2897380 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1 54
SES: 0 3
UAS: 18 18
AS: 3563
Path 0
INP: 3.00 0.00
PER: 1.83 6.80
delay: 8.00 0.00
OR: 104.58 34.09
Bitswap: 1604 1128
-
Hi boxhead & welcome to the Kitz forum.
These are the stats from a 400m connection.
You will see that attenuation levels are only slightly worse than yours, which suggests that your attenuation levels are too high for only 100m line length:-
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 24809 Kbps, Downstream rate = 73424 Kbps
Path: 0, Upstream rate = 10000 Kbps, Downstream rate = 39998 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)
Medley Phase (Final) Band Plan
US: (0,95) (868,1207) (1972,2783)
DS: (32,859) (1216,1963) (2792,3939)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 24809 kbps 73424 kbps
Actual Aggregate Tx Power: 6.9 dBm 13.1 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 3.6 20.9 30.7 N/A 10.8 26.4 39.8
Signal Attenuation(dB): 10.6 20.1 29.7 N/A 10.8 26.4 39.8
SNR Margin(dB): 23.4 22.0 22.2 N/A 15.8 15.9 15.8
TX Power(dBm): -4.4 -26.6 6.6 N/A 9.8 8.2 6.7
Also, your SNRM levels ar around the target level of 6 dB.
This is telling us that currently your connection is performing at around maximum capability. i.e. there is no spare margin to cope with any noise.
Over 100m, I would have expected really high SNRM levels, perhaps in the high 20s if on a capped 40Mb service & higher than 15dB on the 80Mb service.
You mentioned the engineer found a slow port fault.
Did he actually confirm that had been resolved on completion of his work?
Did he also confirm the line length, attenuation, Max rate, SNRM etc. as reported directly via his JDSU or Exfo tester?
I also see that Interleaving, Impulse Noise Protection & delay are switched on, which does suggest noise interference issues.
If you are a Windows user, you could try the HG612 Graphing Scripts, obtainable via this link for us to have a look at:-
http://forum.kitz.co.uk/index.php/topic,10552.0.html
They would give us a graphical view of your current line conditions and/or how it performs over a period of time.
Examples for my "up to" 1000m length connection are attached.
-
Also 31 days of Ongoing stats for my connection are attached, showing the before & after a recent engineer's repair visit.
-
Very quick 'heads up', boxhead. If the engineer found a faulty port, it takes an average of 50-60 mins to have a 'Lift & Shift' implemented.
-
Very quick 'heads up', boxhead. If the engineer found a faulty port, it takes an average of 50-60 mins to have a 'Lift & Shift' implemented.
I was expecting good things, so didn't really probe the engineer about the stats on his tester - doh!
The ISP looked up the install notes and he confirmed the notes said "performed a lift and shift". It's odd that the slow speeds he quoted on the original port are about what I am getting. But no one would say they moved it and really didn't? Would they? Or are they expecting someone to fix the port instead?
Anyway, I'll set up the graphing and see what I get.
Thanks guys. Wish I'd read a bit more about this stuff before the install.
-
Some stats if anyone cares to take a look. I was fillding with cables between 9am-12pm. Other than that, this is what I've got over the past day or so.
The logging is very useful! Oddly, when I recevied my first phonecall on the new line at approx 21:30, it appears the connection dropped?
Also, I did notice some crackling. I did a quiet line test a few times and there's definitely a muffled crackling noise which seems to build up and then fade out. Sadly, the line tests fine.
I'm going to try and use the phone a bit to quantify the line noise and them hopefully get someone out to look at it. I don't use the landline often but having noise on the line isn't acceptable when I do.
-
The logging is very useful! Oddly, when I recevied my first phonecall on the new line at approx 21:30, it appears the connection dropped?
That is indicative of a HR fault on the D-side cable. :(
I'm going to try and use the phone a bit to quantify the line noise and them hopefully get someone out to look at it. I don't use the landline often but having noise on the line isn't acceptable when I do.
Noise on the line ist verboten by the telephony standard of service. :no: Have the (suspected) HR fault fixed -- by reporting the crackling to your telephone service provider (do not make any mention of the broadband service) -- and your broadband sync (& thus throughput) speed should then improve. :)
-
You could try looking at the modem's GUI while making/receiving phone calls.
Especially look at SNR margin (dB).
It should not really change much when using the phone.
If it changes by more than 0.4dB, it would point to a definite problem.
I had that recently & running my connection via a dangly filter was fine. (filtered faceplate removed from the master socket & dangly filter plugged into the test socket).
This proved the issue was a faulty filtered faceplate (SSFP).
When the engineer visited, he firstly replaced the SSFP which sorted out the disconnections when the phone was used issue.
He also carried out some other external work & my connection is now stable again.
Your Hlog graph looks a bit "dodgy" at the top left.
That seems to have affected the bit-loading at the same tones.
Also your QLN doesn't look great, averaging somewhere around -120dB.
Even my long & problematic connection has always shown QLN to be a lot closer to -140dB (i.e. quieter than yours).
Your SNR graph looks quite jagged, indicating noise issues again.
I have attached an example montage from a 400m connection.
The attainable rate is higher & the graphs are smoother.
If you would like to plot your graphs in the same format (mainly for QLN), that will also be a smaller filesize that can be directly attached in this forum let me know.
I could post a replacement GRAPH6.BAT for you.
EDIT:
For only 100m distance from the cabinet, your SNRM levels should be much, much higher than the 6dB or less as shown in your stats/graphs.
For such a short distance, I would have expected an attainable rate of higher than 100Mb (as seen for many other short connections).
-
Your SNR graph looks quite jagged, indicating noise issues again.
For such a short distance, I would have expected an attainable rate of higher than 100Mb (as seen for many other short connections).
Spot on Bald Eagle. After a 3 hour engineer's visit this morning to fix intermittent crackling I could hear during calls, I see expected sync - 100Mbps / 30Mbps.
Now to wait for DLM to do it's thing...??? Because the actual speed is LOWER than before.
See attached.
-
That looks a lot better, all round.
Is that you sat with the engineer in the photo, telling him what to do? :lol:
Did he mention that he would be requesting a DLM reset/recalc following his repair work? He should have done.
-
Is that you sat with the engineer in the photo, telling him what to do?
That's his mate who came to help. I did offer coffee, looked so cosy.
Did he mention that he would be requesting a DLM reset/recalc following his repair work? He should have done.
Given it was booked as a voice fault, doubt it. I'll see what the ISP says when they update the voice fault. Or I'll give them a nudge tomorrow.
It's annoying when you know something's not right, can prove it but no one listens coz "it's in tolerance". Near enough ain't good enough.
-
At least you now have before & after stats/graphs as PROOF ;)
-
A definite result. :thumbs:
We will look forward to a new data set, once the DLM has been forced into submission. :-X
-
@ boxhead,
Any news regarding a DLM reset/recalc yet?
-
I had a change at around 6am today.
DS: 48998 -> 59999 (max. ~102000)
US: 16999 -> 20000 (max. ~31000)
SNRM dropped at the same time. Not sure I like that part, but attainable sill maxed out.
I'll post full stats when it stabilises.
-
20000 & 59999 look like set sync speed caps that may still need overriding manually.
The 20000 is no problem & is the max for your service & as expected.
Assuming DS SNRM still exceeds 6dB by a few dB (I strongly suspect it does) there is still scope for more DS sync speed, but the 59999 does look like an intentional speed cap.
While not ruling it out, we are not aware that DLM for FTTC services gradually increases sync speeds in fixed steps following improvement/repair works.
Rather it usually either "sticks" at some lower level or increases immediately to either the maximum capped level (79999 for your service) or some other intermediate level that doesn't end in 999 or 000.
Was this recent change in response to you contacting your ISP, or has DLM simply decided that's the max speed you can have, no doubt based upon the history of poor speeds/disconnections etc?
-
Assuming DS SNRM still exceeds 6dB by a few dB (I strongly suspect it does)
Yes, SNRM is ok. It dropped from ~18 to ~14 just after 6am yesterday but it's back to ~17 just after 6am today.
Max attainable DS dropped to ~98000 and US down to ~30000.
Capped DS/US speed still at 59999 and 20000 resp.
While not ruling it out, we are not aware that DLM for FTTC services gradually increases sync speeds in fixed steps following improvement/repair works.
Things seem to happen between 6-7am. Today, interleaving fell from >1200 to OFF. Ping times are now 9-10ms to bbc.co.uk, down from >20ms.
While not ruling it out, we are not aware that DLM for FTTC services gradually increases sync speeds in fixed steps following improvement/repair works.
After reading a few posts, I have resigned myself to the fact that we just let DLM do it's job. So far, it seems to work.
I'm hoping I'll check that stats in a couple of days and that (DLM enforced) speed cap will increase, hopefully, once more to 8000 once the error rates are proven to be stable. Definitely NOT going to power cycle/reboot the modem.
I think DLM just tinkers with settings (interleaving, power levels?, etc) every 24 hours until it's happy it has achieved the maximum stable/error free rate.
Was this recent change in response to you contacting your ISP...
No, ISP says they cannot do anything to reset DLM.
Lets see in a couple of days... I think the message is be patient.... DAMN, it's really testing mine! :'(
-
No, ISP says they cannot do anything to reset DLM.
That's not strictly true.
It is true that they can't physically reset it. They have to contact BT to get it reset.
This used to definitely require an engineer to be on site to liaise with BT's Fibre Centre (can't recall its proper name) & to check the outcome of the reset.
This procedure seems to have become slightly more relaxed now.
The latest visiting engineer left my home telling me the reset should happen in the next few hours.
As it happens, the reset actually happened while he was on the phone explaining it to me.
I hope, for your sanity, that DLM does indeed eventually sort things out, letting you have what your connection now appears to be capable of.
If not, maybe a DLM reset request will require escalation to someone who knows the score at your ISP.
Who is this unenlightened ISP by the way?
-
Latest update...
I hope, for your sanity, that DLM does indeed eventually sort things out
Indeed, DLM has again made a house call this morning and DS now 73999. Maybe tomorrow it will be all but done and dusted.
Looks like DLM does make incremental changes based on 24 hour assessments.
-
Indeed, DLM has again made a house call this morning and DS now 73999. Maybe tomorrow it will be all but done and dusted.
Looks like DLM does make incremental changes based on 24 hour assessments.
That's great news & also very interesting feedback regarding apparent incremental increases.
-
For reference, here's the last 7 days stats. I'm hopeful that there will be another correction tomorrow morning which will see the DS get to 80000 (or 79999) and the SNRM step back up again.
It's pretty obvious the engineer fixed the underground joint issues (in the pit at the base of the pole, which is outside my house) and, I think, put me on another pair at 8:30-11:30 on 8th June. He did also suggest that the connections in that pit "aren't ideal" and corrected "a few things" - all outside. I guess he needed to fix the shoddy work of the subcontractor who did the brand new line installation (previously Virgin line) into my comms cupboard. ???
I'll post a final (?) graph perhaps this weekend.
-
In graphpd.BAT you could replace the relevant parts of the attainable rate function with this:-
echo set yrange [0:130000] >> attainable_rate.gnp
echo set ytics axis 5000 nomirror >> attainable_rate.gnp
echo set grid xtics back >> attainable_rate.gnp
echo set grid ytics back >> attainable_rate.gnp
echo set key at "%DTBEGIN%",129000 left noautotitle box 3 >> attainable_rate.gnp
echo plot 'GDATA$$' using 1:9 title ' DS' linecolor 9 w lines >> attainable_rate.gnp
echo unset grid >> attainable_rate.gnp
echo set key at "%DTBEGIN%",124000 left noautotitle box 3 >> attainable_rate.gnp
echo plot 'GDATA$$' using 1:10 title ' US' linecolor 7 w lines >> attainable_rate.gnp
echo unset multiplot >> attainable_rate.gnp
goto :eof
It will extend the y axis to 130Mb & move the key up accordingly to accommodate your new found max rates ;)