Print

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

[Ronski]

It may be worth him trying a hg612 modem, I'm running a ZyXel VMG8324-B10A,  which did give me a nice boost on the downstream. I've had my line since August 2012,  and whilst my downstream has fluctuated up and down its still pretty much the same (49 Mbps). But my upstream has decreased substantially from around 12 Mbps to its current 4.4 Mbps. My line at around 450 to 500 meters well underperforms, performing like a much longer line.

Anyway a few weeks ago I tried my HG612 modem, whilst my D/S dropped I gained almost 2 Mbps on the upstream, so it could be worth trying on his line and he may well see an improvement with some D/S loss though. Note the stats were not uploaded, although I did log them on my laptop.

[ejs]

@kitz

I'm not terribly happy with that theory about the serialisation of a 1500 byte packet, or I'm missing something. It's calculated the total time it will take to transfer those 1500 bytes based on the bandwidth of the connection. On that basis, it will, of course, take the same amount of time to transfer 1500 bytes no matter how many chunks it is or isn't chopped up into.

Also, PTM chops things up into 64 octet PTM "codewords" each of which are preceded with 1 "sync" octet. This is defined in Annex N of ADSL2 (G.992.3). So I don't really see it as wildly different to ATM cells with 48 bytes of data and a 5 byte header, PTM just has less overheads.

A program or app requiring lower latency might well send smaller IP packets, which would be chopped up into fewer ATM cells or PTM codewords than a larger IP packet, but I don't really see how chopping it up into smaller pieces helps when you need all the pieces together at the other end to re-assemble it before it can go any further. That might change with G.INP, where the unit that could be re-transmitted contains a fixed number of ATM cells or PTM codewords, but there's no G.INP here.

I think the xDSL framing parameters aren't really related to the ATM cell or PTM codeword sizing. The framing parameters vary, whereas the ATM or PTM coding is fixed.

Anyway, I think it's a case of:
The attenuation is high.
The high attenuation results in low bandwidth.
The low bandwidth results in smaller frame sizes.

@WWWombat

The FEC on the upstream also adds coding gain, so it wouldn't necessarily get all that bandwidth carrying the FEC data available to carry user data. Taking away the FEC would also take away the coding gain. The DLM recently decided to switch off FEC+interleaving from my ADSL2 connection, and my line speed is now lower, despite there now being no bandwidth taken up by FEC data.

[kitz]

The high attenuation results in low bandwidth.
The low bandwidth results in smaller frame sizes.

This I agree with as per my observation that we only seem to see small frame sizes on the lower speed links.
   
I'm not doing a good job of explaining where I was going with the rest in respect of AAL5, or rather HDLC for PTM.   Its not going to provide a solution for the op, just that there is obviously some reason why the low speed links have smaller frames.:/

On ECI cabs, the upstream R value appears to set at 16. I don't think there is any way you can get rid of upstream FEC.   npr's is odd as it looks like his cab may have had a f/w roll back and according to BTr a DLM reset, but who knows.

Wombat has already had a look at the graphs and I don't see anything of substance in there either.
 

[burakkucat]

Wombat has already had a look at the graphs and I don't see anything of substance in there either.

I deliberately refrained from making any comment at the time I posted those plots. However I have to agree that the overall poor performance is due to the length of the metallic pathway and, thus, the attenuation of the circuit.

As a point of reference, we know that Bald_Eagle1 has a circuit of approximately 1000 metres in length and receives a significantly better service.

[WWWombat]

@kitz
I think I get the point your posts are trying to make, but I need to put more mental effort into fully thing it through ... that'll have to wait until after the holiday, I think

@others
I've sat on my original thinking, and haven't changed my mind yet. I think the way the bit-loading drops rapidly away from tone 650ish is the giveaway.

I'd like to compare the Blog and bit-loading for other night attenuation lines on MDWS, but that's beyond my limited access means right now. BE1's line might be good starting point.

One thing also hit me, from looking at BT's recent STIN on long-range VDSL: the line profile described in there has settings for both a "D" parameter and a "DELAY" one. Does this mean dlmmcould be setting the detailed line settings such as R, D, I and N? I always thought the modems figured out those values starting from the definition of INP and Delay.

[ejs]

BT STIN 522 has Dmax, but it's in units of ms so I think this is the maximum interleaving delay (delay_max), and it also has DELAYMAX_RTX, which I think sets the maximum amount of delay that could be caused by the retransmission.

[WWWombat]

So it does 

A maximum interleaving depth of 16 would have fitted well with the observations of G.INP so far. Nice idea while it lasted, anyway.

I can understand the maximum delay in terms of retransmission, but 16ms sounds like a large latency delay to allow from the interleaving when retransmission is also in play. Plus 8ms from the upstream.

[hendry]

GOOD NEWS! So I've had a breakthrough with Superfast Cornwall and a BT Openreach engineer came around our property to look at the line.

