|
|
I was wondering, based on observations, if anyone knows roughly what the ES or CRC's have to be before DLM may take action in a negative way? The reason I ask this is because, for the moment, I've managed to get myself back on 'fastpath', albeit with a speed cap. I'll explain what I did in order for this to perhaps encourage DLM to get me back there to start with.
Approximately 10 days ago I decided to go back to my Fritz!Box and cap myself to a much lower speed, eventually I set myself to 40 megabits downstream, with no cap on the upstream. My objective was to keep the error seconds under at least 75, or further if I could (under 50). A few days into that experiment DLM decided to reduce my INP from 4 to 3. After 7 days into the experiment I lost hope with DLM switching me back so I decided to go back to the HG612 since it synced better and surprisingly had less errors than my Fritz!Box, though it was capped at 60 megabits downstream due to the DLM altering the min/max rates as a result of me doing so. A few days later (today in other words) at 4am or so DLM resynced me, and to my amazement, though it hasn't removed the downstream cap, it did remove INP and delay altogether! Sadly, I fear I may lose 'fastpath' as my error seconds have gone up to over 100 ES in around 5 hours of sync uptime  . If that rate of ES continues I am expecting to probably get around 300-400 ES in a 24 hour period I imagine.
I've also read, on the TalkTalk forum, that Biohead did a test where his cabinet, like mine, is ECI hardware. He was using an ECI modem but wanted to use Huawei presumably for line stats, so he lost 'fastpath' apparently during that time of using the Huawei. When he went back to the ECI he shortly got back 'fastpath'. I wonder if it's worth me finding an ECI modem on eBay or somewhere and trying that on my line?
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
5253
5455
5657
5859
6061
6263
6465
6667
6869
7071
7273
7475
7677
7879
8081
8283
8485
8687
8889
9091
9293
9495
9697
9899
100101
102103
104105
106107
108109
110111
| BusyBox v1.9.1 (2010-10-15 17:59:06 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.
# xdslcmd info --statsxdslcmd info --stats
xdslcmd: ADSL driver and PHY statusStatus: Showtime
Retrain Reason: 2Max: Upstream rate = 27652 Kbps, Downstream rate = 85332 Kbps
Path: 0, Upstream rate = 20000 Kbps, Downstream rate = 59999 Kbps
Link Power State: L0Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17aTPS-TC: PTM Mode
Trellis: U:ON /D:ONLine Status: No Defect
Training Status: Showtime Down Up
SNR (dB): 13.0 9.7Attn(dB): 0.0 0.0
Pwr(dBm): 12.4 4.8 VDSL2 framing
Path 0B: 239 236
M: 1 1T: 64 5
R: 0 16S: 0.1273 0.3771
L: 15081 5410D: 1 1
I: 240 255N: 240 255
Counters Path 0
OHF: 9133198 310238OHFErr: 127 57
RS: 0 542951RSCorr: 0 406
RSUnCorr: 0 0
Path 0HEC: 915 0
OCD: 0 0LCD: 0 0
Total Cells: 2153866054 0Data Cells: 690838 0
Drop Cells: 0Bit Errors: 0 0
ES: 156 362
SES: 5 0UAS: 249 249
AS: 18678
Path 0INP: 0.00 0.00
PER: 2.03 6.12delay: 0.00 0.00
OR: 90.32 203.67
Bitswap: 203 12
Total time = 1 days 14 hours 55 min 2 secFEC: 0 0
CRC: 127 0ES: 156 362
SES: 5 0UAS: 249 249
LOS: 4 0LOF: 5 0
Latest 15 minutes time = 10 min 2 secFEC: 0 0
CRC: 5 0ES: 3 3
SES: 0 0UAS: 0 0
LOS: 0 0LOF: 0 0
Previous 15 minutes time = 15 min 0 secFEC: 0 0
CRC: 8 0ES: 7 1
SES: 0 0UAS: 0 0
LOS: 0 0LOF: 0 0
Latest 1 day time = 14 hours 55 min 2 secFEC: 0 0
CRC: 127 0ES: 113 138
SES: 5 0UAS: 22 22
LOS: 4 0LOF: 5 0
Previous 1 day time = 24 hours 0 secFEC: 0 0
CRC: 0 0ES: 43 224
SES: 0 0UAS: 227 227
LOS: 0 0LOF: 0 0
Since Link time = 5 hours 11 min 17 secFEC: 0 406
CRC: 127 57ES: 100 50
SES: 0 0UAS: 0 0
LOS: 0 0LOF: 0 0 |
|
|
|
I wonder if it's worth me finding an ECI modem on eBay or somewhere and trying that on my line? Can't see why not. Go for it.
|
|
|
|
I'm running a Huawei modem on and ECI DSLAM and if interleaving gets applied to the line for whatever reason it usually switches back to fastpath within about 4 weeks, usually less.
Mind are those your current stats you posted because it's already on fastpath it think? Line 31: which I believe is the interleave depth is set to 1 which is fastpath. I'm sure I will be corrected if I've got it wrong.
|
|
Register (or login) on our website and you will not see this ad.
|
|
|
|
Yes they are the current stats. I was on interleaving however with an INP of 3, which for a while I've been trying various ways to encourage DLM to put me back on to INP 0, no interleaving depth (1) and no delay. Currently loving my low ping, and would happily live with less speed (between 40-60 megabits downstream with 20 megabits upstream) for the lowest possible ping if there was an option to specify a permanent capped rate profile at the cabinet.
I may buy an ECI modem tomorrow though, if there are any for sale still on eBay at that time, and unlocked if I can find one. I have a strong feeling though that based on my expected ES after 24 hours that DLM will soon put me back to INP 2 or 3 at the very least.
|
|
|
Are you using a game server that applies compensation for latency?
I've seen several reports on here that a very low ping can cause them to overdo that and you end up worse off in the game than before.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 52.9/14.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
Edited by RobertoS (Sun 04-Nov-12 11:59:17)
|
|
|
|
I mainly play Team Fortress 2 and host 12 TF2 Mann vs Machine servers on my home server. This engine does have lag compensation in it, but I don't notice any bad effects from having a lower ping. Interesting point though.
|
|
|
I may buy an ECI modem tomorrow though, if there are any for sale still on eBay at that time, and unlocked if I can find one. I have a strong feeling though that based on my expected ES after 24 hours that DLM will soon put me back to INP 2 or 3 at the very least.
Don't know if it's the new type or old type ECI though
www.ebay.co.uk/itm/150936594263
|
|
|
|
Thanks. I've bought one. Hopefully it'll resolve the rather continuous and regular 1-2 CRC's every minute or two that I'm getting right now.
|
|
|
|
It would be good to explore the line statistics provided by the ECI. Measurements for HLog, HLin, SNR, QLN and Bit Depth should be available for individual subcarriers. Perhaps they are not necessarily provided via that Unix pipe mechanism though. Though for the function of DSL itself, the measurements must be recorded somewhere by the modem though. Something to incorporate into your graphing tool, Ixel? BT Openreach has released a fairly complete source code tarball for the ECI and its Lantiq XWAY platform. Clues for obtaining very detailed line statistics should be in there.
cheers, a
|
|
|
|
Thanks for the tips. I'm new to this pipe mechanism, but I will check out the source and see what I can make of it for adapting into a variant of my current unreleased C#.NET graphing/stats application.
On an additional note, I'm amazed that DLM didn't intervene this morning and re-apply INP, given my ES and CRC's were both about 600-700 range in a 24 hour period. Perhaps it has a delay before taking another action, or recognises that the CRC's themselves are not significantly high (e.g. 20+ per minute, where as mine are about 1-2 per minute). If Royal Mail are efficient then I should be receiving the unlocked ECI tomorrow.
|
|
|
FWIW, I've not had much time to play about yet, so the best I've been able to obtain from an unlocked ECI modem on a live (remotely accessed) VDSL2 connection so far, using an amended version of one of my scripts is as follows:-
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
5051
5253
5455
5657
5859
6061
6263
6465
6667
6869
7071
7273
7475
76 | =~=~=~=~=~=~=~=~=~=~=~= Plink log 2012.10.13 23:00:51 =~=~=~=~=~=~=~=~=~=~=~=
login as: adminpassword:
BusyBox v1.00 (2011.08.09-03:28+0000) Built-in shell (msh)
Enter 'help' for a list of built-in commands.
Alpha # Alpha # echo "g997lspbg 1" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack nReturn=0 nDirection=0 LATN[0]=132 LATN[1]=305 LATN[2]=489 LATN[3]=-32768 LATN[4]=-32768 SATN[0]=117 SATN[1]=302 SATN[2]=484 SATN[3]=-32768 SATN[4]=-32768 SNR[0]=57 SNR[1]=56 SNR[2]=59 SNR[3]=-32768 SNR[4]=-32768
Alpha #
Alpha # echo "g997lspbg 0" > /tmp/pipe/dsl_cpe0_cmdAlpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nDirection=0 LATN[0]=2 LATN[1]=225 LATN[2]=364 LATN[3]=-32768 LATN[4]=-32768 SATN[0]=1 SATN[1]=223 SATN[2]=362 SATN[3]=-32768 SATN[4]=-32768 SNR[0]=68 SNR[1]=69 SNR[2]=63 SNR[3]=-32768 SNR[4]=-32768
Alpha # Alpha # echo "g997listrg 1" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack nReturn=0 nDirection=1 G994VendorID=IFTN SystemVendorID=ECI tele VersionNumber= SerialNumber=7035497883 SelfTestResult=0 XTSECapabilities=(00,00,00,00,00,00,00,00)
Alpha #
Alpha # echo "g997lsg 1 1" > /tmp/pipe/dsl_cpe0_cmdAlpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nLineState=0x801
nReturn=0 nLineState=0x801
Alpha # Alpha # echo "g997lsg 0 1" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack nReturn=0 nDirection=0 nDeltDataType=1 LATN=0 SATN=0 SNR=64 ATTNDR=21918632 ACTPS=-901 ACTATP=125
Alpha #
Alpha # echo "g997csg 1 1" > /tmp/pipe/dsl_cpe0_cmdAlpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=-22Alpha # Alpha # echo "g997csg 0 1" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack nReturn=0 nChannel=0 nDirection=1 ActualDataRate=67868000 PreviousDataRate=73992000 ActualInterleaveDelay=975 ActualImpulseNoiseProtection=30
Alpha #
Alpha # echo "bbsg 0" > /tmp/pipe/dsl_cpe0_cmdAlpha # cat /tmp/pipe/dsl_cpe0_ack
nReturn=0 nDirection=0 nNumData=3
nFormat=(nBandIndex, (nLimit_firstToneIndex, nLimit_lastToneIndex), (nBorder_firstToneIndex, nBorder_lastToneIndex)) nData="
(00,(0010,0031),(0010,0031))
(01,(0882,1193),(0882,1193))
(02,(1984,2770),(1984,2770))
"
Alpha # Alpha # echo "bbsg 1" > /tmp/pipe/dsl_cpe0_cmd
Alpha # cat /tmp/pipe/dsl_cpe0_ack nReturn=0 nDirection=1 nNumData=3
nFormat=(nBandIndex, (nLimit_firstToneIndex, nLimit_lastToneIndex), (nBorder_firstToneIndex, nBorder_lastToneIndex)) nData="
(00,(0033,0857),(0033,0857))
(01,(1218,1959),(1218,1959))
(02,(2795,3950),(2795,3935))
"
Alpha #
Alpha # exit |
Obtaining the stats seems rather unreliable & having quickly read through the released source code, I readily admit to being rather stumped at this stage.
|
|
|
Hopefully I'll have better luck, I've been studying the source code today, interesting. Hopefully the modem will arrive tomorrow morning.
A command that interests me (g997cdrtcg / g997cdrtcs)...
AKA G997_ChannelDataRateThresholdConfigGet / G997_ChannelDataRateThresholdConfigSet:
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
26 | static const DSL_char_t g_sG997cdrtcg[] =
#ifndef DSL_CPE_DEBUG_DISABLE "Long Form: %s" DSL_CPE_CRLF
"Short Form: %s" DSL_CPE_CRLF DSL_CPE_CRLF
"Input Parameter" DSL_CPE_CRLF#if (DSL_CPE_MAX_DEVICE_NUMBER > 1)
"- DSL_uint32_t nDevice (optional, not used in the 'backward compatible' mode)" DSL_CPE_CRLF#endif
"- DSL_uint8_t nChannel" DSL_CPE_CRLF "- DSL_AccessDir_t nDirection" DSL_CPE_CRLF
" upstream = 0" DSL_CPE_CRLF " downstream = 1" DSL_CPE_CRLF
DSL_CPE_CRLF "Output Parameter" DSL_CPE_CRLF
"- DSL_Error_t nReturn" DSL_CPE_CRLF#if (DSL_CPE_MAX_DEVICE_NUMBER > 1)
"- DSL_uint32_t nDevice (optional, not used in the 'backward compatible' mode)" DSL_CPE_CRLF#endif
"- DSL_uint8_t nChannel" DSL_CPE_CRLF "- DSL_AccessDir_t nDirection" DSL_CPE_CRLF
" upstream = 0" DSL_CPE_CRLF " downstream = 1" DSL_CPE_CRLF
"- DSL_uint32_t nDataRateThresholdUpshift" DSL_CPE_CRLF "- DSL_uint32_t nDataRateThresholdDownshift" DSL_CPE_CRLF
DSL_CPE_CRLF ""; |
Is this possibly a command that will restrict the maximum downstream/upstream to what you specify (specifically the set command that is)?
For example, I imagine if I wanted to set on the downstream a max rate of 70,000 Kbps and a min rate of 60,000 Kbps I would do the following...
| Text | 1
| g997cdrtcs 0 1 70000 60000 |
That's assuming that's what it does, and that's also assuming I'm right in believing it's channel 0.
Edited by Ixel (Mon 05-Nov-12 18:30:57)
|
|
|
Just an update to say to others that I've received the unlocked ECI modem this morning and so far (touch wood) there has been absolutely no errors on the upstream or downstream, unless the GUI is wrong (which I hope not). I usually have errors within at least 5 minutes of sync, but I've been synced for nearly 30 minutes without any so far.
At this time, it appears true that you should use an ECI modem on an ECI cabinet, my Fritz!Box 7390 and HG612 both produced errors within 5 minutes of sync uptime. My attainable rates are slightly different however, downstream is virtually identical to the HG612 for me (85000Kbps or so), but the upstream has lost about 7 megabits (attainable is just below 20000Kbps). Nevermind though, so long as it remains stable (virtually error free), keeps me on fastpath and doesn't drop further, I'm happy  .
I will begin my hunt for commands on telnet and update again once I know more for those who are interested, probably in a different thread though.
|
|
|
Did you end up with the old version - it has 4 rubber feet where the new one has two rubber feet, the other two being solid plastic?
I'm sure that Bald Eagle said that the graphic user interface didn't report correctly, or was just blank, I'm sure he'll be along soon to confirm the situation.
|
|
|
Old version of the modem. Trying to find out what the command for dsl_pipe is to fetch the error stats. Once I have I'll see what they say as opposed to the GUI.
EDIT:
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
| Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh pmcctg 0 1
nReturn=0 nChannel=0 nDirection=1 nElapsedTime=4201 bValid=1 nCodeViolations=0 nFEC=0
Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh pmcctg 0 0nReturn=0 nChannel=0 nDirection=0 nElapsedTime=4221 bValid=1 nCodeViolations=0 nFEC=0
Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997lsg 1 1
nReturn=0 nDirection=1 nDeltDataType=1 LATN=178 SATN=170 SNR=112 ATTNDR=85765760 ACTPS=-901 ACTATP=-3
Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997lsg 0 1nReturn=0 nDirection=0 nDeltDataType=1 LATN=0 SATN=0 SNR=61 ATTNDR=19633716 ACTPS=-901 ACTATP=103
Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997lspbg 1
nReturn=0 nDirection=0 LATN[0]=125 LATN[1]=285 LATN[2]=454 LATN[3]=-32768 LATN[4]=-32768 SATN[0]=134 SATN[1]=283 SATN[2]=453 SATN[3]=-32768 SATN[4]=-32768 SNR[0]=111 SNR[1]=108 SNR[2]=115 SNR[3]=-32768 SNR[4]=-32768
Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997lspbg 0nReturn=0 nDirection=0 LATN[0]=11 LATN[1]=211 LATN[2]=334 LATN[3]=-32768 LATN[4]=-32768 SATN[0]=15 SATN[1]=209 SATN[2]=334 SATN[3]=-32768 SATN[4]=-32768 SNR[0]=60 SNR[1]=61 SNR[2]=61 SNR[3]=-32768 SNR[4]=-32768
Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997csg 0 1
nReturn=0 nChannel=0 nDirection=1 ActualDataRate=59996000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=0
Alpha # /ifx/vdsl2/dsl_cpe_pipe.sh g997csg 0 0nReturn=0 nChannel=0 nDirection=0 ActualDataRate=19460000 PreviousDataRate=0 ActualInterleaveDelay=0 ActualImpulseNoiseProtection=0 |
Edited by Ixel (Tue 06-Nov-12 10:39:34)
|
|
|
I'm sure that Bald Eagle said that the graphic user interface didn't report correctly, or was just blank, I'm sure he'll be along soon to confirm the situation.
This is what can be seen on the connection that I have remote access to:-
| Text | 1
23
45
67
89
1011
1213
1415
1617
1819
2021
2223
2425
2627
2829
3031
3233
3435
3637
3839
4041
4243
4445
4647
4849
| Traffic Statistics
Traffic Statistics display Receive and Transmit packets passing through the Device.
STATISTICSInterface Transmit Receive
Pkts Drops PktsLAN 14063 0 14713
WAN 0 0 0VDSL2 Line Status
Line Status showtime
Band Upstream Downstream
US0 Line Attn 0 0US1/DS1 Line Attn 0 0
US2/DS2 Line Attn 0 0US3/DS3 Line Attn 0 0
US4/DS4 Line Attn 0 0US0 Signal Attn 0 0
US1/DS1 Signal Attn 0 0US2/DS2 Signal Attn 0 0
US3/DS3 Signal Attn 0 0US4/DS4 Signal Attn 0 0
US0 Actual SNR 0 0US1/DS1 Actual SNR 0 0
US2/DS2 Actual SNR 0 0US3/DS3 Actual SNR 0 0
US4/DS4 Actual SNR 0 0
Channel Status Upstream DownstreamActual Net Data Rate 20000000 kbps 73992000 kbps
Actual Interleave Delay 0 ms 0 msActual INP 0 Symbols 0 Symbols
Attainable Net Data Rate 22204773 kbps 79386368 kbpsTransmit Power 119 dBm 61 dBm
Current 15 mins Near End Far End
CRC 0 0 FEC 4294967252 0
ES 0 0 SES 0 0
UAS 0 0
24 hours Near End Far EndCRC 4294967291 0
FEC 4294967243 0 ES 0 0
SES 0 0 UAS 0 0 |
Some of that lot looks a bit wrong, too many decimal places or complete zeros that can't be correct, can it?
As it's a live connection & not my own, I can't mess about with it too much in the way of experimenting.
I'm also rather busy with other things at this time, so don't really have time to play about with scripts etc.
I might get some time after Christmas, but hopefully it will all be sorted by then anyway 
|
|
|
|
Some of that is definitely wrong. Interestingly if you study the HTML source of the inner frame you'll see JavaScript variables for things such as SATN, but not used in the GUI. The values given in the GUI for sync rate/attainable rate are actually bps, not Kbps, so divide them by 1000 and round for the Kbps value. This is what I did in my ECIModem Plotter (preview screenshot on the forum I posted it on).
|
|
|
|
guys this sounds scary to me.
it sounds like FTTC DLM is worse than ADSL DLM in that it constantly reboots connections either to relax settings or tighten them up. So a line eg. might get interleaved after a flood of noice, is stable but then DLM itself a week later will put a gap in the uptime by forcing a resync back to fast path, then might be another set of line errors back to interleaving again so the line is forced unstable by DLM itself.
About half of FTTC graphs I have seen (tbb graphs) have a red line showing a resync.
|
|
|
ADSL DLM runs for the life of a connection too, and adjusts target margins / interleaving options if left to run in auto mode
|
|
The author of the above post is a thinkbroadband staff member. It may not constitute an official statement on behalf of thinkbroadband.
|
|
|
guys this sounds scary to me.
it sounds like FTTC DLM is worse than ADSL DLM in that it constantly reboots connections either to relax settings or tighten them up. So a line eg. might get interleaved after a flood of noice, is stable but then DLM itself a week later will put a gap in the uptime by forcing a resync back to fast path, then might be another set of line errors back to interleaving again so the line is forced unstable by DLM itself.
About half of FTTC graphs I have seen (tbb graphs) have a red line showing a resync. This antiquated idea used for adsl and now FTTC clearley does not work for some customers and there should be an option for DLM to be disabled/over ridden by the ISP , whilst the reasoning behind dlm is mainly to save on tech support costs for some if not all the big mass market isp's there are plenty of smaller niche isp's out there too, and the option should be given by BT openreach/wholesale ect ect to all Isp's buying the product wholesale from them ,Giving the isp the choice to use or not use this method of capping the connection. as BT are no longer the ones libable to provide the end user with Tech support, if i was to consider FTTx it would be the on demand product as a connection with induced lag is not worth the money IMO
Edited by tommy45 (Sun 25-Nov-12 19:32:12)
|
|
|
it sounds like FTTC DLM is worse than ADSL DLM in that it constantly ...
I guess it depends on your definition of "constantly".
DLM seems to intervene within 24 hours of the MTBE (or MTBD) going beyond the "red" threshold, and seems to take up to 4 weeks to undo the intervention when MTBE/MTBD holds better than the "green" threshold.
By the strict meaning of the word "constantly", then yes - DLM works forever. By the implied derogatory meaning (where "constantly" implies that changes happen too often), then No - I think the FTTC DLM has pretty serene response times.
If BT set the red & green thresholds sufficiently far apart, the hysteresis should prevent DLM from regularly flip-flopping. However, even if they aren't quite right, a flip-flop period of 28 days isn't too bad (though a 27:1 mark:space ratio isn't good).
Note: I don't know the thresholds for FTTC, but I saw something suggesting that for ADSL2+ on a "standard" profile (not the "stable" or "superstable" profiles) the red threshold was an MTBE of 60 seconds, and the green was an MTBE of 600 seconds.
In that setup, DLM would leave the line alone with a 24-hour error count of between 144 and 1440.
|
|
|
In that setup, DLM would leave the line alone with a 24-hour error count of between 144 and 1440.
FWIW, I'm currently remotely monitoring a new VDSL2 (FTTC) connection (Interleaving is still OFF - for now) where Error Seconds in just 12hours have exceeded 13000.
Sync speeds are 11397kbps DS & 563kbps US (yes, only 563k US).
I imagine Interleaving will be turned ON at quite a high depth by tomorrow afternoon.
When I've finished monitoring this connection, I'll be watching another where VDSL2 DS sync speed is currently around 4Mb (usually lower than 3Mb).
This is NOT an Infinity connection & speeds were not expected to be "superfast".
|
|
|
FWIW, I'm currently remotely monitoring a new VDSL2 (FTTC) connection (Interleaving is still OFF - for now) where Error Seconds in just 12hours have exceeded 13000.
Sync speeds are 11397kbps DS & 563kbps US (yes, only 563k US).
I imagine Interleaving will be turned ON at quite a high depth by tomorrow afternoon.
Yup, I imagine so.
I guess the theresholds need to be scaled by the relative number of CRC blocks being transmitted.
In ADSL, a superframe takes 17ms or so, which implies 58 CRC codes per second.
I don't know about VDSL2, or even if there is a fixed rate, but I guess you get to see the OHF rate by monitoring the stats.
|
|
|
|
yes, but I had never had DLM force a resync, it would only change settings if the line dropped for another reason.
You understand the difference? also am I correct that FTTC DLM forces a resync to change settings or is it like BTw adsl where it only works when the line drops for other reasons?
|
|
|
Is there a variant of SRA for VDSL?
SRA was amazing for my adsl experience. That adapts but the difference is it doesnt interrupt connectivity, it also doesnt toggle interleaving just works on noise margin. According to this doc is also a RRA feature.
http://www.embedded.com/design/connectivity/4007197/...
Edited by Chrysalis (Mon 26-Nov-12 03:02:56)
|
|
|
ok so there is a threshold where its neither too bad or too good.
To give you an idea, my adsl line had 1000s of crc errors a day, this was normal for the line, I did experiment with the SNRM not long before cancelling ukonline (where I had full control of the noise margin) and to get my error rates down to what others typically got maybe less than 100 errors a day I had to goto a noise margin in the high 20s, and had a pretty low sync speed. With the 1000s of crc errors tho the line was still very useable, it had issues when I got 1000s a minute tho.
So the DLM setup you described would have probably bumped the line settings way too conservative, and indeed prior to switching to LLU I had issues of over conservative line settings combined with instability.
I have read there is speed banding now, although I have not heard of any isp using it. Is this a way for DLM to be overriden and a line locked to a speed?
Edited by Chrysalis (Mon 26-Nov-12 03:15:08)
|
|
|
Is there a variant of SRA for VDSL?
I'm pretty sure the equivalent of SRA is built in to the VDSL specification as I'm sure I've had resyncs but you just don't notice them. Not having a static IP, I've not set up a BQM.
Compared to ADSL/ADSL2+, its a non issue.
James BT Infinity 2 19/09/2012 - Estimate 44.6/6.5 - Install 52/12 - Actual 46 / 8 Mbps
13 years of broadband - 1999 ntl:(512k/1M)/BTbusiness(2M)/Metronet(2M)/Bulldog(8M/16M)/BE(19M/16M)/BT FTTC(46M)
Edited by jchamier (Mon 26-Nov-12 08:13:45)
|
|
|
To give you an idea, my adsl line had 1000s of crc errors a day, this was normal for the line, I did experiment with the SNRM not long before cancelling ukonline (where I had full control of the noise margin) and to get my error rates down to what others typically got maybe less than 100 errors a day I had to goto a noise margin in the high 20s, and had a pretty low sync speed.
My (very) old ADSL line (20CN) had a DLM-event very much like the system I just described. Normally it would have almost no errors (10 CRC per hour), but one day got 1,000's in 3 large bursts... and next day had slowed down (via an automatic resync). Some days later, it recovered.
Our first FTTC line suffered 4% packet loss at initial connection due to the error rate (though the modems were locked at the time) DLM acted after 48 hours there, adding interleaving & slowing things down, with the change requiring a resync. The line then stayed like that for months... until the 17a profile was introduced
Our current FTTC line works perfectly at full speed, but the phone line had problems one day in August. Again, DLM reacted (next day) by slowing things down, requiring a resync, and took 3.5 weeks to restore full capability.
Every single one of these changes was made with a visible resync. I suspect that all of them *needed* a resync - I don't think SRA or RRA can cope with turning interleaving on & off at will.
With the 1000s of crc errors tho the line was still very useable, it had issues when I got 1000s a minute tho.
My FTTC line with a 4% packet loss was very useable - but lost around 10% of the ultimate throughput available to it. However, I've seen a line where around 10% loss made it totally unusable.
On ADSL lines, there are 58 CRC checks per second, so it's possible to get up to 3500 per minute... but I'd expect it to be not very useable if you were running at over 350 per minute.
So the DLM setup you described would have probably bumped the line settings way too conservative, and indeed prior to switching to LLU I had issues of over conservative line settings combined with instability.
Yes, it probably would have done. BT's DLM definitely focusses on stability over speed.
I have read there is speed banding now, although I have not heard of any isp using it. Is this a way for DLM to be overriden and a line locked to a speed?
My experience, watching Plusnet handle other subscribers' faults, is that BT employ a number of DLM profiles... which set interleaving to low & high levels, and which *may* also set banded speeds.
This SIN mentions banding of speeds too (section 2.2.1)
The banding seems to be purely a DLM feature, and nothing that an ISP can affect, or select, or even reset.
This Openreach description shows that ISPs can select 1 of 3 settings for DLM: Standard, Stable or Speed. I've never seen an ISP offer to change this setting for a user, so I'm not sure how widespread this setting is but note that this is an *Openreach* setting.
This copy of a 'BT Wholesale' description has slightly different information (section 11). It mentions a Standard, Stable and SuperStable option choice. Again, not seen much at the ISP.
That document (section 13) mentions that DLM policies affect Interleaving, Capping and Impulse Noise Protection, and that the noise margin is set to 6dB for all policies.
But most importantly, it states that these policies are adjusted "to meet target stability".
So it looks like the only thing that an ISP could set is to specify a stability level - but not by directly locking the line to a specific speed.
Note: On 21CN ADSL2 systems, there is a similar setting that BT talks about (the options are Standard, Stable and SuperStable), but few ISPs mention. The information I had shows that the different settings here are in the MTBE thresholds - where Standard has the 60/600 thresholds, the Stable has 600/6000 thresholds, and SuperStable has 6000/60000 thresholds.
|
|
|
|
FTTC DLM appears to force resyncs but it only takes 20-25 secs to resync and most of the time they occur in the early hours of the morning.
|
|
|
|
sorry I meant I still had 0% packetloss and full throughput.
usually my line either worked fully or completely collapsed, I cant remember having situations with 10% lost throughput.
|
|
|
FTTC DLM appears to force resyncs but it only takes 20-25 secs to resync and most of the time they occur in the early hours of the morning.
I use my connection a lot then (do a lot of work during night remotely), also even if I am not using I monitor things with my connection and it will be an annoyance if it drops every night.
With that said tho obviously I am aware this may not happen at all and it may be that I will be in the threshold where DLM leaves me alone, if the line is unstable and DLM keeps changing things then I will ask to go down to 40/10 which provide me with a buffer hopefully as the estimated speed is much higher.
|
|
|
mine resynced 7 times around 1 am now on interleave
BTInfinity - NSDEN using TP-Link W8960n
|
|
|
|
When my connection resyncs "on the fly" it usually only takes 16 seconds.
This is too quick to be spotted by my ISP & BT as a disconnection, a new PPP session is thus NOT initiated & BT's IP Profile is NOT updated.
As my ISP (Plusnet) also uses a line profile (a.k.a. current line speed - slightly lower than BT's IP Profile), that is NOT updated either as they are only informed of any changes whenever BT's IP Profile updates.
|
|
|
Hopefully someone can give me some further info on this, interleaving in particular. Had 80/20 service for 3 months (ADSL24), first two months using laptop connected directly to the modem and got full speed and 11-12ms latency to the bbc. Installed router middle of October and noticed the ping varying by a couple of ms every packet, didn't think much about it and carried on. Noticed ping had gone up and thought interleaving had been applied as router was on and off a few times while my consumer unit was replaced, speeds still as good as before.
Worried about the variation in ping I tested the wan port and it was flapping by a couple of ms even on lan so I replaced the router (TP-Link 3600) with a known good Netgear. Spoke to support and they said BT will not reset the interleaving as a lot of people have found out. Ping is rock steady on the new router so clearly an issue with the Tp-Link.
I've been running a BQM and noticed what I think is a resync today, it seems like a new PPP session is required to update the profile. My question is - as I have no issues with profile speeds, will creating a new PPP session help with my interleaving or should I leave things as they are and hope for the best?
ECI modem on ECI cab so no stats for me and don't want to upset DLM any more by trying a HG on it, BQM link below if anyone can advise on if that is a resync at 1500 and should I create a new PPP session in the hope that interleaving will be updated back to normal?
http://www.thinkbroadband.com/ping/share/71a231556d5...
Many thanks.
|
|
|
|
This is apparently taken from a BT chief engineer's quarterly publication:-
"Each night, the DLM system uses the previous 24hrs of circuit performance data to ascertain whether the mean time between errors or excessive retrain thresholds have been breached on a line. If they have, DLM will place rate caps, interleaving or both, on the line to improve error rate, stability, or both, by the change of its line profile."
|
|
|
DLM controls the interleaving and the sync speed. These are both decided between the cabinet and the modem.
Resetting (disconnect/reconnect) the router to force a new pppoe session will ensure the IP/BRAS profile is reset to match the sync speed. It won't have any effect on the interleaving, or the sync speed.
If you don't have interleaving, the first hop on a tracert will be somewhere around 5/6 ms. Anything above that is due to interleaving. Even though I am on interleaved at the moment (around 8ms extra), a bigger cause of latency is BT's routing from the south to London via Sheffield the hops north and back south add around 10ms extra on the bbc ping between them).
--
Moved (with trepidation) to BT Infinity 2 for upload speed. Happy BE user for several years.
|
|
|
|
All 3 spikes look like resyncs, although the third is obviously of lower duration.
As another posted stated, a new PPP session (as requested by the router, or by a direct PC connection) will have no effect on the need for (or amount of) interleaving or FEC.
As Bald_Eagle stated, DLM tends to look at the average error counts over the last 24 hours, and the number of resyncs, and decides whether it needs to limit your connection speed, or add interleaving.
However, it most certainly isn't as fast at taking things away again when any problems disappear. You can expect to wait for between 1 and 4 weeks for that to happen - so patience is required.
And even then, there's no guarantee. My first line got interleaved after 48 hours, and it stuck forever.
|
|
|
Which is clearly in their favour not those customers who are unduly affected by it, all the more reaon for an opt out from DLM to be provided
And IMO a vaild reason not to bother with FFTC If you are unlucky enough to have a problematic D' side pair be it affected at times by an outside source or even a developing line fault & several weeks is a too long,
I thought this FTTC malarky was supposed to be advaced tech?
Edited by tommy45 (Wed 28-Nov-12 04:05:08)
|
|
|
advaced tech can mean different things.
One is using newer, robust techniques. FTTP is an example of that.
Another is pushing old techniques to (or slighty beyond?) their natural limits. FTTC is an example of that.
--
Moved (with trepidation) to BT Infinity 2 for upload speed. Happy BE user for several years.
|
|
|
Which is clearly in their favour not those customers who are unduly affected by it, all the more reaon for an opt out from DLM to be provided
Who is the "they" that this is in favour of? Certainly there are benefits to end-users, Openreach, Wholesale, ISP and the internet at large.
The only dis-benefit to most end-users is when they don't have a tip-top speed that gives them bragging rights. Some end-users get hit a little heavily - and here I agree that BT have a tendency to rely on DLM rather than fix the line - but it is a small number of users, and certainly not worth cutting off your nose to spite your face.
DLM is a part of the advanced tech that wrings more & more speed out of our copper infrastructure. The next type of advanced technology in the DLM school is known as vectoring, which ought to put back the speed that is otherwise lost from crosstalk. I'd expect that to have direct effects on both aspects contributing to lower speeds: higher SNRM values *and* less need for FEC.
And IMO a vaild reason not to bother with FFTC If you are unlucky enough to have a problematic D' side pair be it affected at times by an outside source or even a developing line fault & several weeks is a too long,
You really do want to chop that nose off, don't you?
The advantage of cabinet-based FTTC here is that it automatically reduces the amount of line that needs to be trouble-shooted to find the problem. The means it ought to be easier to locate than with an exchange-based solution... provided you can get an engineer onto the problem in the first place.
I thought this FTTC malarky was supposed to be advaced tech?
There's always an element of the community that will regard *any* advanced tech as suspicious and worthy of criticism, no matter what good it brings. And not just in telecoms.
In this case, why blame the advanced tech of FTTC when the issue you have is with the planning & operational rules of a telcom company?
|
|
|
All 3 spikes look like resyncs, although the third is obviously of lower duration.
As another posted stated, a new PPP session (as requested by the router, or by a direct PC connection) will have no effect on the need for (or amount of) interleaving or FEC.
As Bald_Eagle stated, DLM tends to look at the average error counts over the last 24 hours, and the number of resyncs, and decides whether it needs to limit your connection speed, or add interleaving.
However, it most certainly isn't as fast at taking things away again when any problems disappear. You can expect to wait for between 1 and 4 weeks for that to happen - so patience is required.
And even then, there's no guarantee. My first line got interleaved after 48 hours, and it stuck forever.
Thanks - I did reset the router for a new PPP session (second spike) and it had no effect on interleaving or my IP profile and actual througput. Contemplating buying a HG modem and unlocking to check line stats but figure it is best just to leave the ECI on and wait for interleaving to be removed in time - if it ever does!
Pings have doubled but I've not seen any change in throughput since having this line, kind of annoying as latency is more important than out and out speed to me. It is a pity that DLM can act so quickly on potential problems but seems to take so long to resolve them.
Does anyone know if a regrade to a 40/10 service from the 80/20 forces a DLM reset, could be an option in some cases if you had a monthly sub.
Cheers
|
|
|
I think I'm one of the ones with a troublesome line, only getting about 42 Meg on a 450 meter line, with interleaving at 700. my connection has not resynced for just over 500 hours now, so will be interesting to see if it improves when it gets to 4 weeks.
I was the first on my cabinet, but my attainable rate has not reduced much at all, perhaps due to an underlying fault.
Is my connection worth it, yes absolutely!
|
|
|
Personally I do see DLM as a hack, I dont see it as a standard part of the VDSL tech, I may be wrong but I guess its some sort of external script thats run checking errors etc.
DLM been over agressive is one issue especially when forcing interleaving, I would rather have a higher snrm (rate cap) than higher base latency. All I can say based on my adsl days the relief I got from losing DLM was unreal, yes my line was horrific but its horrific lines where DLM is supposed to be most beneficial in my case it wasnt.
A end user can be their own version of DLM they can time a resync to when their line is at its worst which in affect reduces the sync rate and increases reliability. A modem might even resync itself during high periods of noise.
So personally I agree with tommy45 in that DLM is an abonimation. Maybe my opinion will change after I have FTTC up and running, time will tell.
As for the slow recovery back to fast path or higher sync rate after a downward DLM, thats at least a good thing otherwise there would be potential flip flopping every night between fast path and interleaving.
Edited by Chrysalis (Wed 28-Nov-12 14:50:37)
|
|
|
Who is the "they" that this is in favour of? BTgroup
ISP's The end user should be given a choice to use DLM or not,After all they are the bill payer /customer,if that still means anything these days
The advantage of cabinet-based FTTC here is that it automatically reduces the amount of line that needs to be trouble-shooted to find the problem. The means it ought to be easier to locate than with an exchange-based solution... provided you can get an engineer onto the problem in the first place.
Here lies the problem, If your Dside pair is being subjected to electrical induction at one or several points in between the NTE and the FFTC cab then FTTC will probably suffer more so than what adsl2+ does, With my line i know there is such induction occurring due to the hum on the ptsn side,
I had an SFI engineer tell me what was causing it,
which i would say is able to impact the connection at times,when i asked about that sorted out,he told me very doubtful as it would take too much time & effort (cost them too much money) and that there could be more than one location involved
But i would be very reluctant to go for FTTC as the min term is 12-18mths depending on isp, there are also install charges of £50-£100 So it would have the potential to be both costly and a year or more of DLM hell ,unable to play FPS games properly online without lag or be able to speak using voice coms without having the echo effect ,
I could not bear that, regardless of it being a lot faster & possibly cheaper than my Dsl connection
But as you said or implied it's openreach that's holding things back by the way that they like to run things, but because it's a product (DLM sold with it) it does kind of kill any advances made by it
why blame the advanced tech of FTTC when the issue you have is with the planning & operational rules of a telcom company?
|
|
|
But i would be very reluctant to go for FTTC as the min term is 12-18mths depending on isp, there are also install charges of £50-£100 So it would have the potential to be both costly and a year or more of DLM hell ,unable to play FPS games properly online without lag or be able to speak using voice coms without having the echo effect ,
I could not bear that, regardless of it being a lot faster & possibly cheaper than my Dsl connection
I've had some quite high levels of interleaving, but never had a problem playing Crysis 2, ping is always lower than ADSL, current ping on speedtests is about 20Ms with interleaving level of 700, ping on ADSL was around 50 IIRC.
|
|
|
Well, using adsl my ping to most servers in the uk ranges from13ms upwards, fastpath, if interleaved that can be 30-40ms , The people i typically connect up with are overseas europe and the usa, so any increase in latency would make the game unplayable, Online gaming is probably the main reason i even have an internet connection, On the latency side of things i know that your location within the uk can/does affect your base latency, then you have the Isp's routing and peering playing a part also
The thing with the is that according to the sfi engineer I'm probably only around 300m-350m from the cab , so would see near the full 80/20 if not the max
|
|
|
Does anyone know if a regrade to a 40/10 service from the 80/20 forces a DLM reset
It does. Even a regrade of the upstream alone (say 40/2 to 40/10) forces a reset of DLM.
|
|
|
I think I'm one of the ones with a troublesome line, only getting about 42 Meg on a 450 meter line, with interleaving at 700. my connection has not resynced for just over 500 hours now, so will be interesting to see if it improves when it gets to 4 weeks.
My first line was quite troublesome - 500 metres, and DLM dropped sync to 36Mbps because of errors, on an 8a profile.
I never managed to get stats from the modem on that profile, and when the cabinet was upgraded to the 17a profile, the sync recovered back to 40Mbps - presumably due to the re-organisation of up & downstream frequencies. The attainable speed was given as 60Mbps, but we left before full 80/20 services became available.
On the stats output, I can now see that it had interleaving & FEC stats of:
R: 16 16
D: 701 1
N: 74 240
INP: 3.00 0.00
delay: 8.00 0.00
So 22% overhead.
I was the first on my cabinet, but my attainable rate has not reduced much at all, perhaps due to an underlying fault.
We had a hold up with our order, so got delayed. In that time our neighbour had theirs installed, so I suspect I was suffering from crosstalk there from day 1.
Is my connection worth it, yes absolutely!
I agree. I was a bit disappointed to see 40Mbps on day 1, then lose 4Mbps on day 3. But the 36Mbps was still well worthwhile.
In the new house, the speed of 80Mbps over ADSL2+ speeds of 5Mbps were even better. I keep hoping that the neighbours don't cotton on to the fact that it is better performance than VM.
|
|
|
Personally I do see DLM as a hack, I dont see it as a standard part of the VDSL tech, I may be wrong but I guess its some sort of external script thats run checking errors etc.
DLM - or the more common name for the technology " Dynamic Spectrum Management" (DSM) - covers a fair number of bits of technology.
The need for DSM stems from the fact that every broadband user also causes interference with every other user - to a greater or lesser extent. The overall aim of all these bits of technology is to make everyone "play nice" - to make sure that no-one suffers too much from the interference caused by another user, and to share nicely.
The parts we see include
- The DLM component we know & discuss on here
- The use of upstream power backoff, to reduce the power of other users' modems.
- The use of PSD (Power Spectral Density) maps in the cabinet, to limit the interference with exchange-based ADSL
- Vectoring, to dynamically adapt to other users' interference
The DLM system we know today isn't *within* the VDSL2 specification - it sits at a level higher than VDSL2. However, the VDSL2 spec *does* define the configuration properties that it makes use of (such as the INP and delay parameters)... and DLM is the process that works out what values those configuration properties should take.
Today's DLM will indeed be performed outside the cabinet - whether scripts or proper programs are involved is irrelevent. The more complex forms of DSM will need to be done within the cabinet, eventually reaching the (natural) complexity that requires the steps be performed in hardware, not software.
These procedures *are*, however, standardised. Ofcom's NICC have a 2010 Report on DSM methods in the UK, which gives more details of the art 2 years ago.
There are also other reports linked on this page from a previous discussion.
Very much *not* a hack. Very much thought out - even if never appreciated.
DLM been over agressive is one issue especially when forcing interleaving, I would rather have a higher snrm (rate cap) than higher base latency. All I can say based on my adsl days the relief I got from losing DLM was unreal, yes my line was horrific but its horrific lines where DLM is supposed to be most beneficial in my case it wasnt.
I agree - DLM shouldn't be used as a substitute for fixing dire lines.
And interestingly, that NICC document recommends that DLM should be introduced on DSL systems that don't have it, and those that already employ the "Automated margin Adjustment" type (that gave you problems) should be upgraded to use a "Tiered Rate Adaption" style instead. The TRA style is the one currently employed in BT's FTTC.
Finally, it seems strange that Openreach's product *do* offer their customer a choice of DLM behaviours - between "standard", "stable", and "speed". It isn't obvious why the ISPs themselves can't make use of this - do BT Wholesale prevent access to this?
So personally I agree with tommy45 in that DLM is an abonimation. Maybe my opinion will change after I have FTTC up and running, time will tell.
I agree that there are some aspects of the implementation that, er, leave scope for improvement.
Here's hoping that the vectoring technology does what it says on the tin. That's the one that does away with the current "simple" level of DLM.
As for the slow recovery back to fast path or higher sync rate after a downward DLM, thats at least a good thing otherwise there would be potential flip flopping every night between fast path and interleaving.
My old line, with interleaving enabled, would not flip-flop back to fastpath.
I just check 2 sets of old stats:
- First showed 183 CRC over 3.5 days, but 3.1 million FECs
- Second showed 52 CRC over 3 days, but 2.1 million FECs
Those levels of CRC would probably trigger DLM to drop me back to fastpath, if DLM looked at those alone. It must be looking at the level of FEC to prevent me dropping back inadvertently.
|
|
|
BTgroup
ISP's The end user should be given a choice to use DLM or not,After all they are the bill payer /customer,if that still means anything these days
I thought that would be your answer.
The problem is that part of the reason for DLM is to "share nicely" with everyone else - after all, if you wanted to have no errors on *your* line, all you'd need to do is whack up the power. Everyone else might have to resort to pigeons, but you'd be OK, right?
However, as I answered Chrysalis, Openreach do have a way for you to set the grade of DLM you want - to Standard, Stable or Speed. It isn't clear why ISPs don't have this option (or don't let you know they do).
And, while I do think that DLM is necessary, I agree that the implementation hasn't always resulted in the best results for everyone. Particularly when BT's "IP profile" mechanisms get in the way.
Here lies the problem, If your Dside pair is being subjected to electrical induction at one or several points in between the NTE and the FFTC cab then FTTC will probably suffer more so than what adsl2+ does,
Why do you say that? I'm not sure that it's a given that FTTC will probably suffer more - it very much depends on the nature of the interference and its location
If the cabinet is notable closer to your house than the exchange, the signal level will be higher when it arrives (except for the portion that get deliberately crippled by the cabinet's PSD mask). That higher signal level might make all the difference.
With my line i know there is such induction occurring due to the hum on the ptsn side,
I had an SFI engineer tell me what was causing it,
which i would say is able to impact the connection at times,when i asked about that sorted out,he told me very doubtful as it would take too much time & effort (cost them too much money) and that there could be more than one location involved
Does the SFI engineer know where the suspected location is?
But i would be very reluctant to go for FTTC as the min term is 12-18mths depending on isp, there are also install charges of £50-£100 So it would have the potential to be both costly and a year or more of DLM hell ,unable to play FPS games properly online without lag or be able to speak using voice coms without having the echo effect ,
I could not bear that, regardless of it being a lot faster & possibly cheaper than my Dsl connection
Ah, I can agree it is very off-putting to see contracts like that. What is your current solution to get around all those problems?
And what kind of latency can you accept, and still have functioning games & voice? Or should i ask the other way around - what was happenign to your latency when it was all going wrong?
|
|
|
|
A good indicator of how good DLM is for customer experience is the skyuser forums.
Initially sky had no DLM, then they later introduced it.
When they did introduce I had a look at their forums and looked at complaints 'before' it was introduced and 'after', from my observations the complaints were significantly higher 'after' DLM. To say its required I dont agree, user's of BE dont have major issues without DLM, and ukonline user's were mostly the same as well.
DLM is just a cost saver for the isp's so they dont have staff spending time manually adjusting settings, I also suspect its like an isp babysitting its users serving the lowest common factor working on the basis "we know better than you" ie. not wanting user's sitting on 3db margins for maximum sync rate's and then complaining of instability. DLM takes care of that mostly I expect as it enforces conservative settings. But of course not always if there is a bad enough line problem.
So I do do understand why DLM is there, but its mainly for the isp's benefit as I see it, SRA is superior in my opinion but SRA does seem to be problematic to get working and potentially would create more support headaches for the isp. So this seems about minimising support calls as especially now people cannot check modem stats without hacking modems isp's probably work on the basis user's are just happy if the connection works over anything else.
|
|
|
I don't know if Sky have a DLM within their own system, like BT Wholesale, but you may be confused.
On FTTC Openreach have a DLM controlling the line between the DSLAM and the end user modem. Sky FTTC users are subject to that, period, because Sky use Openreach GEA.
On the case of BT Wholesale ISPs, the BT Wholesale DLM sits on top of the OR one, but is emasculated in that it doesn't control the connection parameters in any hugely significant manner. It sets the IP Profile for throughput control, and can presumably pass through the standard/stable/extra stable parameter. I assume it can also pass through any prioritisation parameter for the traffic within the individual customer's connection which is present in the OR DLM. (I.e. VOIP and gaming over streaming and similar).
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
|
they dont on FTTC no, but they do on their adsl.
I was commenting on the theory that DLM makes end user's happier.
|
|
|
On the case of BT Wholesale ISPs, the BT Wholesale DLM sits on top of the OR one, but is emasculated in that it doesn't control the connection parameters in any hugely significant manner. It sets the IP Profile for throughput control
Won't that affect the throughput?
|
|
|
On the case of BT Wholesale ISPs, the BT Wholesale DLM sits on top of the OR one, but is emasculated in that it doesn't control the connection parameters in any hugely significant manner. It sets the IP Profile for throughput control
Won't that affect the throughput?
Learn to understand pwoppar gwamatickle inglish.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
On the case of BT Wholesale ISPs, the BT Wholesale DLM sits on top of the OR one, but is emasculated in that it doesn't control the connection parameters in any hugely significant manner. It sets the IP Profile for throughput control
Won't that affect the throughput?
Learn to understand pwoppar gwamatickle inglish.
Can you answer the question?
|
|
|
Won't that affect the throughput? Yes.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
Can you answer the question? Not only can I answer it, I have now also chosen so to do.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
|
Black coffee works wonders.
|
|
|
Won't that affect the throughput? Yes.
Interesting. There have been a number of reports of lines being apparently capped, resolved by an engineer's visit and the engineer calling BTWholesale to have the cap removed.
The BTWholesale speedtester has been reporting 0 Megs for the max attainable speed for about a month, too.
|
|
|
I gather you have had some and now realise that your question was pointless.
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
|
No, I think you have now sobered up.
|
|
|
Does anyone know if a regrade to a 40/10 service from the 80/20 forces a DLM reset
It does. Even a regrade of the upstream alone (say 40/2 to 40/10) forces a reset of DLM.
That is good to know, after the first 12 month initial contract my provider (Adsl24) offers a monthly sub. If interleaving is not removed when my current contract is up I'd be willing to downgrade to 40/10 and see how it goes then regrade to 80/20.
Hoping that interleaving will be removed well before then anyway, if it hadn't started out at 10ms I'd be fuming about the doubling of ping.
Cheers
|
|
|
No, I think you have now sobered up. On the contrary, you seem to have lost your comprehension of English, as I suggested earlier. On the case of BT Wholesale ISPs, the BT Wholesale DLM sits on top of the OR one, but is emasculated in that it doesn't control the connection parameters in any hugely significant manner. It sets the IP Profile for throughput control
Won't that affect the throughput?
Surely if something controls something else, then that something else is affected?
(It should of course say "In the case of ...", not "On the case of", but that doesn't seem to alter the meaning of the bit that appears to be causing you difficulty).
My broadband basic info/help site - www.robertos.me.uk | Domains,website and mail hosting - Tsohost.
Connection - Plusnet Extra Fibre (FTTC). Sync ~ 53.5/15.2Mbps @ 600m. - BQM
"Where talent is a dwarf, self-esteem is a giant." - Jean-Antoine Petit-Senn.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Allergy information: This post was manufactured in an environment where nuts are present. It may include traces of understatement, litotes and humour.
|
|
|
|
I regard the controlling of the throughput as being hugely significant.
|
Pages in this thread: 
Print Thread
