Print

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

[kitz]

Yes, Ive seen it myself on the upstream many a time too. 
However ive not seen it personally on the downstream before.  You are likely correct in that it is something to do with the rolled out router firmwares and changes made at the DSLAM. 

We know PhyR is a broadcom thing, but I suppose it is possible that they could sell the technology to other manufacturers.  I think one of the guys in the other thread said hed seen it in action on another DSLAM  (may have been IFTN - cant recall and cant search atm).

Im not certain about it being PhyR - thats just a guess -  but it does seem to fit.  Although it is possible to apply Error Correction without Interleaving, when I was doing research into error correction for the page I wrote years ago, it was said that block encoding (ie Reed Soloman) needed interleaving to also be applied and that the 2 were always used in tandem.  I suppose the other alternative is some bods somewhere deep in the bowels of the BT dungeons that never see the light of day have come up with their own version of PhyR..   but I think the first seems the most likely.
 

[Ragnarok]

Has anyone managed to trick DLM with regards to interleaving and to reduce the INP level ( which most likely relates to FEC levels as FEC effectively is a redundant data stream to use for error correction without retransmission, occupying a section of the data stream ).

Does Les-70 idea to cap the speed on the modem end and reduce the bit loading and increasing the SNR margin work well enough to reduce error rate and get the DLM to tone down interliving or INP/FEC.

Might there be something on the ECI modem to set the maxrate.

[NewtronStar]

Has anyone managed to trick DLM with regards to interleaving and to reduce the INP level ( which most likely relates to FEC levels as FEC effectively is a redundant data stream to use for error correction without retransmission, occupying a section of the data stream ).

Does Les-70 idea to cap the speed on the modem end and reduce the bit loading and increasing the SNR margin work well enough to reduce error rate and get the DLM to tone down interliving or INP/FEC.

Might there be something on the ECI modem to set the maxrate.

What I think Les-70 is doing is to reduce the (bearer) to a minimum this will cause the DS ES to reduce but with a slower throughput, all Les-70 is doing is to make the DLM think his line is good and after time put him back on Fastpath but at the end of the day his line is to noisy to run at the Max Bearer so he is fooling himself not the DLM he will have to Decrease and Increase the Bearer every couple of months just to have fastpath.

I would just leave it to the DLM.

[konrado5]

kitz: Bald_Eagle1 has RS coding despire fast path. He has R values significantly higher than 0.

R values are 14 DS & 12 US

I've read about RS encoding on fast path at polish scientific book about xDSL.

Best regards
konrado5

[Bald_Eagle1]

I've read about RS encoding on fast path at polish scientific book about xDSL.

So you may be able to answer my queries then.

I have always seen & expected to see DS RSCorr whenever my connection has been Interleaved.

But, why am I now seeing DS RSCorr on my fastpath connection when I never used to see it (when on fastpath)?

In other words, what is causing it?

Is it a fault that I need to report to my ISP?

[les-70]

  @Neutronstar  I don't entirely disagree about your comments on speed capping except that I don't think I am fooling myself.

 I have been capping the speed by roughly the reduction expected with with interleaving.  All was fine for 4 months but I then last Friday I had a day with a new modem/router with no cap.  That day had quite a few resyncs whilst things were being set up, and then on top of that a very large error burst.  The result has been to put me on interleaving with INP 3.5 and a level of 1273.  The speed is just a couple of Mb/s above my previous cap.  I have said elsewhere that the interleaving impresses me as with it I get zero ES and CRC over 4 days now. It is making better use of the available bit loading than my cap.   I also don't I notice the difference from fast path.  I used to when on adsl.  I will need to wait until/if interleaving is removed to tell if I have been banded as I am with TalkTalkBusiness and can't use the BTor tester.  Banding, if that is the right word,will do exactly the same as my capping limit.

    My inclination is continue capping the speed at the level that interleaving will impose relative to the attainable.  As far as I can see I will be more likely to get fast path and I will  not be loosing any speed relative to an interleaved connection.   I also suspect that given how effective the interleaving is the DLM may turn it off.    Maybe I should keep it the way it is by doing 4 resync's a day!! 

   A further issue for my line is the upto 6db fall and rise my line SNR shows at about 08:00-09:00 and 21;00-23:00 respectively when people switch on and off.  When the DLM responds I will have an attainable of about 94Mb/s cf the daytime value of 77-78Mb/s.  I guess the DLM would end up banding/capping me anyway and I don't like any unexpected resync's when I am working.

   As a further p.s. to BE1 I notice that I do get FEC on my upstream when on fast path.

