It would probably annoy the hell out of if it happened to me! IBut it should work and everything is as it should then why isnt it :/ Sometimes the easiest and most irracional solution work and glad you got it in the end

WWWombat thank you very much for the explanation. Not that I understand it now... but I have better idea of what to look at in the stats in regards to interleave. Thanks for your time.

Do you not think it would have been more helpful to write that then? Instead of writing an ambiguous statement that looks to make another statement seem inaccurate? When it isn't.

The salient point is that if you're master socket exhibits the correct polarity, anything connected to it is also likely to, if installed correctly.

It seems the the first reaction on here is to attempt to discredit other members, instead of helping them!

Paul

It seems the the first reaction on here is to attempt to discredit other members, instead of helping them!

No attempt to discredit, just to inform.

Guys I have bit of an update. I have updated firmware on the router to the newest one. I did this on thursday 28th so two days after my initial post. I got 1meg increase in max attainable with rest of things staying pretty much as they were.

Then... a day later I started getting strange bursts of errors. Whenever I resynced I would get instantly few hundred fecs, few crcs and hecs. It did not matter which firmware I was using I tried a three different ones for a good measure plus flashing to original and then back to unlocked ones again. Also I have lost the SNRm - it has gone back from 8,2dB down to 6 and below even at night. It was creeping down ever so sligtly taking max attainable with it (down to 50000 ish at 5,3).

Then following morning modem resynced on the fly at 4am and I was put on heavier interleave. Ping went from 16ms up to 27ms, sync got limited to 37,7 on downstream. So clearly my messing around got me in trouble with dlm... I havent got full stats stats from that moment just a snippet of errors just after re-syncing. See below:

Line rate (kbit/s) 37735 10000 0 0
CRC errors 719 0 0 0
FEC errors 7 0 0 0
HEC errors 42 0 0 0

I did not stop there though. I decided that something else must be wrong here with the wiring. When the engineer installed everything he also moved master from where it used to be to the lounge. I had two extensions also previously so he just rewired them bacwards from the new master going trough the same four pair twisted cable I believe. So crimps at the old master plus crimps at the extension one and new master instead extension two. then backwards trough the same cable to extension one and extension two at the old master. All connected to mk2.

Firstly I proceeded to disconnecting all of the extensions. It did not make much difference to be honest apart from fewer errors on line at the time of testing. Nothing conclusive. So I thought last thing I can do is disconnect the extension wires from mk2 faceplate. Whilst doing that I swopped the incoming around again for a good measure. In response to b4dger and Zarjaz this did not make any difference. At least I dont believe that it did. I believe I had issue with the extensions wired to the mk2 going back trough the same cable. Initially after disconnecting the wires I got 70 on downstream At this point I was screwed anyway with the latency but my speed went bac up to 39999. Errors looked preety good to. Stats below from around eleven twelve last night :

# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Max: Upstream rate = 20887 Kbps, Downstream rate = 70528 Kbps
Path: 0, Upstream rate = 10000 Kbps, Downstream rate = 39999 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 9.6 12.2
Attn(dB): 0.0 0.0
Pwr(dBm): 13.9 7.4
VDSL2 framing
Path 0
B: 26 47
M: 1 1
T: 64 64
R: 16 16
S: 0.0215 0.1521
L: 16025 3366
D: 2019 211
I: 43 64
N: 43 64
Counters
Path 0
OHF: 4095062 870442
OHFErr: 1 0
RS: 1572503390 3768198
RSCorr: 3115 0
RSUnCorr: 26 0

Path 0
HEC: 11 0
OCD: 0 0
LCD: 0 0
Total Cells: 651615839 0
Data Cells: 5166713 0
Drop Cells: 0
Bit Errors: 0 0

ES: 1 0
SES: 0 0
UAS: 17 17
AS: 8474

Path 0
INP: 8.00 4.00
PER: 2.06 9.73
delay: 11.00 8.00
OR: 93.16 59.16

Bitswap: 197 7

Total time = 2 hours 21 min 32 sec
FEC: 3115 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 17 17
LOS: 0 0
LOF: 0 0
Latest 15 minutes time = 6 min 32 sec
FEC: 18 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 2 hours 21 min 32 sec
FEC: 3115 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 17 17
LOS: 0 0
LOF: 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
Since Link time = 2 hours 21 min 13 sec
FEC: 3115 0
CRC: 1 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0


Furthermore... I did all this last night including suddenly pullling the face plate of the master thus losing connection (LOS). This morning I have found that I got another resync on the fly. It was rather interesting result tho as ping went down and SNRm gone up to 13dB ish.
I got burst of errors but this happened during the resync so I am not too worried about. Interesting is error rates since the link up
Below see stats taken just now :


# xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 19385 Kbps, Downstream rate = 70328 Kbps
Path: 0, Upstream rate = 9999 Kbps, Downstream rate = 39996 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 13.2 12.8
Attn(dB): 0.0 0.0
Pwr(dBm): 13.9 7.4
VDSL2 framing
Path 0
B: 57 236
M: 1 1
T: 64 23
R: 16 16
S: 0.0461 0.7543
L: 12835 2694
D: 701 1
I: 74 127
N: 74 254
Counters
Path 0
OHF: 17794515 691039
OHFErr: 4 0
RS: 3416546547 3559522
RSCorr: 3873 0
RSUnCorr: 12 0

Path 0
HEC: 4 0
OCD: 0 0
LCD: 0 0
Total Cells: 3041431422 0
Data Cells: 10680089 0
Drop Cells: 0
Bit Errors: 0 0

ES: 8 0
SES: 6 0
UAS: 35 35
AS: 39548

Path 0
INP: 3.00 0.00
PER: 2.21 8.67
delay: 8.00 0.00
OR: 86.72 59.02

Bitswap: 78 7

Total time = 21 hours 14 min 36 sec
FEC: 13169 0
CRC: 2599 0
ES: 8 0
SES: 6 0
UAS: 35 35
LOS: 5 0
LOF: 5 0
Latest 15 minutes time = 14 min 36 sec
FEC: 449 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 2 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
Latest 1 day time = 21 hours 14 min 36 sec
FEC: 13169 0
CRC: 2599 0
ES: 8 0
SES: 6 0
UAS: 35 35
LOS: 5 0
LOF: 5 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
Since Link time = 10 hours 59 min 7 sec
FEC: 3873 0
CRC: 4 0
ES: 1 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0


I dont know what to say other than it seems vdsl is very sensitive indeed to any dodgy wiring and that I am lucky to go from 40 on downstream max attainable to 70 after some messing with my home wiring. With current error rates I am hoping that dlm will reletn even more and that my pings will be even lower. I am happy with the 40 meg service as this gives me now plenty of overhead space for any crosstalk and other surprises so I am not even thinking about going on to the faster package. Want my pinge back to below 10ms

Cheers Kamil

Edited by deleted (Sun 31-Aug-14 21:12:29)

this firmware has the same dsl code as the previous (blob) it is believed the only thing changed is the VOIP bug that revk of aaisp reported been fixed.

Edited by Chrysalis (Sun 31-Aug-14 22:11:20)

I guess is purely coincidence then. None the less this is what started after updating. But downgrading did not make any difference either. Only removing extensions did.

I don't suppose you have any Hlog graphs from when the extensions were connected & after you disconnected them do you?


What you describe could have been causing a bridged tap effect.


The Hlog graphs would show a pronounced valley with a bridged tap (impacting on attainable rates & sometimes actual sync speeds) & a much smoother curve without it.

I have them thanks to you and other guys who made this possible

Please see links below as I can not insert pictures here. (Is it even possible?)

Firstly with extensions still attached :

http://i1133.photobucket.com/albums/m582/kamilrott/h...
http://i1133.photobucket.com/albums/m582/kamilrott/h...

Second one after disconnecting everything:

http://i1133.photobucket.com/albums/m582/kamilrott/h...

Regards, Kamil

Edited by deleted (Sun 31-Aug-14 22:55:48)

The first 2 graphs do show bridged tap symptoms (2 of them).

The 3rd one (after disconnecting the extensions) is how a healthy Hlog should look.

Who needs an expensive JDSU ???




I have a number of extensions wired from the downstairs faceplate to upstairs & then back downstairs again to another room.

They are connected in 'daisy chain' manner & thus I see no signs of bridged taps at all in my Hlog graphs.



My drop wire was replaced to come in directly to the downstairs master socket a couple of years ago in an attempt to fix an intermittent, but quite frequent disconnection fault.

It originally came into the upstairs master socket.

The original installing BTOR engineer used my shielded 2 pair extension cable from upstairs to make the master socket downstairs.

He used the other pair in the extension cable to backwire to what was originally the master socket upstairs to make it an extension.

From there, the other extensions were wired, again in 'daisy chain' manner.

That wiring setup was fine & again, there were no bridged tap extensions.


I believe backwiring is somewhat frowned upon, but using decent cable & correctly wired it doesn't actually seem to do any harm.


The intermittent fault was eventually traced to a dodgy connection where the undergound cable connected to the pole top mounted DP.





If you do reconnect the phone extensions, try to do them in a daisy chain manner & re-check your Hlog graph on completion.

Note that Hlog & QLN graphs are only updated when a connection resyncs, during the training phase.

So you may need to force a resync to ensure you are viewing the updated graphs.