In reply to a post by WWWombat:

I've been meaning to get around to playing with this... and SWMBO is away at the weekend, so I might get a chance!

Are the plotting scripts available anywhere? If so, I'll try doing my own plotting.

In the meantime, I wanted to point this out...


I noticed the difference between the 2 graphs as being the location of the "gash" (although I'm not sure everyone has the same idea of which bit is being called the gash!): Orly's gash (or dip) appears to end around tone 250, in the SNR graph (ie top graph), while griff_90's gash appears to finish around tone 500 in the same graph (but second down in their image).

I suspect this is indeed caused by the spectral power mask applied at the cabinet - and that the 2 cabinets have different masks.

The document linked above: BT's VDSL Primer from 2009, shows the masks BT intended using at the time. See pages 31 and 32 (of 66).

The masks may put the top of the gash at 600kHz (for cabinets far from the exchange), up to around 2MHz for those closest the exchange.

So... I bet that Orly's cabinet is further from the exchange than griff_90's.

However... I'm not convinced that this document represents the actual deployment at Openreach today. Some of the screen-grabs here show that BT are using US0 (25kHz - 138kHz) which isn't shown in the band-plan 997 in that document, and the spectral mask makes no allowance for it either. I suspect there are some differences in reality...

On a separate note: this mask is a way in which the E-side distance can still affect the bandwidth you see as a customer; the overall behaviour of VDSL2 isn't *just* dependent on the D-side distance.

Hi WWWombat,

Would you be able to expand a little on your comment regarding the E-side affecting the bandwidth?

I have been experiencing some low FTTC speed issues & would like to understand where the issues could be, especially as visiting engineers claim my connection is operating as intended.

My download speeds have been a minimum of 10Mb or so down since the first month's excellent speeds.

Pauline.

Edited by deleted (Tue 11-Oct-11 12:27:23)

A TDR is does not require the pair to be looped. It will measure straight opens / disconnections and also loops (as in shorts / fault).
The only time a loop is required is when testing for resistance to ground . insulation issues etc (bridge testing).

In reply to a post by Anonymous:

A TDR is does not require the pair to be looped. It will measure straight opens / disconnections and also loops (as in shorts / fault).
The only time a loop is required is when testing for resistance to ground . insulation issues etc (bridge testing).

Yes, agreed Anonymous. I thought I had previously mentioned that to Asbokid in one of my prior PMs. Perhaps he's a little bit forgetful . . . rather like myself.

Anyhow it's worthwhile (re)stating, to make the point clear for anyone else who reads through all the postings of this thread.

Edited by burakkucat (Thu 13-Oct-11 03:19:54)

Just a quick note to mention that Asbokid has now uploaded a revised version (2.0) of the Linux graphing script (graph.sh) to his Google Docs page [1].

Little_bird (a.k.a. Pauline) contacted me earlier to say that she is now converting the Linux script to a batch file, suitable for use in a Windows environment.

[1] https://docs.google.com/leaf?id=0B6wW18mYskvBNDI2YmQ...

Edited by burakkucat (Thu 13-Oct-11 03:48:34)

In reply to a post by burakkucat:

Little_bird (a.k.a. Pauline) contacted me earlier to say that she is now converting the Linux script to a batch file, suitable for use in a Windows environment.

I am indeed attempting to convert burakkucat's excellent Linux script to a native Windows batch file.

However, I am slightly hampered by the facts that:-

a) there appear to be some fundamental operating system differences to overcome. &
b) I am a novice at this & don't really know what I am doing

I do have a working Windows batch file, but it does still require some further refinement & testing.


Pauline.

Thanks for the correction, guys.

Hypothetically, with no need to open the cabinet, does this means that TDR tests could be performed by an end-user with the appropriate equipment, e.g. a "mole" or a "hawk" ?

In reply to a post by asbokid:

Hypothetically, with no need to open the cabinet, does this means that TDR tests could be performed by an end-user with the appropriate equipment, e.g. a "mole" or a "hawk" ?

I suppose it could be done . . . But perhaps a suitably qualified person ( ) would care to comment? Maybe Zarjaz could add a few "wise words"?

First tentative use of linux version of DMT as modified by asbokid for OR modem:-


http://i1119.photobucket.com/albums/k631/44_bh/23Oct...

Just seen some interesting stats when logging into the OR Modem:

Line Status
Help
Downstream Upstream
Attainable rate (kbit/s) 92960 31091
SNR margin (dB) 21.3 22.5
Line attenuation (dB) 0 0
Output power (dBmV) 13.8 -6.3

So checked via putty and seen:


# xdslcmd info --show
xdslcmd info --show
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 2
Max: Upstream rate = 31048 Kbps, Downstream rate = 92960 Kbps
Path: 0, Upstream rate = 10000 Kbps, Downstream rate = 39998 Kbps

Link Power State: L0
Mode: VDSL2 Annex B
VDSL2 Profile: Profile 17a
TPS-TC: PTM Mode
Trellis: U:ON /D:ON

Very nice stats that, should see 80/20 sync very easy from that when they enable it.