Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[les-70]

   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!

[bbnovice]

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

[NewtronStar]

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 

[les-70]

  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.

   

[NewtronStar]

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.

[Ixel]

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.

[les-70]

  @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?

[Chrysalis]

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]

  @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.

Code: [Select]

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 .

[NewtronStar]

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 

[Chrysalis]

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?

[Ixel]

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?

Code: [Select]

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

[Chrysalis]

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.

[les-70]

  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.

[Chrysalis]

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.