Surprisingly the engineer Jed this time was very helpful and said there was definitely a fault with the line. We had an engineer before who basically said we had to accept 0.4 upstream. So I am little confused at BT O's fault thresholds & estimates.

At first Jed said he has already found a couple of "dry joints" along the entire length of the line. I'm not quite sure what that means.

He also said he was surprised the upstream is so low, because of "lower frequencies" IIUC?

Anyway, he said at the first pole upstream was measured to be about 2M up. So a long story short, the entire length of the drop line (~60m?) was replaced and now I can happily report we now have 1.5 UP from the house.

I've uploaded a couple of updates to http://archive.webconverger.com/dslstats.zip so you can perhaps compare router stats before and after the repair.


The engineer said that's about what you can expect for being 1300m away from the cabinet. I asked about other rural homes that are further away and he said they are better off on ADSL after 2km! So I am little bit dumbfounded how this technology was deemed appropriate for a rural setting. He did agree with me that overhead fibre is the way to go but he funnily mentioned how Tintagel council at great expense, have got rid of all of its poles since people think they are unsightly!! That's like burning money to me.

He said that "Fibre on Demand" should be available via Superfast, though I've not yet been able to get a quote. I think they are still deciding where it's going to be rolled out in light of  possibly no/less EU finding.

I'm super grateful that Facetime actually seems to work now. However I really do want more. Please sir.

[d2d4j]

Hi

Glad it's been resolved

If you want more, I would move the nt5e to the very point where the drop wire first touches the property (from memory, your video shows it running down the side and then through to your room).

This should remove between 5 - 10 m of cable, not be near any mains power, fuse box and if 2mb was attained at first drop pole, maybe it might increase by 100kb or so. Also, if phone extensions not needed, disconnect them, as I seem to remember you had a small increase

I hope you don't mind my thought

Many thanks

John

[kitz]

Hi.   That is great news thanks for getting back to us.

The concensus by both myself and wombat was that there wasnt really anything more that could be eked out from the downstream, but the upstream was definitely underperforming.

At first Jed said he has already found a couple of "dry joints" along the entire length of the line. I'm not quite sure what that means.

Im not a Telco engineer and Blacksheep is the man to answer that.  I think he means a particular type of HR fault where the cable joins dont make proper contact. 
Sometimes using the phone improves the dsl signal due to the small electrical current bridging the gap and 'wetting the line'.  See ADSL only works when the phone is being used.  HR faults normally always affect the upstream first and the most.

He also said he was surprised the upstream is so low, because of "lower frequencies" IIUC?

That is indeed the case with with ADSL, but VDSL has split bands so certain downstream bands are lower frequency than some upstream.  Wombat noticed that your upstream blocks were low.  The reason why I wanted to see a bit loading graph is to see if I could see why bitloading was so low in the upstream.
From the bit graph kindly provided by b*cat here, you can see your upstream U1 band (in green) is at higher frequencies (circa tone 1000) than your D1 (in red).   

Surprisingly your hlog for U1 on that day looked ok.   But then again hlog is a snapshot in time - taken when the modem syncs.
HR faults are known to be intermittant, it may be that you were 'lucky' in that the day the engineer arrived he was able to spot something using his equipment which does an equivalent of hlog and QLN. 

He said that "Fibre on Demand" should be available via Superfast,

From memory I dont think it was an option available to you.  It will usually say on the BT checker if it is.   Not many ISPs were selling  FTTPoD to consumers...  and although 'technically' Openreach is offering it, BTw has suspended it to their retailers. :/ 

[kitz]

I've uploaded a couple of updates to http://archive.webconverger.com/dslstats.zip so you can perhaps compare router stats before and after the repair.

Thank you for those.   I have a lot on atm and must do some important prep work tonight before tomorrow.
Ive started to extract a couple of days which are possibly relevant but dont have time atm to do an in depth review.

I will copy out some of the main stats and comment briefly.

I'll also attach one of the relevant files If someone has chance to extract a h-log etc graph from it, then it would be most appreciated. [see below 25th.zip]

[ejs]

Upstream ought to be capable of 1Mbps, but it needs to stop using FEC to achieve that. Try more modems?

The more recent stats prior to the fix were with zero FEC, but achieving an upstream speed of 304kbps on the 19th and 332kbps on the 24th. That's worse than it was when it did have FEC on the upstream.

After the fix, presumably the DLM was reset and it's currently operating with FEC+interleaving.

[kitz]

24th

Code: [Select]

adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    4
Last initialization procedure status:   0
Max:    Upstream rate = 437 Kbps, Downstream rate = 18346 Kbps
Bearer: 0, Upstream rate = 332 Kbps, Downstream rate = 18155 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):        6.3             7.7
Attn(dB):        32.0            0.0
Pwr(dBm):        3.9             3.9

                        VDSL2 framing
                        Bearer 0
