Print

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

[door_bell]

Gents/Gentleladies!

I'm still VERY green behind the ears when it comes to anything FTTC related - but I'm soaking up as much as possible. Wanted to keep tabs on the connection and do some data logging but was supplied with the ECI/R variant - which needs some soldering work to JTAG. I'm up for a challenge but the wife would shoot me if I knackered it, soooooooooo I got myself a HG612 and promptly slapped the unlocked noBTagent firmware on 

Just got it up and running with DSL stats and HG612 modem stats for some longer term logging, but I'll admit to struggling a bit with which bits are important to me. To my untrained eye, it looks like it's good - but is it?

Where do you start, what's important to you when you look? Here is some info.....can give more if you can give me some kid-glove handling. I'm a long time cable user, so its' a big change.

I'm about 350M from the cab (which was the only thing the Kelly engineer could tell me). Here we go:

Code: [Select]

xdslcmd info --Bits
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 37078 Kbps, Downstream rate = 107040 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79987 Kbps

Code: [Select]

xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 37050 Kbps, Downstream rate = 107040 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79987 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): 13.6 18.3
Attn(dB): 12.9 0.0
Pwr(dBm): 13.2 2.5
VDSL2 framing
Bearer 0
MSGc: 18 150
B: 239 236
M: 1 1
T: 23 5
R: 0 16
S: 0.0955 0.3771
L: 20104 5410
D: 1 1
I: 240 255
N: 240 255
Counters
Bearer 0
OHF: 633060 170958
OHFErr: 2 0
RS: 0 2516867
RSCorr: 0 8
RSUnCorr: 0 0

Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 160939681 0
Data Cells: 2188742 0
Drop Cells: 0
Bit Errors: 0 0

ES: 2 0
SES: 0 0
UAS: 26 26
AS: 1048

Bearer 0
INP: 0.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 1.65 6.15
OR: 116.09 202.87
AgR: 80103.09 20203.27

Bitswap: 559/559 1/1

Total time = 17 min 54 sec
FEC: 0 8
CRC: 2 0
ES: 2 0
SES: 0 0
UAS: 26 26
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 2 min 54 sec
I'm thinking it all looks OK.....but who knows (not me!!)

Cheers Muchly

[burakkucat]

Max:   Upstream rate = 37078 Kbps, Downstream rate = 107040 Kbps
Bearer:   0, Upstream rate = 20000 Kbps, Downstream rate = 79987 Kbps

At the time that snapshot was taken, your modem had synchronised with the MSAN at 37 Mbps US and 107 Mbps DS. Which is very good. 

As a consequence, your service is operating at the upper limit of the banding, namely 20 Mbps US and 80 Mbps DS. The maximum possible. 

As for the bitloading graph, you have only shown us part of it. (With a profile 17 VDSL2 service, the tones go up to 4095.) What we can see, again, looks good.

[door_bell]

Cracking reply - thanks!

Highly frustrating when the modems come locked by default - can see why they do it, but it's still annoying none the less.

For completeness, I've attached all the tones - didn't see that checkbox! Not sure why the middle group is low - normal?

Night calls, crazy day tomorrow!

Cheers,

D_B

[burakkucat]

  Hmm . . . The bit loading in the US1 band does look -- er -- a bit wimpy. (Predominately 2 bits across the entire band, with a few tones at 3 bit and a few at 1 bits loading.)

As I do not have personal experience of a VDSL2 service, I think I should leave it for others to comment. An Analytical Eagle, perhaps?

[Bald_Eagle1]

My theory (& that's all it is) is that as much bit loading as possible is carried out in the higher frequency bands on those connections that can actually make use of them.

This would then reduce the potential 'swamping' effect at lower frequencies that longer connections are only able to use (mine, for example).

I have attached bitloading graphs from firstly another higher speed, shortish length connection, showing a similar pattern & secondly from my own connection (1000m to 1100m in length).



EDIT:

@ door_bell,

I have to say your connection has remarkably high attainable (max) rates, with plenty of spare SNRM, for a 350m line length & FWIW, it's currently operating on fastpath:-

SNR (dB):    13.6       18.3

D:       1       1

[door_bell]

Thanks for the input Mr Eagle

Makes sense about the tones being for longer/slower connections - clever!

Didn't think it was a problem as I actually manage to hit a 74mb down 19. Something up last night.

I saw a link somewhere that told you how to ID the kit in the DSLAM (ecI or Huawei) using the diagnostics - can you tell??

I thought it was ECI from the vents and pointy roof - but now the speeds are equal/better than the ECI modem I'm not 100% sure.

Still....pleased it looks good )

[burakkucat]

An invocation of xdslcmd info --vendor from the modem's CLI will disclose the remote chipset and, thus, identify the MSAN.

For example, I am using an Huawei HG622 on an ADSL2+ service and see the following --

# xdslcmd info --vendor
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason:   8000
Max:   Upstream rate = 1076 Kbps, Downstream rate = 6092 Kbps
Channel:   INTR, Upstream rate = 1020 Kbps, Downstream rate = 4932 Kbps

ChipSet Vendor Id:   IFTN:0x71c6
ChipSet VersionNumber:   0x71c6
ChipSet SerialNumber:   
#

From the above, IFTN tells me that the MSAN has an Infineon chipset. 

Example images of ECI and Huawei cabinets are attached, below.

[door_bell]

Sound as a pound.

Gave it a go and got:

Code: [Select]

BusyBox v1.9.1 (2013-06-01 18:30:08 CST) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# xdslcmd info --vendor
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 0
Last initialization procedure status:   0
Max:    Upstream rate = 36693 Kbps, Downstream rate = 106804 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 79987 Kbps

ChipSet Vendor Id:      IFTN:0xb203
ChipSet VersionNumber:  0xb203
ChipSet SerialNumber:   7035210649
So, it's IFTN:0xb203 which makes it ECI.

Don't think it was either of the pics you posted, it was smaller. It was the first picture you posted!! 

 

[kitz]

My theory (& that's all it is) is that as much bit loading as possible is carried out in the higher frequency bands on those connections that can actually make use of them.

This would then reduce the potential 'swamping' effect at lower frequencies that longer connections are only able to use (mine, for example).

I think there may be something in that theory.  Further complicated by the various PSD masks of course.

When it comes to bit loading, the water-filling method is traditionally used.  However when it comes to fttc, particularly in the U1 channel, its evident that this is not the case and some other form of algorithm is in place. 

From my own line (see below with that lovely 'L' shape) the U1 band shows something that for sure, is neither indicative of  water-filling or PSD masking.

The bit loading in my U1 band, to me looks more like what is known as bog standard greedy bit loading.  "Greedy" bit loading isnt always good....because the lower tones fill up first...  the effect of which causes more x-talk and why water-filling is the preferred method, as it forces more use of the higher tones for shorter lines.    There is no reason why BT would move to straight forward greedy bit-loading, so that implies there is something else going on with the various channels, there are algorithms that can analyse multiple lines and adjust accordingly, but afaik these can be time consuming and processor intensive.    Therefore BT are up to something else.

The rest of my channels (other than U1) dont seem to display this behaviour.  Is it possible that they have indeed some algorithm that disperses with waterfilling for U1, and if the line is capable shunts what bits it can over to U2.   The effect of this would mean less x-talk in the region of tone 1000 ish onwards for the longer lines.


(yes I'm aware Im still using an old version of dslstats, but a sick PC and poorly & busy kitz has meant she hasnt got around to sorting things yet - but at least you get the idea)