Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: les-70 on January 14, 2014, 11:32:13 AM
-
So far on my FTTC connection running at 80/20 I have estimated that a 1db change in the reported "over all" snrm on HG612's corresponds to a drop of ~4Mb/s in the attainable speed. I wondered if people achieving syncs of either 80/20 or 40/2 or 40/10 could report their downstream snrm's and max attainable speeds. Assuming all are on a 6db target snr this should allow the relation between snrm and speed to be refined. Adding overall downstream attention may also be of interest but I am sure sure that it is a reliable quantity. That is just the three numbers max down/, snrm, and attn.
Thanks in advance for any inputs.
p.s. Please let me know if this has been done before!
-
I know you only asked for three numbers but I thought I send the lot anyway and you use what you need. This is from FTTC Inifinity 2
Regards BBN
-
I wondered if people achieving syncs of either 80/20 or 40/2 or 40/10 could report their downstream snrm's and max attainable speeds.
Thanks in advance for any inputs.
I am not achieving an attainable sync of 40000 kbps but not to far off it with 34000 kbps in the evening 6pm to 10pm at 5.8dB SNR Margin with a 30558Kbps Sync rate and a throughput of 28700 kbps then 36388 kbps from 5am to 4pm at 6.8dB SNR margin and a Sync rate of 30558 Kbps and again a throughput of 28700 Kbps ;D
-
Thanks for the replies. I did ideally need stats from connections syncing at 80/20 but have found some searching posts. From this and more extensive tests on my own line which being the first on cab is for the time being at 80/20, I have concluded that the relation does indeed seems to be ~4Mb/s per 1db when all tones have a bit loading dropping to ~2Mb/s per 1db when about half the tones are bit loaded down to ~0.5Mb/s per 1db when just the adsl2 tones have a bit loading.
The figures help with cross-talk calculations but would be of more interest if you could tweak the target snrm on FTTC connections.
-
The figures help with cross-talk calculations but would be of more interest if you could tweak the target snrm on FTTC connections.
Yes I think BaldEagle1 would like to tweak his SNR margin to 3dB but I don't think the DLM as it is on FTTC could handle those extra line errors, so for the time being the Target SNRM is 6dB on FTTC connectios.
-
The figures help with cross-talk calculations but would be of more interest if you could tweak the target snrm on FTTC connections.
Yes I think BaldEagle1 would like to tweak his SNR margin to 3dB but I don't think the DLM as it is on FTTC could handle those extra line errors, so for the time being the Target SNRM is 6dB on FTTC connectios.
Yeah, target SNRM appears to be locked, the only thing one can do is to cap their own sync speed by using something like 'xdslcmd configure --maxDataRate 50000 20000 70000', where 50000 is the downstream rate, 20000 is the upstream rate, and 70000 is the total of the two sync rates. That's obviously only useful for increasing SNRM. I'm doing this on my own connection at the moment to see if I can do what I did to DLM a year ago, that being to get it stuck in a banding state with no INP and delay no matter how many times one resyncs or how many ES occur.
-
@Ixel I am also trying to copy your past success in getting banded at a plausible speed for the same reasons. How did you come to loose that banded state?
Also once you were banded do you know if the line did still sync at 6db if the attainable became less than the band? Also I assume that further xdslcmd configure --maxDataRate commands could then still lower the sync further? i.e you were capped and not stuck?
-
The figures help with cross-talk calculations but would be of more interest if you could tweak the target snrm on FTTC connections.
Yes I think BaldEagle1 would like to tweak his SNR margin to 3dB but I don't think the DLM as it is on FTTC could handle those extra line errors, so for the time being the Target SNRM is 6dB on FTTC connectios.
Yeah, target SNRM appears to be locked, the only thing one can do is to cap their own sync speed by using something like 'xdslcmd configure --maxDataRate 50000 20000 70000', where 50000 is the downstream rate, 20000 is the upstream rate, and 70000 is the total of the two sync rates. That's obviously only useful for increasing SNRM. I'm doing this on my own connection at the moment to see if I can do what I did to DLM a year ago, that being to get it stuck in a banding state with no INP and delay no matter how many times one resyncs or how many ES occur.
I am wondering if its also useful for pushing/keeping DLM to a fastpath state as a higher snrm reduces errors.
-
@Ixel I am also trying to copy your past success in getting banded at a plausible speed for the same reasons. How did you come to loose that banded state?
Also once you were banded do you know if the line did still sync at 6db if the attainable became less than the band? Also I assume that further xdslcmd configure --maxDataRate commands could then still lower the sync further? i.e you were capped and not stuck?
In a past thread in December, it's believed that a firmware upgrade to the cabinet caused DLM to be reset for all lines associated with it. Before that, I was previously banded at 60/20 with no INP and no delay for what must've been over a year easily (no matter what I did to the connection, e.g. resyncing deliberately).
The line didn't sync at 6dB due to the banding in effect, SNRM was a lot higher (can't remember number off hand). I was definitely restricted to 60,000Kbps down and 20,000Kbps up, having previously went as low as somewhere in the 40,000 Kbps downstream on a FB 7390 (previously this wasn't possible on the HG612 until the recent update to it). The xdslcmd configure --maxDataRate can cap the line speed further yes.
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 29343 Kbps, Downstream rate = 100108 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 66993 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 11.8 12.3
Attn(dB): 16.6 0.0
Pwr(dBm): 12.8 6.6
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 47 236
M: 1 1
T: 64 5
R: 14 16
S: 0.0228 0.3771
L: 21760 5410
D: 1421 1
I: 62 255
N: 62 255
Counters
Bearer 0
OHF: 72896130 995280
OHFErr: 47 1
RS: 1481366956 2820450
RSCorr: 2376249 41
RSUnCorr: 1059 0
Bearer 0
HEC: 190 0
OCD: 7 0
LCD: 7 0
Total Cells: 862728487 0
Data Cells: 271825804 0
Drop Cells: 0
Bit Errors: 0 0
ES: 165 5
SES: 0 0
UAS: 141 141
AS: 106761
Bearer 0
INP: 3.50 0.00
INPRein: 0.00 0.00
delay: 8 0
PER: 1.46 6.15
OR: 131.10 202.87
AgR: 67123.60 20203.27
Bitswap: 71716/71716 6/6
Total time = 1 days 4 hours 38 min 50 sec
FEC: 15864637 268
CRC: 660 6
ES: 165 5
SES: 0 0
UAS: 141 141
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 8 min 50 sec
FEC: 10569 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 27753 0
CRC: 5 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 4 hours 38 min 50 sec
FEC: 399993 4
CRC: 8 1
ES: 2 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 1916220 36
CRC: 39 0
ES: 15 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 1 days 5 hours 39 min 19 sec
FEC: 2376249 41
CRC: 47 1
ES: 17 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
@Chrysalis: Yeah. This is one of the reasons I'm trying again, so I can return to Fastpath albeit at a slightly lower downstream speed. I would go for the 40 meg package if it isn't for the fact I'd also lose 10 meg upload speed. So, I'm trying to impose my own speed limit on the downstream without imposing further limits on the upstream. All being well DLM will return the line to fastpath and keep it that way :).
-
So, I'm trying to impose my own speed limit on the downstream without imposing further limits on the upstream. All being well DLM will return the line to fastpath and keep it that way :).
You are a lucky FTTC customer with so much spare SNRM to hand, but your theory will work on a like for like line, it won't work when the CP is getting an attainable of less than 40000Kbps as they have a much lower SNR margin (further from the FTTC Cab) ;)
and they need all the Max dowload rate they can get and TBH I have never experienced the Internet with fastpath it's always been Interleaved with 25-45ms and online gameing is great with those parameters ::)
-
To answer the question if I recall right on my line 3db of snrm is roughly 14mbit of sync speed. so about 5mbit per 1 db of snrm.
To ixel I agree, what a few people dont realise or perhaps more than a few that a higher latency does slow things down, try browsing a website in asia and it feels slow thats because of the latency. A line with a sync of 60000 on fast path will feel faster and actually be faster on many things than a line at 79999 interleaved. Also I agree if it wasnt for the upload cap of 10mbit I may well have downgraded to the 40mbit product to gain more snrm and have a nice margin. Unfortenatly openreach have decided they prefer applying interleaving to increasing snrm.
My line as an example, the overheads of FEC take 6mbit of the sync speed for its existing setting, if I am right 1db of snr is about 4.8mbit, then I could set a cap of 6mbit below the normal fastpath sync rate and have some more stability from a snrm of about 7.5db fast path instead of 6db interleaved. Also since I mentioned the new firmware is less stable on my line its interesting that on the old firmware on fastpath my sync speed was always 1-2mbit below the attainable and snrm nearly 7db. On the new firmware the attainable and sync close together but snrm around 6db. However my sync speed was no higher as the attainable was lower due to the tones turned off.
So this command on the hg612 only works on the latest firmware?
-
To answer the question if I recall right on my line 3db of snrm is roughly 14mbit of sync speed. so about 5mbit per 1 db of snrm.
To ixel I agree, what a few people dont realise or perhaps more than a few that a higher latency does slow things down, try browsing a website in asia and it feels slow thats because of the latency. A line with a sync of 60000 on fast path will feel faster and actually be faster on many things than a line at 79999 interleaved. Also I agree if it wasnt for the upload cap of 10mbit I may well have downgraded to the 40mbit product to gain more snrm and have a nice margin. Unfortenatly openreach have decided they prefer applying interleaving to increasing snrm.
My line as an example, the overheads of FEC take 6mbit of the sync speed for its existing setting, if I am right 1db of snr is about 4.8mbit, then I could set a cap of 6mbit below the normal fastpath sync rate and have some more stability from a snrm of about 7.5db fast path instead of 6db interleaved. Also since I mentioned the new firmware is less stable on my line its interesting that on the old firmware on fastpath my sync speed was always 1-2mbit below the attainable and snrm nearly 7db. On the new firmware the attainable and sync close together but snrm around 6db. However my sync speed was no higher as the attainable was lower due to the tones turned off.
So this command on the hg612 only works on the latest firmware?
Yeah. And yes, the latest firmware only has this ability. I've just been switched to Fastpath this morning, remaining at the configured speed cap I set on the HG612 of course. I wish there was a way to save the setting between any power failures, but I suppose I could just design a mini-program to monitor the sync speed of the HG612 and ensure it remains at the one I wish.
Latest stats (although my Error Seconds have increased now, I wonder how many could trigger interleave, > 900 ES in a 24 hour period perhaps (15 mins), I have no idea?
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 29434 Kbps, Downstream rate = 96436 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 66969 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 14.3 12.4
Attn(dB): 16.6 0.0
Pwr(dBm): 12.7 6.6
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 239 236
M: 1 1
T: 23 5
R: 0 16
S: 0.1141 0.3771
L: 16832 5410
D: 1 1
I: 240 255
N: 240 255
Counters
Bearer 0
OHF: 10827861 752967
OHFErr: 150 1
RS: 0 3536308
RSCorr: 0 11
RSUnCorr: 0 0
Bearer 0
HEC: 857 0
OCD: 25 0
LCD: 25 0
Total Cells: 2753095512 0
Data Cells: 6341395 0
Drop Cells: 0
Bit Errors: 0 0
ES: 272 7
SES: 10 0
UAS: 177 167
AS: 21390
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.97 6.15
OR: 97.19 202.87
AgR: 67066.02 20203.27
Bitswap: 15063/15063 0/0
Total time = 1 days 23 hours 2 min 50 sec
FEC: 0 11
CRC: 150 1
ES: 272 7
SES: 10 0
UAS: 177 167
LOS: 1 0
LOF: 8 0
LOM: 0 0
Latest 15 minutes time = 2 min 50 sec
FEC: 0 0
CRC: 5 0
ES: 2 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 22 0
ES: 5 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 23 hours 2 min 50 sec
FEC: 0 11
CRC: 150 1
ES: 109 3
SES: 10 0
UAS: 36 26
LOS: 1 0
LOF: 8 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 0 0
CRC: 0 0
ES: 15 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 5 hours 56 min 29 sec
FEC: 0 11
CRC: 150 1
ES: 86 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
-
how long did you have to wait for fast path in days?
I been waiting a week and a half now.
Since I have raised a fault with plusnet tho I cant fiddle with the device, but if I end up still stuck on interleaving after an engineer has been I will try it then, but this is annoying as I was planning on downgrading the firmware again since the 2nd asbokid blob is more stable than the new BT one.
-
If you wish to automate the tweak you could try disabling vdsl in the modem settings and adding "xdslcmd configure --mod v --maxDataRate 64000 16000 80000" to the configuration tab custom commands in dslstats and enable it for "dsl down" -- edit - you may need to ensure the sample frequency is long enough for a resync to occur though or you will have an endless loop!!!!!. It is definitely OK at 1min and I have not tried less.
This way should the modem be power cycled or rebooted and thus loose the tweak -- it won't loose it otherwise -- it won't connect at all as vdsl is not not enabled except when enabled with the command. I am set up this way at the moment but have have not really tested it except at full power up. I also have a command file that tests things then does the same only if needed. It is based on Snadge and Baldeagle1's tweak files. If I have trouble with the dsl stats approach I will go back to that.
-
Yeah I will try something along those lines if it comes to me having to force my line back to fastpath, plusnet are progressing my fault as a low speed fault as I am currently almost 20mbit below my estimate, they told me that alone justifies an engineer and not to worry about the errors I reported last week. They said they will instruct the engineer to do a DLM reset as well. The problem is there is an error in BTw's systems preventing them booking an engineer something to do with my address code isnt set right so having to wait for that to be fixed.
-
how long did you have to wait for fast path in days?
I been waiting a week and a half now.
Since I have raised a fault with plusnet tho I cant fiddle with the device, but if I end up still stuck on interleaving after an engineer has been I will try it then, but this is annoying as I was planning on downgrading the firmware again since the 2nd asbokid blob is more stable than the new BT one.
About 10 days for me to switch back to fastpath. I applied the first sync cap on the 7th, about 77000Kbps downstream. Then about two days later I decided to reduce it to 67000Kbps, have kept it there ever since.
@les-70: Clever idea.
-
ok thanks, so only a day or so after the 2nd sync cap then.
-
how do you change it? i put the command in and it says too many parameters?
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fimg600.imageshack.us%2Fimg600%2F4419%2Fvdm2.jpg&hash=d6e5ed28aaa0cd40ae78f06dc64933b4a3c45dde)
-
how do you change it? i put the command in and it says too many parameters?
At first guess it sounds to me like you don't have the very latest HG612 firmware.
I'm using B030SP06, unlockedgui-nobtagent, from Howlingwolf's post (http://forum.kitz.co.uk/index.php?topic=13130.msg247661#msg247661), on the download link it's located in the 'Experimental' directory. The latest firmware version only supports --maxDataRate.
-
To ixel I agree, what a few people dont realise or perhaps more than a few that a higher latency does slow things down, try browsing a website in asia and it feels slow thats because of the latency.
I don't go outside the google homepage of .co.uk and what sites in asia are you looking at ;)
sorry I don't get this Fastpath fasination that seems to hook the younger internet users they seem more concerned about lower pings than the overall modems well being on there connection, call me a fuddy duddy if you like :D but on interleaved I can do the same stuff as a fastpath user so what is this all about ?
-
To ixel I agree, what a few people dont realise or perhaps more than a few that a higher latency does slow things down, try browsing a website in asia and it feels slow thats because of the latency.
I don't go outside the google homepage of .co.uk and what sites in asia are you looking at ;)
sorry I don't get this Fastpath fasination that seems to hook the younger internet users they seem more concerned about lower pings than the overall modems well being on there connection, call me a fuddy duddy if you like :D but on interleaved I can do the same stuff as a fastpath user so what is this all about ?
In my case, when playing a first person shooter online I notice a 10ms to 15ms increase, generally my shots miss the targets more often and my kill to death ratio is worse than without the increased latency.
-
In my case, when playing a first person shooter online I notice a 10ms to 15ms increase, generally my shots miss the targets more often and my kill to death ratio is worse than without the increased latency.
Cheers Ixel for updating and old Gamer like me 1982 to 2014 but then some gamers put the Kill Ration has decreased because the DPI on the mouse is not accurate enough :P
-
In my case, when playing a first person shooter online I notice a 10ms to 15ms increase, generally my shots miss the targets more often and my kill to death ratio is worse than without the increased latency.
Cheers Ixel for updating and old Gamer like me 1982 to 2014 but then some gamers put the Kill Ration has decreased because the DPI on the mouse is not accurate enough :P
Ha. While true, that's not my case, because now I'm back on fastpath my gaming experience has improved again. I'm sure some other people have that issue though, where DPI is the culpret.
-
To ixel I agree, what a few people dont realise or perhaps more than a few that a higher latency does slow things down, try browsing a website in asia and it feels slow thats because of the latency.
I don't go outside the google homepage of .co.uk and what sites in asia are you looking at ;)
sorry I don't get this Fastpath fasination that seems to hook the younger internet users they seem more concerned about lower pings than the overall modems well being on there connection, call me a fuddy duddy if you like :D but on interleaved I can do the same stuff as a fastpath user so what is this all about ?
I think you are confused, fastpath doesnt only affect asia sites, it affects 'everything'. I used asia sites as an example of seeing the affect of latency on performance. Actually asia sites fastpath wont have much of an impact as the latency is already high so an extra 10-30ms on a already 300ms latency isnt a huge deal, but an extra 10-30ms latency on a 20ms base latency is a big deal.
You need to understand how tcp slowstart etc. works to realise latency affects performance on everything.
eg. before I got switched I was maxing out my upload to a german server of mine, but when I got switched to interleaved I only maxed out at about 14mbit/sec as the extra latency was enough for the send buffers to get maxed out on the latency.
Also some example's of asia based sites.
square-enix.com
asus.com
You dont have to be an asian to be accessing asian based sites, japanese based companies will host in their own country often. ;)
Latency is also the reason why 3g feels slow compared to fixed line based broadband. A 2mbit adsl connection will be way faster than a 6mbit 3g connection. The reason is although the speed capacity is higher, because of the latency the speed takes much longer to ramp up. In addition when doing things like loading a web page small packets have to be bounced back and forth initially to start the process, with high latency these small packets take longer.
Interleaving (with sufficient recieve buffers) wont affect bulk downloading, as the speed eventually ramps up and will be fast, but otherwise almost everything else is affected.
so here I am 6am 11 days after been put on interleaved with very low error rates still no fast path. DLM way too conservative in recovery.
-
I think you are confused, fastpath doesnt only affect asia sites, it affects 'everything'. I used asia sites as an example of seeing the affect of latency on performance. Actually asia sites fastpath wont have much of an impact as the latency is already high so an extra 10-30ms on a already 300ms latency isnt a huge deal, but an extra 10-30ms latency on a 20ms base latency is a big deal.
You need to understand how tcp slowstart etc. works to realise latency affects performance on everything.
eg. before I got switched I was maxing out my upload to a german server of mine, but when I got switched to interleaved I only maxed out at about 14mbit/sec as the extra latency was enough for the send buffers to get maxed out on the latency.
Also some example's of asia based sites.
square-enix.com
asus.com
You dont have to be an asian to be accessing asian based sites, japanese based companies will host in their own country often. ;)
Latency is also the reason why 3g feels slow compared to fixed line based broadband. A 2mbit adsl connection will be way faster than a 6mbit 3g connection. The reason is although the speed capacity is higher, because of the latency the speed takes much longer to ramp up. In addition when doing things like loading a web page small packets have to be bounced back and forth initially to start the process, with high latency these small packets take longer.
Interleaving (with sufficient recieve buffers) wont affect bulk downloading, as the speed eventually ramps up and will be fast, but otherwise almost everything else is affected.
so here I am 6am 11 days after been put on interleaved with very low error rates still no fast path. DLM way too conservative in recovery.
What's your average daily ES count over the last week or so?
@les-70: I've implemented your suggestion with a slight twist of my own. As my ASUS RT-N66U router is set to reboot at 7:30am every day (I feel running on a freshly started router just helps the day's internet usage), I've also configured one of the digital timer plug things I've got to switch off the modem (HG612) at 7:25am and switch it back on at 7:35am. This so far seems to be working quite well.
-
i was on fast path, for over a week, when i first got infinity, my connection was fine despite the poor line and low speeds.
Everything was snappy, you can tell the difference.
It only lasted a week though, then it went interleaved, its way to aggressive dlm, id love an option to turn it off.
-
I think you are confused, fastpath doesnt only affect asia sites, it affects 'everything'. I used asia sites as an example of seeing the affect of latency on performance. Actually asia sites fastpath wont have much of an impact as the latency is already high so an extra 10-30ms on a already 300ms latency isnt a huge deal, but an extra 10-30ms latency on a 20ms base latency is a big deal.
You need to understand how tcp slowstart etc. works to realise latency affects performance on everything.
eg. before I got switched I was maxing out my upload to a german server of mine, but when I got switched to interleaved I only maxed out at about 14mbit/sec as the extra latency was enough for the send buffers to get maxed out on the latency.
Also some example's of asia based sites.
square-enix.com
asus.com
You dont have to be an asian to be accessing asian based sites, japanese based companies will host in their own country often. ;)
Latency is also the reason why 3g feels slow compared to fixed line based broadband. A 2mbit adsl connection will be way faster than a 6mbit 3g connection. The reason is although the speed capacity is higher, because of the latency the speed takes much longer to ramp up. In addition when doing things like loading a web page small packets have to be bounced back and forth initially to start the process, with high latency these small packets take longer.
Interleaving (with sufficient recieve buffers) wont affect bulk downloading, as the speed eventually ramps up and will be fast, but otherwise almost everything else is affected.
so here I am 6am 11 days after been put on interleaved with very low error rates still no fast path. DLM way too conservative in recovery.
What's your average daily ES count over the last week or so?
@les-70: I've implemented your suggestion with a slight twist of my own. As my ASUS RT-N66U router is set to reboot at 7:30am every day (I feel running on a freshly started router just helps the day's internet usage), I've also configured one of the digital timer plug things I've got to switch off the modem (HG612) at 7:25am and switch it back on at 7:35am. This so far seems to be working quite well.
I have had 2 ES over past 10 days. Not 2 ES per day 2 total.
-
I have had 2 ES over past 10 days. Not 2 ES per day 2 total.
That's very odd. I'd have expected DLM to switch you by now then :s.
-
I have had 2 ES over past 10 days. Not 2 ES per day 2 total.
That's very odd. I'd have expected DLM to switch you by now then :s.
A DLM with good logic yes.
-
I have had 2 ES over past 10 days. Not 2 ES per day 2 total.
That's very odd. I'd have expected DLM to switch you by now then :s.
A DLM with good logic yes.
you have ten days to go and your impatience will be your downfall, and trying to fool the DLM is near to impossible and Yes Ixel thinks he's got it cracked but would say it's just pure conincidence, his line is basically faultless he would have been moved to fastpath even without the so called tweaks so I wish Ixel would do some more re-search into his findings with some Graphs to back it up with, as your are leading some members into a false path on FTTC.
-
Twice in a row I wouldn't call a coincidence myself, but my line isn't faultless. I don't know where you assume that, as now I'm back on fastpath I'm currently getting quite a lot of ES per hour, quite a lot this evening infact. I've never known my line to be this bad on fastpath before, only things have changed are the new firmware update, the MK2 faceplate I recently bought, and a new ADSLnation Pro+ 0.5m cable. It will be interesting to see if DLM puts me back on interleaved again, despite me reducing the sync speed in order to increase SNRM.
From what I see you have what I call a perfect FTTC line, I get about 20-30 Errored Seconds per hour with a Max Attainable of 34000 kbps you have capped your own download rate and most users complain because the DLM has capped there download rate, I don't mind people flaunting there higher specs's but what I don't like is you seem oblivious that most FTTC customers don't have excellent lines like yours and you will need to take that into consideration to when giving out the tweaks details
Apart from that I'm just jealous ;D
-
From what I see you have what I call a perfect FTTC line, I get about 20-30 Errored Seconds per hour with a Max Attainable of 34000 kbps you have capped your own download rate and most users complain because the DLM has capped there download rate, I don't mind people flaunting there higher specs's but what I don't like is you seem oblivious that most FTTC customers don't have excellent lines like yours and you will need to take that into consideration to when giving out the tweaks details
Apart from that I'm just jealous ;D
On the contrary, I know two people locally who have terrible speeds due to their distance from the cabinet, I sympathise and have tried to help them get the best speed possible out of their connection. I don't intend or mean to show off my 'good quality' line, even though I don't feel it's good quality in regards to errors, it does however produce a speed that a good percentage wouldn't get and for that I'm very greatful.
Anyway I feel as if my presence on this forum appears to be more of an annoyance or appears to be encouraging something that's not nice, so in the best of interests I'll avoid posting.
-
I have had 2 ES over past 10 days. Not 2 ES per day 2 total.
That's very odd. I'd have expected DLM to switch you by now then :s.
A DLM with good logic yes.
you have ten days to go and your impatience will be your downfall, and trying to fool the DLM is near to impossible and Yes Ixel thinks he's got it cracked but would say it's just pure conincidence, his line is basically faultless he would have been moved to fastpath even without the so called tweaks so I wish Ixel would do some more re-search into his findings with some Graphs to back it up with, as your are leading some members into a false path on FTTC.
DLM isnt a static 14 days. In the past I have recovered after 2-3 days.
and I am waiting however I can form an opinion a 14+ day wait is ridiculous for a one off issue. :)
Also to note I havent tweaked my modem as I said I am waiting, I believe what he did will help people stay on fast path assuming the DLM doesnt penalise for a high snr margin (why would it?). The DLM isnt some super intelligent being, its a software program fed with parameters, software can be manipulated and is done so frequently. All the tidibits made public about DLM indicate it works on # of retrains and # of errors on the line. Increasing the noise margin on a line via capping its sync speed will decrease both retrains and errors. So its logical both him and les are correct.
It be interesting to see which comes first, the engineer plusnet are trying to arrange (BTw system broken) or my DLM recovering. Also my line is still banded to 74mbit for a year now, from a fault I had a year ago, it never reverted to 80 banding.
-
Chrysalis I waited over a 89 day sync and then 37 days. I had enough and phoned BT and got an engineer, luckily I know the engineers in the area. Requested a DLM reset and he did it for me...
-
wow you patient :)
Something weird is happening as I think I was banded to 54 a few days ago and now 40 since this morning. the error rates are now extremely low, no retrains (except DLM early morning).
-
You are all making a newcomer to any DLM (I was always on llu on adsl2+) quite concerned. So far the only resyncs on my line have been ones caused by me but as more people get FTTC on my cab I expect the DLM to get more interested in my line as time goes by. I am restricted my speed to keep it that way as I also dislike interleaving.
I had a fault on my adsl2 line card and it stopped syncing at all at its normal ~17Mb/s on fast path and it was then enabled to work at 8mb/s but inteleaved until the line card was changed. 8mb/s initially felt unresponsive on web pages but I asked for it to moved to fast path. With that change I could hardly notice the difference between 17 and 8. Nothing like the change from fast to interleaved at a level 64.
Is there any description of what the FTTC DLM looks for and does? I have only found guesses and bits on ADSL DLM in limited trawls through the forum posts.
-
It's entirely different, BTW DLM worked off noise and target margins. The OR DLM seems to work off Banding and Interleaving/Fastpath.
-
I am also of the view the BTw dlm was better, although many disagree with me. But the BTw DLM seemed to (a) tolerate more before taking action, (b) could be overriden/reset by the isp without an engineer and (c) usually it buffed up snrm before trying to interleave. Whilst the Openreach DLM has a auto recover mechanism its very slow, where people can end up paying for a gimped service for several weeks because DLM is programmed to be extremely cautious. The only thing better about openreach DLM is it doesnt also interleave upstream like BTw used to. So the interleaving is less severe. Of course LLU without DLM was brilliant but BT just dont get it in that regard.
Les as to the differences these are my observations based on my line and information around the web.
BTw DLM more sensitive to disconnections, Openreach less sensitive.
BTw DLM less sensitive to error bursts, Openreach 'much' more sensitive to line errors.
BTw DLM will usually increase snrm to stabilise a line before applying interleaving, Openreach DLM will typically apply interleaving before trying banding.
BTw's snrm changes can be overriden by a modem, Openreach's banding cannot be overriden by a modem.
BTw DLM can be reset by an isp, the fast/path interleave status can be set to auto, fast path, or interleaved by an isp. Openreach DLM the isp has no control over the DLM other than configuring the stability profile, an engineer is required to order a DLM reset.
There is very little known about isp's changing stability profile's, it seems it can be done on a whim, they place an order and it gets actioned by openreach, what isnt known is if a profile change resets DLM or not, if it does then the isp's do have a way to reset DLM but none so far have tried to take this route, eg. changing a line to stable profile for 24 hours to reset DLM, then switching it back to speed.
-
Thanks for the advice on experiences with the OR DLM. I would not complain about about line errors being the main criteria, that may well be best.
That said my impression here is that many line errors are quite intermittent and probably correspond to rarer very nasty rf spikes that take a lot of snr and thus speed drop to control. I have not had much experience of interleaving and can't comment on how effective it is. It would interesting know what crc/hour people on fast path actually get, there may be an upper bound to values found on fast path lines that gives some idea of what provokes the OR DLM. It may however be bursts that cause real traffic issues that trigger the DLM. That would also be quite sensible even if frustrating when the bursts are very rare but enough to trigger action.
It also is pity we don't know more about the fast/standard/stable OR DLM option that I seen discussed on TBB forum. They might just vary in the aggressiveness of intervention or they might differ in favoring fast path or interleaving c.f banding. Without knowing what they do it is not worth trying to request one or the other.
-
plusnet staff have stated the differences on the profiles are the trigger points, the example they quoted was 10 disconnections a day on speed vs 2 on super stable, this was an example quoted tho I dont think is actual figures.
Some noise bursts might take a lot of snrm to control I dont disagree, my issue is that DLM can over react big time for very short term problems. There is a difference between ongoing permanent noise and one off interference. The latter can still cause a line to be slowed down for several weeks. Plus DLM waiting till 3-6am the next day means it will often react too late to temporary problems.
My ideal solution is no DLM or at least optional DLM.
But a better DLM would maybe work like this.
It monitors errors at 15 minute intervals.
If excessive CRC errors (particurly SES) it makes changes to the line immediatly, applying a higher snrm, or banding Xmbit below current sync speed.
If still a problem, it tries even more snrm.
If still a problem it then applies interleaving.
It priorities interleaving the 2nd time if the extra snrm decreases sync speed below 15mbit/sec.
when DLM intervenes it sends a automated alert to the local openreach office in the area to report a line fault, openreach are then duty bound to bring the line back to fast path unbanded conditions, if they fail the end user has a choice of free opt out of contract or ongoing fixed fee £10 month discount until the fault is fixed, in other words interleaving is treated as a temporary fix to a problem not a permanent fix.
If the line calms down, and its the first instance in a month it will wait a maximum of 36 hours and then recover the line to full performance (or at least up one performance level if multiple actions have been taken). This is a guarantueed recovery time so isp rep's can assure end users it will happen, not the draw out of the hat as is now.
If the problem comes back, same as before, react within 15 minutes, but the recovery time increased to 5 days, again a guarantueed time so end users not told to "just wait" for an indefinite time.
If the problem comes back a 3rd time within a month after a 5 day recovery then use the current slow tiptoe approach as it at that point can be considered a ongoing problem.
After a line has been problem free for 1-2 months reset the counter so if a new problem occurs its considered a "first time" again and treated as such.
Even the above would be frustrating tho eg. if you have a short burst of errors that lasted 5 minutes once every 3 weeks, that could lead to a permanent interleaved line.
-
So far on my FTTC connection running at 80/20 I have estimated that a 1db change in the reported "over all" snrm on HG612's corresponds to a drop of ~4Mb/s in the attainable speed. I wondered if people achieving syncs of either 80/20 or 40/2 or 40/10 could report their downstream snrm's and max attainable speeds. Assuming all are on a 6db target snr this should allow the relation between snrm and speed to be refined. Adding overall downstream attention may also be of interest but I am sure sure that it is a reliable quantity. That is just the three numbers max down/, snrm, and attn.
Thanks in advance for any inputs.
p.s. Please let me know if this has been done before!
Sorry Im late coming in with this, but PC has been sick over the past month due to an issue with the graphics drivers, so not been able to get them sooner.
Anyhow I think this is a good suggestion and Ive put together some stats for this topic.
It should also be bourne in mind that I had a line fault in my early few months. These arent my best/worst. I just took the stats from the first plink of that day.
Date Max Up Max Down SNR up SNR down
19/07/2013 35730 101448 15.8 11.8
19/08/2013 34811 105652 15.4 12.8
19/09/2013 31944 96096 14.5 10.3
19/10/2013 32271 95400 14.8 10.1
19/11/2013 30385 88552 12.8 8.3
19/12/2013 30794 88540 13.1 8.3
19/01/2014 30833 86436 13.1 7.7
Signal Atten July 2013 and now
U0 u1 u2 u3 d1 d2 d3
0.8 17.7 28.8 N/A 11.1 24.4 38.4
0.1 17.7 26.4 N/A 10.4 23.1 35.7
-
no callback from plusnet when they promised yesterday I am started to become tempted to try this to fasttrack it. Then I realised the line is already throttled to a very low sync now anyway. My attainable is still the same.
-
@Kitz Thanks for those stats they are very much in line with those found already and at the 4Mb/s per db corresponding to all or almost all tones in use. See reply 3 for my conclusions on the relationship.
I don't expect my line to stay at 80/20, I was first here on FTTC and at the moment I think there are only about 4 connections on FTTC on the cab and with just that my attainable has dropped from 108 to 85. It looks like you have had similar drops. All things being equal and guessing FTTC take up in my immediate vicinity I have calculated that I will end up with an attainable of about 70Mb/s or a bit less. More or less at or below the BTW lowest estimate for an impacted line. To stay on fast path I am interested in keeping the DLM out of that capping process.
-
yeah kitz you getting close down to 7.7db snrm now.
Incidently plusnets line checker does not detect crosstalk on my line but as I said before without vectoring technology deployed I am not sure how they could reliably detect it. I gone down to 69 attainable on fast path from 110, so the BTw checker states I dont have a fault detected and I dont have crosstalk, so unexplained loss of 40mbit of sync signal.
for me plusnet still cant book an engineer :(
-
It's surprising the impact x-talk can have. Certainly more than I was expecting, and I'm not even sure if some of the figures have been higher than bt anticipated.
I wasn't 1st on my cab and there were quite a few already active (I'm port 25 iirc) yet as you can see I've lost appx 20mb in 6 months (my first quoted figure above perhaps wasn't the best as i was in the midst of a line fault at that time), so I should imagine those first on my cab will possibly have lost a lot more. None of the lines served via my cab will be long lines.
-
your loop loss is higher then mine, but dont panic yet, :) I think I do have higher than average crosstalk, I think I have seen only one other person on the net report a speed drop as big as mine (before any DLM capping), most seem so to lose 10-20mbit not 40mbit+.
-
@ chrys. I'd be happier with a dlm that at least the ISP could override. Atm it seems far too harsh and easy to cut in. Some lines may need it, but it doesn't seem to take into account the occasional blip which many may be willing to ride out. It takes far too long to repair, and how ridiculous that only engineers can reset.
Now I'm down to 7.7 I'm starting to see a fair few errors. The amount of errors I see would certainly seem to exceed the figures for a reduction to take place according to that doc we were discussing some months ago.
The weird thing is the snr itself is practically a flat line, no dips or anything, but my fear will be that it will be the error rate that cause the dlm to kick in at some point. I never got errors at 3db on adsl2+ and normally I would say that it must be something to do with the higher frequencies in use... But when I look at dslstats it would appear that the most bit swap occurs in the lower tones such as those in u0 and d1.
-
We x-posted. 40mb is ridiculous and why I said earlier that I think even bt may not have anticipated the amount of loss that some are now seeing.
-
I know I said to a member here a few days ago that I would avoid posting again because they didn't like me showing my stats or something, but I don't see why I should :P.
I wanted to update on latest stats in order to contribute to this thread (regarding sync speed and snrm relationship, and of course how DLM is doing nothing on my line at the moment so far it seems, despite the number of ES and SES being rather high in my opinion).
My current setup:
- Power plug cuts HG612 power at 7:25am and restores power at 7:35am
- HG612 is configured to not automatically sync a VDSL2 signal
- DSLstats (great program!) is configured to retry connecting to HG612 when it loses connection, samples every 60 seconds (thanks to les for the sampling and the xdslcmd command idea) and is configured to send the following command when no VDSL: 'xdslcmd configure --mod v --maxDataRate 77500 20000 97500 --Ginp 0x0 --CoMinMgn on --dynamicD off --dynamicF off --phyReXmt 0x3 --sesdrop off' (yeah yeah, been fiddling around with other parameters lol, I just like to experiment :P)
- ASUS RT-N66U reboots itself (Tomato USB Shibby firmware) at 7:30am, starts a fresh PPPoE session when HG612 is synced by around 7:37am~
Parameters definition:
- 'mod v' = Enable VDSL2 connection type so HG612 can now sync again
- 'maxDataRate <downstreamKbps> <upstreamKbps> <totalKbps>' = sync cap, be careful when using this though, last time I did this over a year ago I got DLM to cap me on a profile of up to 60 meg downstream because I used a sync cap as low as 45 meg (if memory serves me well), this time I'm still on 80 meg cap because I didn't go any less than 60 meg, see footnote 1 for more details on my theory (yes, theory, please correct me if I'm wrong)
- 'Ginp <bitmask>' = I don't think this works anyway, but I've set it, basically it should specify whether DS and/or US can support INP, 0x0 means off for both DS and US
- 'CoMinMgn, dynamicD, dynamicF' = I'm not entirely sure on what effect they have, if any, anyone here know? 'dynamicD' is default to on, 'CoMinMgn' and 'dynamicF' are default to off I believe
- 'phyReXmt <bitmask>' = Physical retransmission, retransmit when an error occurs I believe, to my understanding this isn't implemented by BT OR yet but could be planned, 0x3 enables it for both DS and US
- 'sesdrop' = If enabled it's supposed to reduce or eliminate transmission controls and error corrections on data packets, trying to reduce latency in particular on "Interleaved" path DSL line, I don't believe it works anyway, default should be 'off' anyway (had it 'on' a couple of days ago)
I don't have the previous 24 hour statistics as HG612 reboots every morning at 7:25am, but, I'll provide current statistics at time of posting this reply and will edit this reply much later this evening to update them again.
As of 21/01/2014 14:57:
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 29578 Kbps, Downstream rate = 94644 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 77472 Kbps
Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode(0x0)
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 10.9 12.3
Attn(dB): 16.6 0.0
Pwr(dBm): 12.7 6.4
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 239 236
M: 1 1
T: 23 5
R: 0 16
S: 0.0986 0.3771
L: 19472 5410
D: 1 1
I: 240 255
N: 240 255
Counters
Bearer 0
OHF: 15372920 1546764
OHFErr: 114795 0
RS: 0 3568041
RSCorr: 0 7
RSUnCorr: 0 0
Bearer 0
HEC: 16489 0
OCD: 3793 0
LCD: 3793 0
Total Cells: 3909019903 0
Data Cells: 28141901 0
Drop Cells: 0
Bit Errors: 0 0
ES: 649 0
SES: 288 0
UAS: 168 168
AS: 26251
Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.70 6.15
OR: 112.44 202.87
AgR: 77584.93 20203.27
Bitswap: 20704/20705 0/0
Total time = 7 hours 20 min 19 sec
FEC: 0 7
CRC: 114795 0
ES: 649 0
SES: 288 0
UAS: 168 168
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 5 min 19 sec
FEC: 0 0
CRC: 1788 0
ES: 6 0
SES: 5 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 3408 0
ES: 19 0
SES: 8 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 7 hours 20 min 19 sec
FEC: 0 7
CRC: 114795 0
ES: 649 0
SES: 288 0
UAS: 168 168
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 7 hours 17 min 31 sec
FEC: 0 7
CRC: 114795 0
ES: 649 0
SES: 288 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
I set downstream cap to 77500Kbps since over two days ago, so with the amount of errors accumulating I would've thought DLM would've intervened by now, but then again perhaps there's another reason why it's not, hmm.
Errored Seconds Chart: http://i.imgur.com/2TBWfa8.png (http://i.imgur.com/2TBWfa8.png)
Any thoughts? Is my line seriously good quality despite the large amount of errors?
The above is all an experiment to see if I could once again get DLM to stop putting me on interleaved (for the lowest ping possible on fastpath), if you try to repeat any of my steps please be aware that I may just have been lucky twice in a row and that you do so at your own risk. Try not to cap your connection too much as it could cause your connection to get stuck in a banded state (like I was at 60/20 a year or so ago). It took roughly 10 days before interleaved (INP 3, delay 8ms) was removed from my line.
Footnote #1: Somewhere a long while ago I came across a post (I'm almost sure it was on BT's forum) where someone posted a list of DLM profiles (e.g. sfad... blah blah), but for the life of me I can't find it again. Anyway, I believe something like the following might be done on the downstream, additional input is welcome:
Max DS | Min DS (Mbps)
80 | 40
60 | 30
40 | 20
20 | 10
15 | 7.5
Update: Found it, the list of banded profiles was posted by Black Sheep at http://forum.kitz.co.uk/index.php?topic=12896.msg244008#msg244008 (http://forum.kitz.co.uk/index.php?topic=12896.msg244008#msg244008).
Sorry for the long post, hopefully someone here will find it useful though :).
-
@ chrys. I'd be happier with a dlm that at least the ISP could override. Atm it seems far too harsh and easy to cut in. Some lines may need it, but it doesn't seem to take into account the occasional blip which many may be willing to ride out. It takes far too long to repair, and how ridiculous that only engineers can reset.
Now I'm down to 7.7 I'm starting to see a fair few errors. The amount of errors I see would certainly seem to exceed the figures for a reduction to take place according to that doc we were discussing some months ago.
The weird thing is the snr itself is practically a flat line, no dips or anything, but my fear will be that it will be the error rate that cause the dlm to kick in at some point. I never got errors at 3db on adsl2+ and normally I would say that it must be something to do with the higher frequencies in use... But when I look at dslstats it would appear that the most bit swap occurs in the lower tones such as those in u0 and d1.
thanks kitz I am glad you agree, indeed I am one of those who would rather tolerate riding out a short burst of errors than having my line gimped for multiple weeks by a DLM reaction. Currently syncing at 39994kbit/sec with 71824 attainable, bonkers. 12.8db snrm, and 1283 interleaving depth. no signs of actual problems on the line since 8th jan.
Also whenever my line has had error bursts, the snrm on my vdsl has never dipped, whatever the causes are of my errors I never see snr dips to match up. Except the upstream snrm problem I reported on here when using the phone.
To ixel thanks for your summary, can you add how to disable auto vdsl2 to it? On my spare hg612 I tried to disable vdsl2 in the gui but it is rejected.
-
Just had a friendly OR engineer in the box on pole that serves me. He was fixing a phone fault with next door. He opened the box and sprayed the wires out. My snr went up 2db! all the wires in the box were untwisted in the box and like spaghetti - looked quite normal! to me. As soon as the wires were squashed together again to go back the snr returned to its previous value. I guess I am lucky it is not worse. He said ideally the wires should be twisted in box and were in some brand new boxes. Not surprisingly it was "not his job" to do anything though. He said although cross talk does occur in lines the junction boxes are also a big source of it.
Thanks Ixel for the stats I am looking out for fast path errors stats to try to see what the DLM seems to be able to live with.
Edit In fact I wonder whether this post is rubbish and the engineer simply disconnected someone when he opened the wires up and reconnected them when he put them back - possibly by accident or on purpose.
-
Also whenever my line has had error bursts, the snrm on my vdsl has never dipped, whatever the causes are of my errors I never see snr dips to match up. Except the upstream snrm problem I reported on here when using the phone.
To ixel thanks for your summary, can you add how to disable auto vdsl2 to it? On my spare hg612 I tried to disable vdsl2 in the gui but it is rejected.
My errors don't seem to effect SNRM either, connection seems smooth and speed tests are as I'd expect them to be. My upstream SNRM seems to fluctuate though (US0 only, a typical variance of around 1dB, never the same or near the same each minute, does anyone else have that?).
To disable VDSL2 permanently on boot, I followed les-70's advice (in the GUI), see screenshot at http://i.imgur.com/UAWJgHz.png (http://i.imgur.com/UAWJgHz.png). Did you by any chance try disabling them all? If you did then that's why you had an error.
@les-70: You're welcome. I'll update the post later tonight again with more current statistics. If anything significant occurs I'll post about it.
-
yeah I tried to leave all unticked.
with at least one ticked the counter for UAS will still increase, which is bad as then the modem may send that of to the dslam on connection.
-
yeah I tried to leave all unticked.
with at least one ticked the counter for UAS will still increase, which is bad as then the modem may send that of to the dslam on connection.
Yes, depending on if the DLM uses that for its algorithm, then it could be bad. So far my own connection (since being back on fastpath) hasn't had ill effects from ES, SES, or UAS. But obviously for the average joe connection they would get hit by DLM, certainly be ES and SES assumably, but no clue as to whether also by UAS.
One other idea, though I don't know if this really helps, is you could do 'xdslcmd info --reset' before the 'xdslcmd configure <...>' command. This will reset all statistics back to their original values at boot, or should do anyway.
-
I am currently using a command file to tweak the startup of vdsl. The only advantage over dslstats is that it gets me on line a bit quicker and leaves you free to have any sampling rate you want in dslstats. I attach it in two bits, the main zip and a zip with just plink.exe. Plink needs to go in the "login" folder. I have only separated it to get round the 200kb attachment limit. The .bat file should do nothing if the modem can't be accessed or if there is already an internet connection. The modem IP occurs in two places and need an edit to suit. Mine is at ..0.64. The modem login in the login files is the default of admin. No credit to me just a mod of Snadge and Blackeagle1's work.
With the tweak you need to loose 4Mb/s to gain 1db of snr if all tones are in use - roughly on syncs of more than 60mb/s. On longer lines where less tones are in use e.g. at say a 20 Mb/s sync you may only need to loose ~1mb/s to gain 1 db of snr.
-
I am currently using a command file to tweak the startup of vdsl. The only advantage over dslstats is that it gets me on line a bit quicker and leaves you free to have any sampling rate you want in dslstats. I attach it in two bits, the main zip and a zip with just plink.exe. Plink needs to go in the "login" folder. I have only separated it to get round the 200kb attachment limit. The .bat file should do nothing if the modem can't be accessed or if there is already an internet connection. The modem IP occurs in two places and need an edit to suit. Mine is at ..0.64. The modem login in the login files is the default of admin. No credit to me just a mod of Snadge and Blackeagle1's work.
With the tweak you need to loose 4Mb/s to gain 1db of snr if all tones are in use - roughly on syncs of more than 60mb/s. On longer lines where less tones are in use e.g. at say a 20 Mb/s sync you may only need to loose ~1mb/s to gain 1 db of snr.
Interesting, thanks, I'll probably use this instead then. I finally found that list of banding profiles I was on about earlier, it was Black Sheep who posted it last year in a thread (http://forum.kitz.co.uk/index.php?topic=12896.msg244008#msg244008).
Update 22/01/2014 08:47
After relieving the downstream sync cap the DLM has decided to put me back on an INP of 3 and delay of 8ms. So it seems DLM isn't stuck, just what happened before was (I believe) caused by the banded speed I had (60/20 as opposed to 80/20). An interesting experiment nonetheless, and so tomorrow morning the modem will be back on 61/20 from my end.
-
You back on interleaved even with your capped sync? Although I guess only knocking 3mbit of your sync was only a small change maybe 74 would be better? I am back on fast path as of this morning but appear to be banded to 60mbit. Given my previous banding of 74 appeared to be permanent I am guessing I am stuck now on 60 for eternity unless I have a DLM reset. Although right now with an attainable of only 62.6 its not doing much harm unless BT fix my line. As a side note it be cool if BE and Ronski add INP support to the stats. Ironically newtronstar's prediction of 14 days I think was very close to my fast path change, I think actually 15 days.
-
The amount of errors I see would certainly seem to exceed the figures for a reduction to take place according to that doc we were discussing some months ago.
1. Please can Kitz or another point me to this document.
2. As is well known Openreach have 3 DLM settings for FTTC see below. Has anyone had their setting changed and if so did it make any difference? I would guess that "speed" would be best for avoiding interleaving.
"Dynamic Line Management (DLM) features:
Match the way a line is managed to the way
your customer uses it:
Standard – best overall balance
between speed and stability for general
internet users
Stable – prioritise stability over speed for
IPTV videoconferencing, home workers
and businesses transferring data and IPTV
Speed – prioritise speed over stability for
online gamers."
-
The discussion was in this thread based on the patents
http://forum.kitz.co.uk/index.php?topic=12896.15
As regards to anyone managing to get their BToR profile changed, I'm not aware of anyone saying they have.
The profile names between BToR and the btw systems seems to cause confusion even for the ISPs - again discussed in that particular thread. Iirc I was hoping that azzaka may be able to provide some clarification and see if the could attempt a profile change.
-
You back on interleaved even with your capped sync? Although I guess only knocking 3mbit of your sync was only a small change maybe 74 would be better? I am back on fast path as of this morning but appear to be banded to 60mbit. Given my previous banding of 74 appeared to be permanent I am guessing I am stuck now on 60 for eternity unless I have a DLM reset. Although right now with an attainable of only 62.6 its not doing much harm unless BT fix my line. As a side note it be cool if BE and Ronski add INP support to the stats. Ironically newtronstar's prediction of 14 days I think was very close to my fast path change, I think actually 15 days.
Yes I'm on interleaved again at the moment when I relieved my DS sync cap.
It sounds like you're on what I had before DLM reset on my line in December. I assume your DS sync cap your end was below 60 meg at the time?
-
I didnt cap DS sync my end. I only played on a spare hg612.
That would have been very foolish for me with a fault currently open.
-
We x-posted. 40mb is ridiculous and why I said earlier that I think even bt may not have anticipated the amount of loss that some are now seeing.
with a 62 attainable on fast path, is now just shy of 50mbit, indeed ridiculous. Maybe its not all crosstalk and BT find a fault, I hope so.
-
As a side note it be cool if BE and Ronski add INP support to the stats.
If it's in the logged data, let me know what you want and how you'd like it presented and I'll see what I can do.
-
As a side note it be cool if BE and Ronski add INP support to the stats.
If it's in the logged data, let me know what you want and how you'd like it presented and I'll see what I can do.
I believe it isnt, I will email BE.
-
actually it may be there.
modem_stats.log the 10th number before VDSL2 I think is downstream INP. 9th upstream INP
24/01/2014 07:49 58736 20000 6.5 9.7 13.6 5.2 67324 27151 PTM 0 234 22328 3890 0 0 86313 0 0 0 0 23.976 22328 3890 0 47689894 396271 33152 0 234 0 3618538057 696502 8486843 0 0 0 1149 1 0 194 0 10 0 0 0 634352 9765 0 0.1 15.1 27.6 0.0 9.6 22.8 37.7 0.1 15.0 27.5 0.0 12.1 22.6 37.7 9.0 10.2 9.6 0.0 6.5 6.5 6.5 -5.0 -28.0 4.8 0.0 10.6 7.4 7.4 Showtime 0 0 L0 17a ON ON No Showtime 14.8 0.0 51 236 1 1 64 5 12 16 0.0282 0.3771 18176 5410 0 0 0 0 1158232012 0 831248395 0 0 0 0 26 26 3.00 0.00 1.80 6.15 8.00 0.00 106.08 202.87 60678 330 VDSL2 44 0
and after fast path switch
24/01/2014 07:51 59995 20000 7.1 9.7 13.6 5.4 62424 26831 PTM 0 0 0 0 0 0 45 0 0 0 0 0.013 0 0 0 22003 7370 0 0 0 0 0 478853 0 0 0 0 1 1 10 194 10 10 0 0 0 0 0 0 0.1 15.2 27.5 0.0 9.5 22.8 37.8 0.1 15.1 27.5 0.0 12.0 22.6 37.7 9.6 10.5 9.4 0.0 7.2 7.2 7.1 -5.0 -28.4 5.0 0.0 10.6 7.5 7.3 Showtime 1 0 L0 17a ON ON No Showtime 14.7 0.0 239 236 1 1 64 5 0 16 0.1273 0.3771 15080 5410 0 0 0 0 5160100 0 980 0 0 0 0 62 52 0.00 0.00 2.04 6.15 0.00 0.00 89.97 202.87 15 0 VDSL2 0 0
-
Is it just INP you would like to see displayed ?
-
yeah the other stuff I think isnt important.
I am not 100% sure its those 2 numbers tho.
-
I am not 100% sure its those 2 numbers tho.
It is indeed those 2 numbers.
Leave it with me, I'll see if I can add the combined DS & US INP graphs in the spare space in the ongoing montage.
-
yeah the other stuff I think isnt important.
I am not 100% sure its those 2 numbers tho.
Added to the GUI, new version available for download.
-
thanks guys.
-
40mb is ridiculous and why I said earlier that I think even bt may not have anticipated the amount of loss that some are now seeing.
Ok... so I see that cross-talk is now beginning to have an effect on this area.
A few months ago BT introduced the 'impacted' and 'clean' lines on their checker. After this first took effect the range was showing as 80mbps for both on my own line.
Sometime in the past week this has changed I now see that they say down to 53.8mbps is acceptable in the 'impacted' range result :(
-
wb BE, hope you had a good holiday :)
-------
hmmm I guess I need to split this thread up, its now seems to be covering several different topics other than what it was originally intended.. things could get messy :(
This is nigh on impossible too many topics involving the original topic, stats, line faults and the DLM means plus interleaving queries, mean that I cant see how I can split it without loosing some content. It doesnt make pretty reading in its current format for anyone trying to follow whats going on without reading the whole thread and trying to figure out which reply relates to what subject. ??? Its not often I get arsy about threads going OT, but this is a classic :-X
-
sorry :(
-
Its not you chrys, I think just about everyone has had a hand in this, so its impossible to separate it out.. and now Im making it even worse by moaning about it :lol:
-
@ Chrysalis,
As a side note it be cool if BE and Ronski add INP support to the stats. Ironically newtronstar's prediction of 14 days I think was very close to my fast path change, I think actually 15 days.
Now that INP data is being graphed, have you spotted any significant changes during the periods when your connection's attainable rates/sync speeds have fluctuated & if so, how do they correspond to SNRM levels?
-
Since I have the modem stats log from 2012 data I did already check to see if INP was any different when I used to have 90mbit attainable (no stats from 110). They were 0.0 then as is now, the only time I seen it above 0.0 is when interleaving is on. Although I do believe INP can work in fast path I just think BT never use it alongside fast path.