MSGc:           26              33
B:              239             10
M:              1               1
T:              53              5
R:              0               0
S:              0.4203          1.0000
L:              4568            88
D:              1               1
I:              240             11
N:              240             11

                        Counters
                        Bearer 0
OHF:            10723615                592911
OHFErr:         537             0
RS:             0               3642638
RSCorr:         0               0
RSUnCorr:       0               0

                        Bearer 0
HEC:            592             0
OCD:            7               0
LCD:            7               0
Total Cells:    2093248990              0
Data Cells:     57070792                0
Drop Cells:     0
Bit Errors:     0               0

ES:             185             0
SES:            42              0
UAS:            4741            4701
AS:             59967

                        Bearer 0
INP:            0.00            0.00
INPRein:        0.00            0.00
delay:          0               0
PER:            5.59            16.31
OR:             45.78           19.12
AgR:            18200.90        350.63

Bitswap:        4671/4673               1/1

Total time = 20 hours 17 min 23 sec
FEC:            0               0
CRC:            7420            0
ES:             185             0
SES:            42              0
UAS:            4741            4701
LOS:            1               0
LOF:            22              0
LOM:            24              0
25th

Code: [Select]

> adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason:    4
Last initialization procedure status:   0
Max:    Upstream rate = 1220 Kbps, Downstream rate = 22987 Kbps
Bearer: 0, Upstream rate = 1510 Kbps, Downstream rate = 17764 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):        6.4             6.4
Attn(dB):        31.4            0.0
Pwr(dBm):        7.0             6.9

                        VDSL2 framing
                        Bearer 0
MSGc:           26              33
B:              47              83
M:              1               1
T:              64              12
R:              16              16
S:              0.0859          1.7719
L:              5960            456
D:              753             19
I:              64              101
N:              64              101

                        Counters
                        Bearer 0
OHF:            417610          144594
OHFErr:         20              0
RS:             106862567               908778
RSCorr:         8714            0
RSUnCorr:       2787            0

                        Bearer 0
HEC:            623             0
OCD:            2               0
LCD:            2               0
Total Cells:    78740765                0
Data Cells:     3221798         0
Drop Cells:     0
Bit Errors:     0               0

ES:             358             0
SES:            168             0
UAS:            53854           53688
AS:             2306

                        Bearer 0
INP:            8.00            2.50
INPRein:        0.00            0.00
delay:          16              8
PER:            5.51            16.00
OR:             46.38           19.48
AgR:            17810.42        1529.07

Bitswap:        53/53           0/0

Total time = 2 days 2 hours 22 min 42 sec
FEC:            494702          18
CRC:            14296           0
ES:             358             0
SES:            168             0
UAS:            53854           53688
LOS:            9               0
LOF:            105             0
LOM:            61              0

The obvious thing I notice is that the line now has Interleaving and INP.     
Damn looks like a possible soft DLM reset rather than the engineer doing a full reset and putting it on open profile

@Hendry - what that mean to you is that there is still a little bit more speed in that line for you. INP = 8 is high.  Currently FEC overheads are costing you some line speed.
Hopefully in time the DLM will remove it and your downstream speed should improve to ~20Mbps.

---

I'm puzzled why an OR engineer would only do a soft reset.. in fact I didnt think they did.    One possible reason is the day the engineer arrived the line could possibly have been behaving quite badly and it had lots of Errors.   If so it could be that DLM has kicked in by itself  and the OR engineer didnt actually do a DLM reset.

I'm sorry I really have run out of time to look at the stats in more depth.   If no-one else beats me to it first, then it will be weekend before I get chance to do so.

[kitz]

The more recent stats prior to the fix were with zero FEC, but achieving an upstream speed of 304kbps on the 19th and 332kbps on the 24th. That's worse than it was when it did have FEC on the upstream.

After the fix, presumably the DLM was reset and it's currently operating with FEC+interleaving.

Your post crossed with mine.   Yep thats immediately what I noticed.
INP = 8 though seems very high.    By default a soft reset should set to INP 3 or 4 and Interleave delay of 8  (low)...  not 16 (high).
Hence me wondering if DLM kicked in by itself as the line could have been very bad that day for the engineer to spot the HR fault.

Why hasnt a full reset to Open profile been done?
Sorry really do have to go now.

[burakkucat]

I have taken the ZIP format file that Hendry has provided, selected the last textual file for each day that contains valid data (to allow snapshot graphs to be plotted) and then plotted the usual graphs, for each.

Out of personal interest, I have also calculated "cele" (a parameter of my my own creation) from the transfer function for each day's data-set. It confirms that there was some form of maintenance performed on the metallic pathway between yesterday (Wed 24th August) and today (Thur 25th August). 

Attached are two Hlog plots for the circuit, created using data harvested on 2016-08-08 and 2016-08-25, respectively.

For those inquisitive Kitizens, I have made available a ZIP format file containing all the snapshot graphs that could be plotted from the data so provided.

[Edited to insert a missing apostrophe.]