[konrado5]

I've read about RS encoding on fast path at polish scientific book about xDSL.

So you may be able to answer my queries then.

I have always seen & expected to see DS RSCorr whenever my connection has been Interleaved.

But, why am I now seeing DS RSCorr on my fastpath connection when I never used to see it (when on fastpath)?

In other words, what is causing it?

Either your ISP enabled RS correction or DLM enabled it. I don't know why.

Is it a fault that I need to report to my ISP?

I would report as fault but I report almost all.

[c6em]

Reed Solomon error correction is as I understood it a separate concept from that of interleaving.
So I believe it would be quite possible to have one and not the other.

We have been quite accustomed on UK ADSL lines to associate them together - though I was always aware that this was not correct - but correcting anyone on the details was going to be a waste of (my) time.
I always hesitated a little before declaring that a line with FEC errors was "obviously interleaved"!

We are into @asbokid territory here and those with a far greater knowledge than me of data communication protocols - which interestingly originate from the early rocket control systems development.

So it may be on FTTC lines that RS error correction is being used as a standalone line stabilisation method.....

[Ragnarok]

FEC is more for impulse noise protection, it's a seperate data stream in the carrier used to help the modem reconstruct the main data stream if their are errors. Thats why when you have a max attainable rate in excess of 80000kbps on a new/DLM reset line with a over 6db snr, it's virtually a data stream gone to waste currently unless you run that with FEC. If you have played with a satellite TV feeds, you know the more FEC the more likely you are to get an error free picture at the cost of bandwidth on the carrier.

DLM when it decides it's necessary uses that extra bandwidth to transmit an FEC error correction stream alongside it. once the actual data rate dips below 80mbps ( currently) , it's eating into the available bandwidth.

The best trade off may in fact not be what DLM is doing but to lower the data rate to the point there are insignificant errors with a much higher SNR margin, and adjust upward when FEC/INP is turned down ( as the bandwidth formerly used for FEC is now useable bandwidth )  but stop before the errors are likely to trigger DLM to intervene with FEC again.

Reed solomon coding has been used regularly in the past as part of the FEC in digital broadcasting, it's been surpassed by low density parity checks + BCH class CRC coding, which far more effective while requiring less processing power. if you have any impulse noise protection on your line it's probably using RS, if your lucky without interleaving too!! I'm not sure what INP level introduces FEC.

I do know that the FEC reduced my attainable rate by 10mbps at INP 3 from 93 down to 82 ish before my line got hammered by crosstalk, So the FEC level looks to be around 8/9 or the error correction stream is approximately 1/9th of the total data carrier.

[Bald_Eagle1]

I didn't ever see DS FEC errors on the rare occasions that my connection was on fastpath when using the original HG612 firmware version.

My connection, until recently, was interleaved for all the time I have been using the updated modem firmware version & it is only now that it is on fastpath that I see the DS FEC/RSCorr errors.

So it might be a feature of the updated firmware to use FEC on fastpath connections, particularly for those longer connections that are unable to max out 40 Mbps or 80 Mbps services.

It has taken since October though for my connection to be switched to fastpath.

At almost 18 1/2 days in sync, I think this is the longest my connection has ever operated on fastpath.



My ping times, according to Speedtest.net, now average around 10 ms compared to the up to 23 ms when interleaved.

I'm not an online gamer so that's not all that important to me.
However, it does now feel as though I generally don't have to wait quite as long for pages to update when using t'internet.


