Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: Bald_Eagle1 on May 11, 2014, 09:10:44 AM
-
My connection was unexpectedly put back on fastpath some 15 days ago.
We have occasionally seen low US FEC/RSCorr error counts when on fastpath, but I haven't previously seen DS FEC/RSCorr errors when on fastpath.
Compared to counts prior to being put back on fastpath, these DS errors are miniscule.
DS CRC errors are also unexpectedly now lower, but DS ES are expectedly higher.
Has anyone else seen this?
It may be a feature of the HG612's updated firmware as the last time my connection (briefly) ran on fastpath, DS FEC/RSCorr errors were completely zero.
-
No not seen it. Running the latest firmware in the Hg612 FEC were all zero on fast path. Just been made interleaved and I am trying to puzzle out what levels of FEC/min are reasonable. After looking at CRC/min on fast path the numbers seem huge. Given previous values of CRC I am trying to understand why so many FEC occur, I notice that others seem to have these large values.
-
RS-Coding is possible also on fast path. Check R parameter in "adsl info --stats".
Best regards
konrado5
-
Running the latest firmware in the Hg612 FEC were all zero on fast path. Just been made interleaved and I am trying to puzzle out what levels of FEC/min are reasonable
when on interleaved you don't want to see FEC's going above the 50K mark to often and if you hit 850K (burst errors) then its hello DLM thanks for increased Interleaving, so FEC's should be no more than 18K.
-
Compared to counts prior to being put back on fastpath, these DS errors are miniscule.
DS CRC errors are also unexpectedly now lower, but DS ES are expectedly higher.
You will find once you get close to the max DS (Bearer) your line can handle you will find the DS ES will rise for me it's 30000Kbps if the Bearer is 28700Kbps I don't get any DS ES errors ;)
-
Cheers NS.
Yep, I've seen that on quite a number of connections that can't achieve 40 Mbps DS.
I'm currently in sync at slightly higher speeds than Attainable Rates, with DS SNRM peaking at 5.9dB at 2 pm.
At its lowest it is 5.4dB at 10 pm (which in my rational mind is nowhere enough fluctuation to bother about):-
From 2pm today:-
Max: Upstream rate = 4483 Kbps, Downstream rate = 21744 Kbps
Bearer: 0, Upstream rate = 4516 Kbps, Downstream rate = 22271 Kbps
From 10 pm last night:-
Max: Upstream rate = 4465 Kbps, Downstream rate = 20980 Kbps
Bearer: 0, Upstream rate = 4516 Kbps, Downstream rate = 22271 Kbps
R values are 14 DS & 12 US
Inp & delay values are zero for DS & US
My query was really about DS FEC/RSCorr errors though.
Your connection fairly often switches between fastpath & Interleaved doesn't it?
Do you ever see DS FEC/RSCorr errors when on fastpath?
-
R values are 14 DS & 12 US
Inp & delay values are zero for DS & US
You have got RS without interleaving.
Best regards
konrado5
-
You have got RS without interleaving.
Are you able to explain why?
-
R above 0 indicates "RS coding". FEC/RSCorr errors also indicates RS coding.
-
This also tells me:-
RS: 3459524930 3716447
RSCorr: 1314215 336
RSUnCorr: 214657 0
What I'd like to know is WHY have I got RS without interleaving?
Also, why have I now got it on DS when I have never seen it on DS before when on fastpatch?
-
Max: Upstream rate = 4465 Kbps, Downstream rate = 20980 Kbps
Bearer: 0, Upstream rate = 4516 Kbps, Downstream rate = 22271 Kbps
This has to one of those trick questions BE1
Your Max Attainable is higher than the Bearer on the DS would normally see this on the US never DS on my line, I can't see this as down to you being on Fastpath there seems to be something amiss :-\
the answers is your not on FastPath something in the stats is fooling you :D
-
Max: Upstream rate = 4465 Kbps, Downstream rate = 20980 Kbps
Bearer: 0, Upstream rate = 4516 Kbps, Downstream rate = 22271 Kbps
This has to one of those trick questions BE1
Your Max Attainable is higher than the Bearer on the DS would normally see this on the US never DS on my line, I can't see this as down to you being on Fastpath there seems to be something amiss :-\
But the Max Attainable isn't higher than the Bearer.
Bearer is almost 2 Mbps higher than Attainable in that example.
I've seen that quite a few times on various other users' connections.
I've also seen a low amount of US FEC errors on fastpath connections, but I've never previously seen DS FEC errors on a fastpath VDSL2 connection.
I can only assume that SNRM was higher when my connection resynced some 16 1/2 days ago.
EDIT:-
In fact, here are some of the stats from that resync:-
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 4516 Kbps, Downstream rate = 22160 Kbps
Bearer: 0, Upstream rate = 4516 Kbps, Downstream rate = 22271 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.2 6.2
Attn(dB): 24.6 0.0
Pwr(dBm): 12.6 6.9
The connection had been up for 34 seconds by the time the resync data was obtained at 07:25:11, 26th April.
-
It may be pure coincidence, but I have just started remotely monitoring a connection that is a long way from the cabinet.
I only have a few hours worth of data, but I am seeing the same phenomenon i.e. DS FEC/RSCorr errors on a fastpath connection.
Both modems have the October firmware updates.
I wonder if this could be a feature of the updated firmware i.e. to introduce DS FEC/RSCorr on some fastpath connections that would otherwise see massive CRC errors & even more DS Errored Seconds, no doubt kicking DLM into aggressive action
Mine is connected to a Huawei DSLAM & the other is connected to an ECI DSLAM.
The snapshot & ongoing montages for the other connection are attached if anyone feels able to comment
-
Isnt this supposed to be what PhyR is all about.
Error Correction on the fly and doesnt need interleaving to be applied?
I think it was discussed in another thread.
-
Thanks Kitz.
I'll have a look for that thread & generally read up on PhyR.
As we are not previously aware of this phenomenon on DS (i.e. via the original HG612 firmware version), it may well be one of the enhancements introduced with the October updated firmware.
As you are aware, the updated version also includes revised band plans, increased bitswapping & different (perhaps more realistic???) reporting of Signal Attenuation etc.
The updated version does definitely appear to have improved speeds slightly & increased stability for some longer connections (regardless of the make of DSLAM).
-
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.
-
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.
-
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.
-
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
-
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?
-
@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.
-
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.
-
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.....
-
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.
-
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.
-
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*
-
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 ;)
-
London:-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F3501124768.png&hash=fe1289f0064252699c7cf9cd7f524cec8b3fa721) (http://www.speedtest.net/my-result/3501124768)
Manchester:-
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F3501128768.png&hash=e66295dab9e3c5f37a73d0e18791a93a5a437a72) (http://www.speedtest.net/my-result/3501128768)
I'm actually around 7 miles from Manchester & 200 miles from London ;D
I've attached one of my best speed tests - Ah. Memories.................
-
London 16 ms
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F3501263302.png&hash=0d2884f0a82898ddb927914d4789a8c290dafa9e) (http://www.speedtest.net/my-result/3501263302)
Manchester 22ms
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.speedtest.net%2Fresult%2F3501265315.png&hash=61000290847f663adbe28b3d3cfa9e197da04553) (http://www.speedtest.net/my-result/3501265315)
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.
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]
-
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.
-
Kitz thanks for remind me how bad BT's routing is from the east midlands.
A lot of it will depend how far you are from the RAS and core-nodes.
As you can see from the trace I posted above, it took me 8ms to traverse 55 miles to Manchester, yet once I was on the core it only took 5 seconds to get from Manchester to Ealing, London which is circa 200 miles... so you can see how much better the core is than the backhauls.
21CN has more core node access points (http://www.kitz.co.uk/adsl/21cn_nodes.htm) than the old 20CN network, so it depends just how far east you are, but I thought the midlands was one of the areas were access was supposedly improved as new PoPs were introduced :/
-
Keep thumping the ground the worm will surface.
-
BE1... is it worth posting your full stats? For thread history, if nothing else, perhaps? :)
As an aside, I've seen 9ms on ADSL2+ PTM/fastpath which I thought was only possible on FTTC prior!
Capping tones to negate INP sounds like a brilliant idea, too, fairplay! A 5ms ping would be epic! Who cares if usable bandwidth is cut in half :D
-
Who cares if usable bandwidth is cut in half :D
The Kitz forum may be over run with posts with "I think my line is capped" :o
-
Ive seen a few 7ms on the old 20CN, but they were all from the London area.
-
Unfortunately my connection resynced a couple of days ago & I'm now interleaved again with lower DS sync speed:-
http://forum.kitz.co.uk/index.php?topic=13934.msg262948#msg262948
-
Kitz thanks for remind me how bad BT's routing is from the east midlands.
A lot of it will depend how far you are from the RAS and core-nodes.
As you can see from the trace I posted above, it took me 8ms to traverse 55 miles to Manchester, yet once I was on the core it only took 5 seconds to get from Manchester to Ealing, London which is circa 200 miles... so you can see how much better the core is than the backhauls.
21CN has more core node access points (http://www.kitz.co.uk/adsl/21cn_nodes.htm) than the old 20CN network, so it depends just how far east you are, but I thought the midlands was one of the areas were access was supposedly improved as new PoPs were introduced :/
There is one new POP which I am not been routed through.
I think the southern east midlands is pretty bad for BTw routing.
BT need some POP's between Leicester and London.
-
:(
No worries.
It sounds as if some of us are on 'joking fastpath' anyway. I wonder if it might be possible to use the two latency paths l keep hearing about?
I reckon I could get by on 256Kb/s of pure fastpath goodness. DLM could interleave/RS/INP/FEC the arse out of the remaining 39Mb~.
I wonder how I'd get my gaming traffic to use this slice of fastpath? Win 7 can set DSCP on a per application basis.
I wonder if any of this is doable. There must be a few low end tones that could be considered globally fastpathable? Every profile could be a gamer-compatible profile!
-
Yeah, actual speed is dependent on both RTT and capacity of the line. A higher sync speed doesnt mean will get higher speeds from any specific location.
e.g. if my line synced at say 50mbit on a interleaved profile, I would downgrade to 40/10 to get extra snrm and get the line back to fast path, to me 40mbit fast path beats 50mbit interleaved.
-
I came across a graph t'other day that showed the effect of INP on bandwidth and latency. The added latency is annoying to me personally but if the graphs were to be believed, it has a HUGE effect on actual throughput.
Struggling to see the point of INP permanently applied to a line for a noise burst that happens once or twice a day for 500 micro seconds.
I did see some other stuff about 'coding gain' (not related to INP but to RS or interleaving IIRC) but that went over my head tbh. My takeaway from it was that there can be some additional throughput in some scenarios due to better bitloading (or should that be bitwangling? :D) but it was a bit much for me to understand so that might well be wrong!
-
In reality is probably no point but the issue I guess from openreach side is what if the user is watching netflix at that moment and that short error burst is enough to disrupt it? It may reduce support callouts by a few % and for their eyes may justify it.
I can understand it if the line is unstable for large chunks of the day and its turned on right away when needed, but I think its silly if a line has a short burst of noise, then interleaving is turned on 12 hours later for no reason.