Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: TomPoolHD on May 31, 2017, 09:27:12 PM
-
Today I had VDSL installed, and the speeds seem to be somewhat interesting.
The line is rather long and I didn't expect huge speeds but at 2km from the cabinet I think a 3000kbps sync is a little lower than expected. Im connected to Malton exchange on cabinet 9.
I just wondered if anyone can deduce any information from my line stats and mydslwebstats data that I have started to upload.
mydslwebstats username: TomPoolHD
Line stats: http://imgur.com/7plrT2U
Any help is greatly appreciated!
Thanks Tom
-
Hello Tom. Welcome to the Kitz forum. :)
Having taken a quick look at the information your have provided, along with viewing MDWS, it does seem as if you have a circuit that is at the "far limit" for a G.993.2 (VDSL2) based Internet service. I think we need to let the circuit "do its own thing" and then review the situation after 24 hours have elapsed.
Being a new provision, the circuit is running on fast-path with a "wide open" profile. I suspect that once the first 24 hours have elapsed the DLM will then attempt to optimise the circuit's performance.
I may be wrong but I thought that Ofcom had issued a diktat that all ISPs/CPs must provide a personalised estimate as to the performance one could expect when signing up for their service. So if I'm not imagining it what estimate did your ISP/CP provide, please?
-
Hi, I am 1.9km from my eci cabinet and I get 16 down and 0.5 up. I have to limit it to 10 down or I get horrendous amounts of interleaving applied.
-
Hi Tom, is that a Zyxel modem?
-
Hi Tom, is that a Zyxel modem?
It's a Billion 8900AX 2400.
I may be wrong but I thought that Ofcom had issued a diktat that all ISPs/CPs must provide a personalised estimate as to the performance one could expect when signing up for their service. So if I'm not imagining it what estimate did your ISP/CP provide, please?
Great to be here, thanks.
I think the clean estimate was 4.7 Mbps downstream, impacted 2Mbps. AAISP have the range of 2-10.7 as they Quote from the bottom of impacted to the top of clean estimate.
-
I think the clean estimate was 4.7 Mbps downstream, impacted 2Mbps. AAISP have the range of 2-10.7 as they Quote from the bottom of impacted to the top of clean estimate.
Thank you.
Ah, yes, I had read that A&A tend to quote a rather optimistic wide range. My feeling -- with the sparse amount of data that is currently available to us -- is that around 3 Mbps DS may be the upper limit for your circuit.
-
Blimey 2km to the cab. I didn't think it was possible, would you not be better off with ADSL2+ Tom?
-
Blimey 2km to the cab. I didn't think it was possible, would you not be better off with ADSL2+ Tom?
ADSL was giving a speed of around 5Mbps so yep at the moment it looks that way.
On the plus side an engineer arrived this morning and has found a battery fault, and something to do with a bad earth. I'm not entirely sure but he is checking everything so fingers crossed we could see some more speed!
-
I am km from the cabinet and get 15/1 with latency about 20. The happy days of G.inp gave me 18/1 and 15.
-
On the plus side an engineer arrived this morning and has found a battery fault, and something to do with a bad earth.
It will either be a "battery contact fault" or an "earth contact fault". I'd be surprised if both types of fault were found . . . but then I'm not the Openreach technician tasked with the fault. :) (And that explains the cessation of uploads to MDWS at 0839 hours this morning.)
I will be very interested to see the resultant Hlog and QLN plots once the work is complete -- I hope to see an improvement.
-
It will either be a "battery contact fault" or an "earth contact fault". I'd be surprised if both types of fault were found . . . but then I'm not the Openreach technician tasked with the fault. :) (And that explains the cessation of uploads to MDWS at 0839 hours this morning.)
I will be very interested to see the resultant Hlog and QLN plots once the work is complete -- I hope to see an improvement.
I'm going to setup the computer again to record the results. Sadly no gain in speed from the fault being fixed but hopefully errors reduced or some effect on the quality of the broadband :)
-
Uploading to MDWS is, once again, in progress.
I was hoping to see an improvement in both the Hlog and QLN plots . . .
The latter still looks like a fine-tooth flea-comb. :-X
-
Uploading to MDWS is, once again, in progress.
I was hoping to see an improvement in both the Hlog and QLN plots . . .
The latter still looks like a fine-tooth flea-comb. :-X
I thought we had cracked it with the battery fault, seems not :(
The SFI engineer said his final tests said the line was perfect. I'm not sure what to do now...
AAISP have said they will continue to chase it up, hopefully they can find something else that might be causing the problem.
In regards to the upstream speed is that in any way related with the downstream speed? Like a correlation, as I can see another user on mydslwebstats is also at the end of a long line recieving around 10Mbps down and 1Mbps up. Im not great with the technical side of broadband but I think it's best to analyse as much as possible to see if there is an underlying problem and comparison with another long line may help.
Thanks Tom
-
In regards to the upstream speed is that in any way related with the downstream speed? Like a correlation, as I can see another user on mydslwebstats is also at the end of a long line recieving around 10Mbps down and 1Mbps up. Im not great with the technical side of broadband but I think it's best to analyse as much as possible to see if there is an underlying problem and comparison with another long line may help.
The DS and US synchronisation and throughput speeds are related to the loop-loss (the attenuation) of the circuit . . . Strictly, it is an inverse relationship.
We need to watch and wait, as the circuit has not yet had a full 24 hours of operation.
2.2 User Network Interface - General
2.2.1 Dynamic Line Management
Dynamic Line Management (DLM) is employed in GEA-FTTC. DLM constantly
manages lines to maintain a target link quality (speed and stability). It does this for as
long as the product exists.
At provision, the line is put on “wide open” VDSL2 line profiles allowing the
upstream and downstream line speeds to run at the upper limit of the product option
selected.
On the first day of operation, DLM will intervene if severe instability is detected.
Otherwise, DLM will wait until the day after provision before deciding if it must
intervene, provided that the line has been trained up for at least 15 minutes during the
preceding day.
If DLM intervenes it will set a profile with a maximum rate and a minimum rate,
where the minimum rate is set at approximately half of the maximum rate. The
purpose of the minimum rate is to ensure that the line does not train at a rate which is
significantly below the level the line should be able to achieve. If this happened, then
the line is likely to remain at a very low rate until a re-train is forced by the user by
powering off the modem.
Note : It is the DLM system that sets the line profile, and this should not be interfered
with by CPs/users setting rates, SNR margins etc. at the modem.
Note : The upstream throughput is also constrained on the DSLAM to the upstream
rate requested in the order, i.e. 2 Mbit/s, 10 Mbit/s or 20 Mbit/s, so even if the VDSL2
upstream line speed is higher, the upstream throughput is constrained to the level
ordered for the product.
SIN 498 v7.3 (http://www.btplc.com/sinet/SINs/pdf/498v7p3.pdf)
-
The DS and US synchronisation and throughput speeds are related to the loop-loss (the attenuation) of the circuit . . . Strictly, it is an inverse relationship.
We need to watch and wait, as the circuit has not yet had a full 24 hours of operation.
SIN 498 v7.3 (http://www.btplc.com/sinet/SINs/pdf/498v7p3.pdf)
Ah ok thanks for that!
The engineer also mentioned he had preformed a DLM reset. Am I right in thinking G.INP could be placed on the line? That could bring some more speed :)
-
The engineer also mentioned he had preformed a DLM reset.
He was, clearly, one of Black Sheep's flock. The DLM reset (the "circuit recalc") has set everything back as if it is a newly provisioned circuit. So the 24 hour period will be from the time of that reset.
Am I right in thinking G.INP could be placed on the line?
G.Inp (more correctly G.998.4) is one setting in the DLM's repertoire which can be applied to the circuit if the DLM decides to intervene. It's best not to try and second guess what might happen . . . we should know by this time tomorrow. ;)
-
He was, clearly, one of Black Sheep's flock. The DLM reset (the "circuit recalc") has set everything back as if it is a newly provisioned circuit. So the 24 hour period will be from the time of that reset.
G.Inp (more correctly G.998.4) is one setting in the DLM's repertoire which can be applied to the circuit if the DLM decides to intervene. It's best not to try and second guess what might happen . . . we should know by this time tomorrow. ;)
Right il leave well alone!
Looks like I have another engineer coming on Saturday, not entirely sure what he will be able to do in comparison with today's engineer?
I will wait with bated breath...
-
Quick update, the engineer on Friday left this note that I don't fully understand:
I cannot complete this task because I do not have the skills required to complete the task and could not obtain assistance on the day. I am passing to an engineer with underground skills because the fault has been proven underground. The line has been proven good to the PCP, OK at PCP D159. Battery Earth and HR to DP230 pr3. Spare pairs 4 dis at 17m and 8 dis at 300m from D. Battery contact was detected towards the end customer. OK at PCP D159. Battery Earth and HR to DP230 pr3. Spare pairs 4 dis at 17m and 8 dis at 300m from DP"
And today 2 jointing engineers spent all morning trying to find the fault and this is the note that has come through tonight after they left:
BT Fault Notification Only - Further work needed - Requires duct or maintenance dig
Right When Tested; End User Equipment;All BT tests completed ok, diagnostics show no fault condition
-
It's pretty much as it says, Tom ....................... there are no good spare 'pairs' between the Cabinet (PCP) and the DP (Telegraph Pole, or Underground joint ..... dependant on location).
One 'pair' is required to deliver telephony/broadband services to each customer.
As such, the job has gone to the underground engineers to deal with the fault, and they have deemed it necessary to have a section of footpath, grass verge, etc etc ..... dug up by our contractors. The chances are there will be a wet joint where this dig is to take place ??.
-
It's pretty much as it says, Tom ....................... there are no good spare 'pairs' between the Cabinet (PCP) and the DP (Telegraph Pole, or Underground joint ..... dependant on location).
One 'pair' is required to deliver telephony/broadband services to each customer.
As such, the job has gone to the underground engineers to deal with the fault, and they have deemed it necessary to have a section of footpath, grass verge, etc etc ..... dug up by our contractors. The chances are there will be a wet joint where this dig is to take place ??.
Thanks for explaining Black Sheep.
Hopefully sorting this wire out will help with the broadband speed :)
-
No probs, mate. :)
-
Although the Hlog plot for Tom's circuit shows the expected rapid decline in attenuation versus sub-carrier for the distance involved, it does not show evidence of any obvious defect(s) in the metallic pathway.
The QLN plot, however, remains looking like a fine-toothed flea-comb and I suspect that the AC balance is poor.
Finally the SNRM plot (with added retrain indicators), attached, shows that all is not well. The one plus point we can see from that plot is that the ISP/CP is A&A. I don't think they will allow the metallic pathway to be left in a defective state for too long . . . ;)
-
Just had another update, the A55 was submitted yesterday and will take 5 days to process.
Just a matter of time now to see what OR can find underground, hopefully it will result in the cable being replaced :fingers:
-
That is good to know. Thank you for the progress report. :)
Just a quick comment, Tom. You will find that there is a "Reply" button to the bottom right of the frame. Quite often newer members will see the "Quote" button above the post and then use that to reply . . . which results in needless duplication. Hence the reason for my edit of your last post.
-
OR turned up this morning, they proceeded to repair the joint. Apparently it was full of water but they have remade it and apparently all is well.
The router stats have not changed drastically, the wide range of figures relating to attenuation visible on mydslwebstats is the different routers reporting the figure in their own way, the HG612 settled on 39.5dB after the work had been done, from an original figure of 43dB with a sync around 2600kbps exactly the same as before the fault was rectified.
The router connected now is the Billion 8900ax, it seems to have not reported a change in attenuation and is still at 40.1dB with a sync speed of 3621kbps, also the same as before...
The QLN plot has not changed looking at previous screenshots, so could there be still an underlying problem?
mydslwebstats: TomPoolHD
Thanks Tom.
EDIT: I have just seen the SNR has been bumped up and also the interleave depth has changed to 71... Maybe a DLM reset will help show the line in a raw form after the fault has been fixed, highlighting any obvious gains.
-
Currently there is not a great amount of detail available to view via MDWS.
What is apparent is that the circuit is now operating in interleaved mode -- so I presume a "circuit recalc" was not performed after the joint had been re-made.
The Hlog plot shows no obvious change as the overall loop-loss remains as before. The spikes in the QLN plot do not appear to be quite so large but it still maintains its "fine-tooth flea-comb" appearance.
No doubt A&A will also continue to monitor the circuit.
-
Persistence seems to be getting me somewhere. Today we had 3 BT OR engineers attend and completely replace our overhead section of our line, they even found a section that had been hit by lightning that had not been spotted by the numerous engineers that have visited before.
The attainable speed seems to have risen to around 6Mbps but the HG612 will not sync any higher than the current 2199kbps, could anyone help me out and explain what's going on?
-
Was a DLM reset performed (a "circuit recalc") once all the work on the infrastructure was completed? If not, it could be that the DLM process is "holding back" the circuit.
-
Ok it looks like that has now happened, looks a lot better than before!
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Last initialization procedure status: 0
Max: Upstream rate = 1285 Kbps, Downstream rate = 5880 Kbps
Bearer: 0, Upstream rate = 1285 Kbps, Downstream rate = 6009 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 6.1 6.7
Attn(dB): 36.5 0.0
Pwr(dBm): 6.0 10.5
VDSL2 framing
Bearer 0
MSGc: 58 26
B: 174 31
M: 1 1
T: 25 59
R: 14 0
S: 0.9268 0.7805
L: 1640 328
D: 1 1
I: 190 32
N: 190 32
Counters
Bearer 0
OHF: 347616 351212
OHFErr: 14 10
RS: 17376544 3540787
RSCorr: 34 0
RSUnCorr: 29 0
Bearer 0
HEC: 24 0
OCD: 8 0
LCD: 8 0
Total Cells: 46459029 0
Data Cells: 3767974 0
Drop Cells: 0
Bit Errors: 0 0
ES: 36 24
SES: 23 0
UAS: 5941 5918
AS: 4044
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 11.63 11.55
OR: 44.02 22.15
AgR: 6052.98 1306.89
Bitswap: 1542/1542 0/0
Total time = 4 hours 9 min 30 sec
FEC: 40 0
CRC: 1093 10
ES: 36 24
SES: 23 0
UAS: 5941 5918
LOS: 1 0
LOF: 22 0
LOM: 10 0
Latest 15 minutes time = 9 min 30 sec
FEC: 9 0
CRC: 2 6
ES: 2 6
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 6 0
CRC: 6 1
ES: 4 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 4 hours 9 min 30 sec
FEC: 40 0
CRC: 1093 10
ES: 36 24
SES: 23 0
UAS: 5941 5918
LOS: 1 0
LOF: 22 0
LOM: 10 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 hours 7 min 23 sec
FEC: 34 0
CRC: 14 10
ES: 11 11
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
Ok it looks like that has now happened, looks a lot better than before!
I'll go and take a look via MDWS.
Later edit: I'll have to remember to take a look tomorrow as, so far, there have not been sufficient uploads to MDWS.