I did see ping times of around 5 ms & significantly higher DS sync speed for approximately 1 month when I first had FTTC installed, but I believe I was one of, if not the first to be connected to my cabinet. i.e. well before crosstalk had any effect on my connection.

[kitz]

I did see ping times of around 5 ms

I saw something similar on my first few days of being connected, and Im not first on the cab.  I just assumed that it was the BT speedtester having flipped, as I couldnt see how it could be that quick from 'oop norf', when my ISP gateway is in London, despite the BT speedtester being located (or used to be) on the Manchester RAS. 
Mine now averages about 15/16ms to Maidenhead..  which is about the equivalent to the best I got when on Be*

[NewtronStar]

I did see ping times of around 5 ms

I saw something similar on my first few days of being connected, and Im not first on the cab.  I just assumed that it was the BT speedtester having flipped, as I couldnt see how it could be that quick from 'oop norf', when my ISP gateway is in London, despite the BT speedtester being located (or used to be) on the Manchester RAS. 
Mine now averages about 15/16ms to Maidenhead..  which is about the equivalent to the best I got when on Be*

Those are nice Pings both of you, all I get is 47ms from the Douglas gateway and I am an online gamer and the games work fine, would rather have higher thoughput than lower pings anyday 

[Bald_Eagle1]

London:-



Manchester:-




I'm actually around 7 miles from Manchester & 200 miles from London 

I've attached one of my best speed tests - Ah. Memories.................

[kitz]

London 16 ms



Manchester 22ms



Im about 55 miles from Manchester & 250 from London.


Once upon a time when I was on the RIN test platform for PN, you could see the hops on the BT backhaul.  Hop 8 is Manchester accessing the UK core network.

Code: [Select]

  1     1 ms     1 ms     1 ms  192.168.7.100
  2     9 ms     9 ms    10 ms  217.47.204.58
  3     8 ms     9 ms     8 ms  217.47.251.161
  4     9 ms     8 ms     9 ms  217.41.173.13
  5     9 ms     8 ms     8 ms  217.41.173.118
  6     9 ms     9 ms     8 ms  217.41.173.62
  7     9 ms     8 ms     7 ms  217.47.109.242
  8     8 ms     8 ms     8 ms  londonc-access3-s26.ukcore.bt.net [194.72.2.181]
  9    14 ms    17 ms    13 ms  core1-pos4-0.ealing.ukcore.bt.net [62.6.204.193]
 10    13 ms    13 ms    13 ms  transit1-pos5-0.ealing.ukcore.bt.net [194.72.17.122]
 11    13 ms    13 ms    12 ms  t2c1-p1-0.uk-eal.eu.bt.net [166.49.168.13]
 12    15 ms    14 ms    13 ms  t2c2-p1-0.uk-lon1.eu.bt.net [166.49.208.210]
 13    14 ms    14 ms    14 ms  t2a1-ge7-0-0.uk-lon1.eu.bt.net [166.49.135.110]
 14    14 ms    14 ms    14 ms  ge-1.linx.londen03.uk.bb.verio.net [195.66.226.138]
 15     *        *       20 ms  xe-3-1.r01.londen03.uk.bb.gin.ntt.net [129.250.2.46]
 16    14 ms    14 ms    14 ms  vlan814.ge6.br2.rbl-mer.misp.co.uk [213.130.48.34]
 17    14 ms    14 ms    14 ms  thermalthree.footholds.net [195.62.28.240]

[Chrysalis]

On openreach based FTTC, its common to have FEC enabled on US on fast path, I have it on mine also, dont worry about it.

Kitz thanks for remind me how bad BT's routing is from the east midlands.

100 miles from london.

Yet on fast path 14ms to bbc. (on plusnet's lowest latency gw, can be as high as 19ms on the worst)

On easynet (ukonline) was 9ms, as was a direct route.

When the BTw fault was raised at plusnet a short while back the derby to liverpool link was congested, that is north of me and away from the direction of london, yet my traffic to london goes over that link.

BE you dont have to wait as long for pages to load because they loading quicker   Latency is a key variable in performance.  RTT is very important.