Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: NewtronStar on June 20, 2013, 11:29:12 PM
-
Hi does anyone know how long it takes the BT DLM on FTTC to adjust (increase) the line rate if it saw noise on the line is it 4 days or 2 weeks ?
as I seem to be stuck at 26093 line rate for 3 days did try a HG612 reboot but still the same
as seen below.
-
As you have a very high DS Interleaving depth of 1671 & SNRM just below the target 6dB, along with a 'noisy' looking SNR graph (D2 band), it looks like you might be stuck at around current speeds until/if line conditions improve.
Have you been recording ongoing stats in order to see when things actually changed?
Like many other users, have your estimated speeds been reduced recently?
-
dont reboot when waiting for DLM to change to a higher profile. I have occasionally read people saying they done this but I wouldnt do it. Well i did do it when swapping modems, but I wouldnt do it I mean if eg, to try and speed up DLM, I think it will only slowdown DLM.
DLM seems to recover from interleaving anythign from a few days up to a few weeks. As long as the FEC count is low enough.
It seems to take much longer to increase banding tho. My line is still banded and it hasnt dropped or had crc error bursts for a long time now. I think i have been banded for 2 months or more now.
-
Gentlefolk,
Our experiences suggest that those lines that have had a fixed cap applied usually on 15, 20, 25, 30 or 35 Mbps are permanently fixed until a BT Openreach engineer has visited with his test instrument and then (s)he remembers to "reset the DLM".
Why some lines are capped at those values and some not still remains a mystery - at least to me.
Kind regards,
Walter
-
Have you been recording ongoing stats in order to see when things actually changed?
Like many other users, have your estimated speeds been reduced recently?
unfortunatlely not BE1 :-[ as the line has been steady for over 1 year. my last logging finished in march due to re-installing the PC OS, still have backups of Current stats here is one from 13/3/2013, it happened last weekend and all i did was to turn off the homehub3 overnight which i normally don't do.
the estimated speeds are 31.5 Mbps & did a reboot on modem and lost another 1meg in the line rate i'll do as Chrysalis suggested and leave it alone now.
-
It's a little hard to compare due to the different formats, but apart from Interleaving depth increasing from 467 in JANUARY to 1671 yesterday, nothing else seems to have changed much.
If you don't have the current version of the program installed & don't wish to install it (WHY NOT? ;D ;D), feel free to zip & post both Plink logs here & I'll graph them for you for comparison purposes.
-
feel free to zip & post both Plink logs here & I'll graph them for you for comparison purposes.
thats very kind of you. the original version of HG612 Win Graphs 3.10 Zip file was corrupted due to a Data recovery software I used in March as the orginal Backup of PC got trashed but only lost 2% external backup is the way to go and forget internal backup partitions ;)
-
Hi does anyone know how long it takes the BT DLM on FTTC to adjust (increase) the line rate if it saw noise on the line is it 4 days or 2 weeks ?
as I seem to be stuck at 26093 line rate for 3 days did try a HG612 reboot but still the same
as seen below.
If you want my experience, see here http://forum.kitz.co.uk/index.php/topic,12593.0.html (http://forum.kitz.co.uk/index.php/topic,12593.0.html)
This assumes that the noise resulted in multiple resyncs within a short time-frame of < 24 hrs. This seems likely, as if it only induced increased error rates, then recovery may be much less than that.
This thread http://forum.kitz.co.uk/index.php/topic,12535.0.html (http://forum.kitz.co.uk/index.php/topic,12535.0.html) discusses this further.
-
Why some lines are capped at those values and some not still remains a mystery - at least to me.
Walter, you may need to refresh your memory here http://forum.kitz.co.uk/index.php/topic,12535.0.html (http://forum.kitz.co.uk/index.php/topic,12535.0.html) :)
-
thats very kind of you. the original version of HG612 Win Graphs 3.10 Zip file was corrupted due to a Data recovery software I used in March as the orginal Backup of PC got trashed but only lost 2% external backup is the way to go and forget internal backup partitions ;)
I actually found one of your Plink log files from 30/06/2012 for comparison against yesterday's graphs & those from January.
Not a lot had changed between June 2012 & January 2013, but we can see fewer tones being used yesterday.
In January, your connection had remained in sync for over 93 days, so DLM must have been quite happy with it.
By yesterday, Interleaving depth had increased dramatically to a fairly high level & I can see a slight worsening of QLN levels.
QLN & Hlog levels will vary slightly depending on conditions at the time of resync & that data remains until the next resync.
SNR & SNRM levels constantly vary between resyncs due to ambient noise, usually more noise being detected in the evenings.
Do you have any ongoing data at all to have a look at for a picture of error counts etc?
I don't have any ongoing graphs or raw data for your connection.
-
& here's yesterday's montage.
-
I have this from July 2012 but as you know I don't keep the PC on 24/7 and I am not sure if it would help you understand whats going here.
and I now regret not having HG612 stats runing every day TBH I never thought this would happen to me.
here are two ongoing stats 1st one july 2012 and 2nd this week of 2013
-
By yesterday, Interleaving depth had increased dramatically to a fairly high level & I can see a slight worsening of QLN levels.
Yes BE i can now see this to when comparing my old & new stats interleaving depth has gone from 450 to 1600 could you tell me how or what could have caused this but I guess its noise on my line.
"Interleaving involves the use of powerful error-correction algorithms to improve broadband speed and stability on long or noisy phone lines. We use it as a matter of course on our broadband lines including BT Infinity lines where the connection between the street cabinet and your home is over copper cable.
-
Yes BE i can now see this to when comparing my old & new stats interleaving depth has gone from 450 to 1600 could you tell me how or what could have caused this but I guess its noise on my line.
It could be increased errors due to noise or it could be a physical fault (possibly intermittent) that started to cause frequent resyncs or many manually forced resyncs or simply increased crosstalk (although at a quick glance, crosstalk doesn't seem to be a major issue).
Was the resync at around 17:30 21st June initiated by DLM or a manually forced resync?
The script version that you have been using takes some of its data from the modem's GUI.
We now know that FEC & CRC errors are reported incorrectly in the modem's GUI so we should ignore those graphs & look at the RSCorr graph for FEC errors & the OHFErr graph for CRC errors.
Also, the script version was written on the assumption that logging would continue 24/7.
As cumulative values are used, with a calculation carried out to compare the just harvested data with the previous row of data in the log file, large spikes can be seen in the graphs each time logging recommences following a period where logging had been switched off or the PC switched off.
If you wished to post zipped copies of your modem_stats.log, I could edit them to make the resulting graphs plot more 'sensible/realistic' data.
The initial release of the program version (HG612 Modem Stats 1.0) addresses a few of those issues & the soon to be released update addresses even more of them & it will also provide extra data such as bitswapping & fully automated scheduled harvesting & optional graphing of snapshot data & ongoing data.
The new version avoids the 'spikes' when logging recommences & automatically generates snapshot data (optionally graphing it) along with appending a RESYNC.LOG whenever a resync is detected etc. etc.
e.g:-
05/05/2013 01:12 - RESYNC detected (DS 24289 Kbps, US 4943 Kbps) since the previous ongoing data harvest (DS 24588 Kbps, US 4912 Kbps)
05/05/2013 04:18 - RESYNC detected (DS 19763 Kbps, US 4962 Kbps) since the previous ongoing data harvest (DS 24289 Kbps, US 4943 Kbps)
05/05/2013 08:06 - RESYNC detected (DS 24293 Kbps, US 4965 Kbps) since the previous ongoing data harvest (DS 19763 Kbps, US 4962 Kbps)
-
It could be increased errors due to noise or it could be a physical fault (possibly intermittent) that started to cause frequent resyncs or many manually forced resyncs or simply increased crosstalk (although at a quick glance, crosstalk doesn't seem to be a major issue).
Was the resync at around 17:30 21st June initiated by DLM or a manually forced resync
That was me rebooting the HG612 from it's GUI to force a resync, but no joy as line rate has gone down to 25581 so I have lost 3-4 Mbps in download performance, it does not sound much but can already see the impact when downloading large files.
Now last week someone did say to me we need to get new phones (dect) as it kept cutting off I thought it maybe the batterys and did a quiet line test and it was very quiet, does it have to be a corded phone to do these tests or will dect phone work as thats what I used.
-
. . . did a quiet line test and it was very quiet, does it have to be a corded phone to do these tests or will dect phone work as thats what I used.
When performing a QLT, it is always advisable to use a classic, wired phone (plugged directly into the 'test socket' of the NTE5/A) as the use of a cordless phone could result in a false positive.
In this case you have observed a 'good silence', so I don't think the test needs to be repeated with a wired phone. :)
-
In this case you have observed a 'good silence', so I don't think the test needs to be repeated with a wired phone. :)
thankyou very much BC :) I really should buy one of them incase of powercuts and on that note
when our electric went off in March for 32 hours (SnowStorm) and when it did come back on the HG612 had it's highest sync ever line rate of 32Mbps and attainable rate of 35600, very strange unless the FTTC Cab also had a power outage and did a line reset for all customers. ;)
-
If you want my experience, see here http://forum.kitz.co.uk/index.php/topic,12593.0.html (http://forum.kitz.co.uk/index.php/topic,12593.0.html)
This assumes that the noise resulted in multiple resyncs within a short time-frame of < 24 hrs. This seems likely, as if it only induced increased error rates, then recovery may be much less than that.
Cheers I was looking into your thread a few days ago, I just don't know my DLM has been very kind to me over the year and could do three reboots of the HG612 in 12 hours just for testing purposes and I got away with it , but as this is my first time the DLM has been not so kind to me and Modem has been in sync for 2-3 months (no manual reboots) by me until this last week when I notice this cap ! it looks like my hands are tied at the moment by the DLM or a fault and I don't look forward to try and explain to BT I lost 4Mbps in a week as I don't think it would warrant an investication :-\
-
Well its looking good and two weeks to the day since the slow speed arrived the DLM has increased my path downstream rate and interleaving has gone down. :)
Still waiting for the IP profile to change to 28Mbps !
-
With a sync speed of 28556 Kbps, your IP Profile should be around 27.64 Mbps (96.79% of sync speed.
If it is still lower than that, a ROUTER (not modem) disconnect/reconnect should update it accordingly.
Retrain Reason was 2, which indicates an 'on the fly' DLM initiated resycnc.
These are often too quick to be noticed by the IP Profile updating system & need user intervention to initiate a new PPP session via the ROUTER.
-
With a sync speed of 28556 Kbps, your IP Profile should be around 27.64 Mbps (96.79% of sync speed.
If it is still lower than that, a ROUTER (not modem) disconnect/reconnect should update it accordingly.
Retrain Reason was 2, which indicates an 'on the fly' DLM initiated resycnc.
These are often too quick to be noticed by the IP Profile updating system & need user intervention to initiate a new PPP session via the ROUTER.
Yeap your spot on with the IP profile BE1 ;) So all in all it looks like it takes the DLM two weeks to increase the IP profile when it's dectected noise on the line, as this is my first and hopefully last encounter with the DLM :-\ i'll know what to look out for and the HG612 WinGraphs will be on permanently but not the PC sorry :D
and Cheers for all the help :)
-
Gentlefolk,
Our experiences suggest that those lines that have had a fixed cap applied usually on 15, 20, 25, 30 or 35 Mbps are permanently fixed until a BT Openreach engineer has visited with his test instrument and then (s)he remembers to "reset the DLM".
Why some lines are capped at those values and some not still remains a mystery - at least to me.
Kind regards,
Walter
hi there
my line (40/10) seems to be "capped" down at 35000 since a few weeks, however i had a few ping changes and upload speed too.....current stats:
Max: Upstream rate = 10993 Kbps, Downstream rate = 46708 Kbps
Path: 0, Upstream rate = 9995 Kbps, Downstream rate = 35000 Kbps
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 0.1 7.4 10.4 N/A 4.4 10.2 18.3
Signal Attenuation(dB): 0.1 7.4 10.4 N/A 4.4 10.2 18.3
SNR Margin(dB): 6.5 6.9 6.2 N/A 8.6 8.6 8.2
TX Power(dBm): -11.3 -128.0 -8.4 N/A 9.8 7.4 0.6
worth to wait some more weeks rather than calling Sky and asking for a profile reset? this past friday ping went down to an awesome 5-6ms from 13ms which i had previously, so DLM is doing "something" but i wouldn't like if they might mess up the ping....
thanks
Gab
-
Hi gab81 & welcome to the Kitz forum.
Do you have any snapshot/ongoing graphs (recent and from before the capped 35 Mbps) for us to have a look at along with the full contents of the --pbParams & --stats data?
You do seem to have very low attainable rates (Max) for such low attenuation values.
Surprisingly, there isn't that much spare SNRM either & TX power looks rather low at first glance.
-
Hi gab81 & welcome to the Kitz forum.
Do you have any snapshot/ongoing graphs (recent and from before the capped 35 Mbps) for us to have a look at along with the full contents of the --pbParams & --stats data?
You do seem to have very low attainable rates (Max) for such low attenuation values.
Surprisingly, there isn't that much spare SNRM either & TX power looks rather low at first glance.
many thanks for the warm welcome, here's fresh stats just collected 5 mins ago (i don't have any old graphs since i unlocked recently) and yeah i can almost see the fibre cab from my window :-)
# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 11025 Kbps, Downstream rate = 46712 Kbps
Path: 0, Upstream rate = 9995 Kbps, Downstream rate = 35000 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): 8.5 6.5
Attn(dB): 0.0 0.0
Pwr(dBm): 12.0 -6.6
VDSL2 framing
Path 0
B: 239 235
M: 1 1
T: 64 7
R: 0 16
S: 0.2182 0.7508
L: 8799 2717
D: 1 1
I: 240 255
N: 240 255
Counters
Path 0
OHF: 9162486 1297178
OHFErr: 100 169
RS: 0 3574665
RSCorr: 0 1259
RSUnCorr: 0 0
Path 0
HEC: 52 0
OCD: 0 0
LCD: 0 0
Total Cells: 2159532391 0
Data Cells: 69434444 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1217 1764
SES: 28 0
UAS: 341 341
AS: 32116
Path 0
INP: 0.00 0.00
PER: 3.49 11.82
delay: 0.00 0.00
OR: 59.57 152.21
Bitswap: 1915 481
Total time = 1 days 13 hours 45 min 41 sec
FEC: 0 0
CRC: 8930 0
ES: 1217 1764
SES: 28 0
UAS: 341 341
LOS: 0 0
LOF: 0 0
Latest 15 minutes time = 41 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 1 0
ES: 1 11
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 13 hours 45 min 41 sec
FEC: 0 0
CRC: 140 0
ES: 118 192
SES: 0 0
UAS: 126 126
LOS: 0 0
LOF: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 2154 0
ES: 205 331
SES: 7 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Since Link time = 8 hours 55 min 15 sec
FEC: 0 1259
CRC: 100 169
ES: 82 141
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
# xdslcmd info --pbParams
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 11035 Kbps, Downstream rate = 46712 Kbps
Path: 0, Upstream rate = 9995 Kbps, Downstream rate = 35000 Kbps
Discovery Phase (Initial) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)
Medley Phase (Final) Band Plan
US: (0,95) (880,1195) (1984,2771)
DS: (32,859) (1216,1959) (2792,4083)
VDSL Port Details Upstream Downstream
Attainable Net Data Rate: 11035 kbps 46712 kbps
Actual Aggregate Tx Power: - 6.6 dBm 12.0 dBm
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 0.1 7.4 10.4 N/A 4.4 10.2 18.3
Signal Attenuation(dB): 0.1 7.4 10.4 N/A 4.4 10.2 18.3
SNR Margin(dB): 6.1 7.0 6.3 N/A 8.6 8.6 8.1
TX Power(dBm): -11.3 -128.0 -8.4 N/A 9.8 7.4 0.6
# xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 11025 Kbps, Downstream rate = 46712 Kbps
Path: 0, Upstream rate = 9995 Kbps, Downstream rate = 35000 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): 8.5 6.5
Attn(dB): 0.0 0.0
Pwr(dBm): 12.0 -6.6
VDSL2 framing
Path 0
B: 239 235
M: 1 1
T: 64 7
R: 0 16
S: 0.2182 0.7508
L: 8799 2717
D: 1 1
I: 240 255
N: 240 255
Counters
Path 0
OHF: 9224113 1315419
OHFErr: 100 172
RS: 0 428678
RSCorr: 0 1270
RSUnCorr: 0 0
Path 0
HEC: 52 0
OCD: 0 0
LCD: 0 0
Total Cells: 2174057474 0
Data Cells: 69435177 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1217 1767
SES: 28 0
UAS: 341 341
AS: 32332
Path 0
INP: 0.00 0.00
PER: 3.49 11.82
delay: 0.00 0.00
OR: 59.57 152.21
Bitswap: 1956 481
and all this with a ping of 5-6ms which is pretty awesome.
following graphs, they are not on 24/7 though..
thanks a lot!
Gabrio
-
here stats:
-
btw something interesting, i just realized that in the last graphs i collected earlier today, the green lines were not there in the frequencies, it seems like it's populating those blanks now.... good or bad?
see this one, 12.00 today:
-
We can see from your Band Plans that you are connected to an ECI DSLAM.
QLN & Hlog data is only collected during the training stage when a connection syncs/resyncs & remains static until the next resync.
SNR & Bitloading is constantly monitored & updated (unless using the new 35m BLOB, when Bitloading also remains static until the next resync).
ECI DSLAMS occasionally send upstream data at a resync (shown green), whereas Huawei DSLAMS never send it.
So, occasionally seeing US data in the current (snapshot) graphs is actually a good thing.
Looking at your Hlog graph, apart from it being slightly wavy in the higher frequency D3 band, I can't see any issues & it confirms very low attenuation per frequency tone.
However, your QLN graph does show quite a high level of background 'noise'. No doubt hence the low SNR, SNRM & Attainable rate values.
I would usually have expected SNRM values to be around 20 (or more) for your 40 Mb connection i.e. loads of scope for stability & higher speeds.
Your connection is currently operating on fastpath for DS & US (D: = 1 for both), which probably explains the low ping times.
Impulse Noise Protection is zero for US & DS, as is delay.
We can see quite a few errored seconds though, along with fairly low values of CRC/HEC errors.
On their own, that doesn't look too bad, but they do seem quite high for a connection with such low attenuation values.
It's a pity you don't have any older stats for comparison, so it's impossible to say if the highish background noise etc. is a recent issue.
That may well be the cause of the 35 Mbps capping, although I have read somewhere that Sky customers are placed on more 'stable' (lower speed) profiles than other FTTC users.
I can't confirm that as fact though.
If possible, I would try to allow monitoring 24/7, at least for a few days, in order to obtain a longer term picture of your connection's performance/statistics before pursuing anything with Sky.
The connection must have resynced yesterday (possibly around 3:00 pm)?
Was that initiated by yourself (maybe via a modem reboot, power cycle or disconnecting from/reconnecting to the master socket)?
If you wished to use the attached updated GRAPH6.exe in place of the original one, it will provide connection up time at the time the data is collected.
The first program update is also now due, possibly this week or next.
It will provide a bit more data along with collecting the ongoing stats a little more efficiently etc.
-
We can see from your Band Plans that you are connected to an ECI DSLAM.
QLN & Hlog data is only collected during the training stage when a connection syncs/resyncs & remains static until the next resync.
SNR & Bitloading is constantly monitored & updated (unless using the new 35m BLOB, when Bitloading also remains static until the next resync).
ECI DSLAMS occasionally send upstream data at a resync (shown green), whereas Huawei DSLAMS never send it.
So, occasionally seeing US data in the current (snapshot) graphs is actually a good thing.
Looking at your Hlog graph, apart from it being slightly wavy in the higher frequency D3 band, I can't see any issues & it confirms very low attenuation per frequency tone.
However, your QLN graph does show quite a high level of background 'noise'. No doubt hence the low SNR, SNRM & Attainable rate values.
I would usually have expected SNRM values to be around 20 (or more) for your 40 Mb connection i.e. loads of scope for stability & higher speeds.
Your connection is currently operating on fastpath for DS & US (D: = 1 for both), which probably explains the low ping times.
Impulse Noise Protection is zero for US & DS, as is delay.
We can see quite a few errored seconds though, along with fairly low values of CRC/HEC errors.
On their own, that doesn't look too bad, but they do seem quite high for a connection with such low attenuation values.
It's a pity you don't have any older stats for comparison, so it's impossible to say if the highish background noise etc. is a recent issue.
That may well be the cause of the 35 Mbps capping, although I have read somewhere that Sky customers are placed on more 'stable' (lower speed) profiles than other FTTC users.
I can't confirm that as fact though.
If possible, I would try to allow monitoring 24/7, at least for a few days, in order to obtain a longer term picture of your connection's performance/statistics before pursuing anything with Sky.
The connection must have resynced yesterday (possibly around 3:00 pm)?
Was that initiated by yourself (maybe via a modem reboot, power cycle or disconnecting from/reconnecting to the master socket)?
If you wished to use the attached updated GRAPH6.exe in place of the original one, it will provide connection up time at the time the data is collected.
The first program update is also now due, possibly this week or next.
It will provide a bit more data along with collecting the ongoing stats a little more efficiently etc.
hi
thanks a lot for the very detailed answer, wish there was a guide to understand all parameters!!! I will leave it for a few days and post data let's say wednesday. I can tell something is changing though, U SNR is going up for one band, in fact attainable sync is slowly going up too, right now it's 11057. D SNR also changing a bit and attainable sync is on 46860 - 47000ish right now.
i did test the background noise some weeks ago with that special phone number and the voice said "i detect little noise, your line is OK". can't remember the number....
and yes, connection resynced yesterday, i "tried" to change SNR with the "configure" parameter but nothing happened, tried twice, didn't work, didn't touch it anymore.
thanks
Gabrio
-
thanks a lot for the very detailed answer, wish there was a guide to understand all parameters!!! I will leave it for a few days and post data let's say wednesday. I can tell something is changing though, U SNR is going up for one band, in fact attainable sync is slowly going up too, right now it's 11057. D SNR also changing a bit and attainable sync is on 46860 - 47000ish right now.
i did test the background noise some weeks ago with that special phone number and the voice said "i detect little noise, your line is OK". can't remember the number....
I suppose that must be a Sky number.
I use the usual BT 17070 number for my Plusnet connection, but it doesn't mention anything about detected noise levels.
and yes, connection resynced yesterday, i "tried" to change SNR with the "configure" parameter but nothing happened, tried twice, didn't work, didn't touch it anymore.
That does work with the HG612 modem, but only when used with an ADSL connection.
DLM fully controls a number of things for VDSL2 (FTTC) connections, the SNR tweak being one of them that has no effect.
-
thanks a lot for the very detailed answer, wish there was a guide to understand all parameters!!! I will leave it for a few days and post data let's say wednesday. I can tell something is changing though, U SNR is going up for one band, in fact attainable sync is slowly going up too, right now it's 11057. D SNR also changing a bit and attainable sync is on 46860 - 47000ish right now.
i did test the background noise some weeks ago with that special phone number and the voice said "i detect little noise, your line is OK". can't remember the number....
I suppose that must be a Sky number.
I use the usual BT 17070 number for my Plusnet connection, but it doesn't mention anything about detected noise levels.
and yes, connection resynced yesterday, i "tried" to change SNR with the "configure" parameter but nothing happened, tried twice, didn't work, didn't touch it anymore.
That does work with the HG612 modem, but only when used with an ADSL connection.
DLM fully controls a number of things for VDSL2 (FTTC) connections, the SNR tweak being one of them that has no effect.
Got it, yes i have a sky phone number and yeah that's the number, i just tried it and Zoe was quite happy, i tried the test 1) success and the 4) echo/noise, she said "there is no echo on your line and there is very little noise, your line is working properly. tried this like 4 times, same result.
thanks
Gab
-
Gentlefolk,
Our experiences suggest that those lines that have had a fixed cap applied usually on 15, 20, 25, 30 or 35 Mbps are permanently fixed until a BT Openreach engineer has visited with his test instrument and then (s)he remembers to "reset the DLM".
Why some lines are capped at those values and some not still remains a mystery - at least to me.
Kind regards,
Walter
hi there
my line (40/10) seems to be "capped" down at 35000 since a few weeks, however i had a few ping changes and upload speed too.....current stats:
Max: Upstream rate = 10993 Kbps, Downstream rate = 46708 Kbps
Path: 0, Upstream rate = 9995 Kbps, Downstream rate = 35000 Kbps
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 0.1 7.4 10.4 N/A 4.4 10.2 18.3
Signal Attenuation(dB): 0.1 7.4 10.4 N/A 4.4 10.2 18.3
SNR Margin(dB): 6.5 6.9 6.2 N/A 8.6 8.6 8.2
TX Power(dBm): -11.3 -128.0 -8.4 N/A 9.8 7.4 0.6
worth to wait some more weeks rather than calling Sky and asking for a profile reset? this past friday ping went down to an awesome 5-6ms from 13ms which i had previously, so DLM is doing "something" but i wouldn't like if they might mess up the ping....
thanks
Gab
that attainable looks horrid for the attenuation, it should be capable of over 100mbit so an easy 40/10 sync.
or have I misread the data?
--edit--
just looked at your graphs, your QLN is extremely high, the worst I have ever seen posted on any site, :( Deffo an underperforming line.
-
Gentlefolk,
Our experiences suggest that those lines that have had a fixed cap applied usually on 15, 20, 25, 30 or 35 Mbps are permanently fixed until a BT Openreach engineer has visited with his test instrument and then (s)he remembers to "reset the DLM".
Why some lines are capped at those values and some not still remains a mystery - at least to me.
Kind regards,
Walter
hi there
my line (40/10) seems to be "capped" down at 35000 since a few weeks, however i had a few ping changes and upload speed too.....current stats:
Max: Upstream rate = 10993 Kbps, Downstream rate = 46708 Kbps
Path: 0, Upstream rate = 9995 Kbps, Downstream rate = 35000 Kbps
============================================================================
VDSL Band Status U0 U1 U2 U3 D1 D2 D3
Line Attenuation(dB): 0.1 7.4 10.4 N/A 4.4 10.2 18.3
Signal Attenuation(dB): 0.1 7.4 10.4 N/A 4.4 10.2 18.3
SNR Margin(dB): 6.5 6.9 6.2 N/A 8.6 8.6 8.2
TX Power(dBm): -11.3 -128.0 -8.4 N/A 9.8 7.4 0.6
worth to wait some more weeks rather than calling Sky and asking for a profile reset? this past friday ping went down to an awesome 5-6ms from 13ms which i had previously, so DLM is doing "something" but i wouldn't like if they might mess up the ping....
thanks
Gab
that attainable looks horrid for the attenuation, it should be capable of over 100mbit so an easy 40/10 sync.
or have I misread the data?
--edit--
just looked at your graphs, your QLN is extremely high, the worst I have ever seen posted on any site, :( Deffo an underperforming line.
hi there,
thanks for the comment hehe ;D
Actually the guys here on the forum have already given me their feedback and yeah i know about the noise levels (Zoe's test number gives "very little noise" so thats strange indeed). i can almost have coffee inside the cabinet LOL... i am doing monitoring all this week and will post stats next monday from 1 week worth of data.
it should defo attach higher but i'd be happy to see back 40 since i am paying the 40/10 package so it doesn't matter.
just for the note i have Huawei modem on a ECI cabinet and cap should be lifted sometime around 50-60th day according to the "theory" and 3 steps down which happened (read previous posts).
ciao!
Gabrio
-
The capping only affects actual sync not attainable but yeah luckily you only on 40/10 anyway so currently not losing too much speed.
under 9db snr margin, the crosstalk is brutal on your line for sure.
thanks for the posts, they a massive eye opener, you seem the #1 candidate for vectoring now :D
-
The capping only affects actual sync not attainable but yeah luckily you only on 40/10 anyway so currently not losing too much speed.
under 9db snr margin, the crosstalk is brutal on your line for sure.
thanks for the posts, they a massive eye opener, you seem the #1 candidate for vectoring now :D
LOL to be honest with you it's a highly populated area, in the proximity with a radius of say 300m there are like 4 fibre cabinets but i cannot tell how many ppl are connected on fibre. if u read the story, something happened on that sunday 16th june, somebody speculated that they connected someone and that in fact did the crosstalk in first place, but seriously, on a sunday, possible? oh well, i am happy with this connection anyway ;D ping is just great, 5ms
-
BTW, just out of curiosity, my Huawei Modem + Sky Router + Cordless phone are connected to the power mains with a 4-gang extension w/ surge protector, I just read another post someone removing it and SNR improved... worth a quick disconnect or not?
-
Hello guys, so here's one week+ of statistics of what is happening on my line, which as some have said, would be a great candidate for vectoring anyway.
My observations:
- On the uptime graph you will find 2 instances where the connection seems to have resynced, in the first case (31.07 @ 12.00) it was an automatic resync, soon after that i had "retrain reason = 2".
- The second instance (31.07 @ 20.00 approx) it was me removing the power surge protector since i read of a case influencing the modem's performance. Unfortunately i didn't notice the resync happening at 12.00 that day.
As you can see these 2 events have impacted the signal in some way, in particular i noticed that the power of the D3 band was going down, was that connected to the removal of the surge protector or the fact of the automatic resync?
Also, D3 SNRM was going down on 31.07 @ 12.00 but then picked up again....?
Finally, on that very same day, 31.07, from the other graphs we observe that some new tones have been discovered (31.07 @ 16.27 until 20.58 that day) and the QLN graph was also different, was it improving or not? I cannot understand that. After i disconnected the surge protector, things changed, less tones discovered and since then to now it has been discovering a bit different tones here and there.
So it's now 50 days since the day i lost speed for the first time, i am wondering if the 35000 banding will finally go away around this week reaching the 56th day? Or due to the physical conditions of the line will always stay like that.
Off to the graphs, here we are!
31.07 - 16.27 > automatic resync, retrain reason 2
31.07 - 20.58 > resync from me removing surge protector
05.08 - 12.00 > stats i have today
and 7 days full monty > stats i have today
Cheers for comments guys!!
Gabrio
-
It seems that Razpag is the expert to this matter, just curious, what do you think about this funny situation, will the 39996 ever going to be back or i'd need to pester Sky?
Thanks!
-
Watch that razpag geezer, he's an animal. ;D
TBH, there are a lot of folk better placed on here these days, who have conducted lengthy tests and attained a far greater knowledge of DLM, than that razpag fool.
BE, B*Cat, Asbo, Eric, (and now Kitz herself), are definitely the ones to approach with all things DLM. Apologies if I've missed anybody else who should belong on that list. :-\
-
Hehe good one... Anyone else wishing to comment if i will get the 39996 itself alone at some point? I am somehow reluctant to call sky. One thing is clear to me, is a cabling issue or cross talk otherwise i cant explain all the line noise and low attn rate being just 140 meters from the cabinet....oh well.....