Kitz Forum
Broadband Related => Broadband Technology => Topic started by: tommy45 on May 31, 2015, 02:52:37 AM
-
//* Note from Admin - Ive split off the Mk2 G.INP line stats to form its own thread away from the main topic. *//
Well going by my stats I just had the so called G.inp rollout fix, G.inp was switched off on my upstream for some reason, my stats show a slight gain in DS attainable, SNR is no higher than it has been whilst fully g.inped US SNR back to the higher level but surprisingly the us attainable is slightly lower ???? it should have increased!!! I guess this is going to pee some off as they may lose full us sync speed the inp value increased on the ds by 1 to 48 and us power increased a little as did the signal & line attenuation levels,why?
-
@tommy45,
Would you mind posting a copy of your xlogfile.txt?
(it should be in the same folder as modem_stats.log)
Going on the initial G.INP rollout, it's likely to be a while before my Huawei DSLAM is updated & I'm trying to put something together to email users when the changes take place.
As it hasn't happened on my connection yet, I'm not 100% sure what data to use for determining the changes.
I was going to use the previously unused blat.exe email program that is already stored in the Apps folder, but it doesn't work with Gmail users.
I have found a different program, mailsend.exe that seems to work for all connections, even those using ipv6, but it's taking me a while to amend the code that I had tested using blat.exe.
-
tommy can you be kind enough to do a screenshot of modem stats gui? or post a montage, thanks.
I noticed on various forums is some discussion about US error correction been left on by openreach on the fixed profiles, its worth pointing out its always been enabled anyway even on fast path.
See here, I have US FEC's.
-
Here you go
It looks from MDWS there are several others that have also had this cack handed attempt of a fix applied where it wasn't needed i use a huawei , So that may blow the theory about the DSLAM being able see what brand of chip the modem is using and apply the profile accordingly, they would appear to have blundered yet again and rolled it out to all regardless wrong again BTOR As my us does generate errors when fast path my concern is ending up with the borked ECI profile interleave on the us when G.inp on both did it's job as it was supposed to do,
Maybe people power will get BT to listen to what it's customers what, a petition so the customer gets control via isp of how their connection is set up, because it's clear bt don't have any clue "opt out of DLM"
I haven't rebooted the modem to clear all the errors from before the change, and as a result of the change
Also due to the dlm action and modem re syncing very quickly it's difficult to say if my BTW IP profile has changed, as it still shows 77.35 but it would if it hadn't been updated, as i have encountered before,following DLM action, i have had to power off the modem wait a short time and power it back on again ,to get the BTW ip profile to update,
I noticed that the Zen radius servers detected the re sync, where as in the past plusnets often did not as you would be on the same Gateway, and router had nothing in its log to say it lost pppoe session due to not getting a response for 6 seconds
-
It does seem like the fix was just to turn off G.INP on the upstream the evidence looks like it's swinging in that direction tommy45 :(
-
It does seem like the fix was just to turn off G.INP on the upstream the evidence looks like it's swinging in that direction tommy45 :(
But why does it reduce the upstream attainable which in some cases will result in loss of some actual sync speed on the US ? it would seem to do this by ramping up the US signal and line attenuation levels somehow, though this doesn't impact the US SNR levels, IMO they have botched it again as the US attainable should increase not decrease if it is fast path
-
All i know Tommy45 when G.INP was removed from my line the DS and US sync rate dropped and have the Upstream on the so called fastpath profile interleave depth 1 and INP: 0 INPRein:0 and Delay: 0 and still the attainable is lower than it was when i had the MK1 G.INP profile.
-
Also due to the dlm action and modem re syncing very quickly it's difficult to say if my BTW IP profile has changed, as it still shows 77.35 but it would if it hadn't been updated, as i have encountered before,following DLM action, i have had to power off the modem wait a short time and power it back on again ,to get the BTW ip profile to update
Your connection is in sync at 79999 Kbps.
As G.INP is still active on the downstream, your IP Profile should be around 96.69% of sync speed. i.e. approximately 77351 Kbps, rounded to 77.35 Mbps (which is currently being reported).
It would be showing as 77.43 Mbps if G.INP wasn't active.
I noticed that the Zen radius servers detected the re sync, where as in the past plusnets often did not as you would be on the same Gateway, and router had nothing in its log to say it lost pppoe session due to not getting a response for 6 seconds
It could just be that the connection was down long enough due to the changes for it to have also forced a new PPPoE session anyway.
-
It does seem like the fix was just to turn off G.INP on the upstream the evidence looks like it's swinging in that direction tommy45 :(
Or could it be an attempt by OR to "level the playing field" between Huwaei and ECI cabs, if as expected the ECI DSLAMS cannot do upstream G.INP?
-
It does seem like the fix was just to turn off G.INP on the upstream the evidence looks like it's swinging in that direction tommy45 :(
But why does it reduce the upstream attainable which in some cases will result in loss of some actual sync speed on the US ? it would seem to do this by ramping up the US signal and line attenuation levels somehow, though this doesn't impact the US SNR levels, IMO they have botched it again as the US attainable should increase not decrease if it is fast path
I'd noticed some oddities with the upstream before they even did the fixes. If you look at both of these cases where the EU's fixed the situation themselves by getting BCM bases modem/routers. Both of them lost some of their upstream and never quite got back to the 18.5Mbps speed test figures again. These aren't isolated incidents.
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fwww.kitz.co.uk%2Fadsl%2Fimages%2FGINP_stats.png&hash=42f37c67406e82c0b3820641c5198d99c0a7bd31)
-
It does seem like the fix was just to turn off G.INP on the upstream the evidence looks like it's swinging in that direction tommy45 :(
Or could it be an attempt by OR to "level the playing field" between Huwaei and ECI cabs, if as expected the ECI DSLAMS cannot do upstream G.INP?
Yep, lowest common denominator wins.
-
So then a clear case of we have borked things for eci eu's lets bork it for everyone else too,? Instead of doing what they should have done found a solution that fixed their mess,I hope Mr kennard gives them both barrels for their
ineptness
If they don't know what they are doing then they should seek the advice from a company that does, roll on the day that the EU gets are choice of who supplies /controls their bb product, I'm dreading them rolling out vectoring or G .fast what mess will they make of the deployment of that
-
Your connection is in sync at 79999 Kbps.
As G.INP is still active on the downstream, your IP Profile should be around 96.69% of sync speed. i.e. approximately 77351 Kbps, rounded to 77.35 Mbps (which is currently being reported).
It would be showing as 77.43 Mbps if G.INP wasn't active.
Yes the BTW IP profile used to be 77.43 if using this Huawei modem and 77.44 when using the ECI modem for some reason, when on fast path
-
So then a clear case of we have borked things for eci eu's lets bork it for everyone else too,? Instead of doing what they should have done found a solution that fixed their mess,I hope Mr
I see this more as a compromise that BTOR had to make for all end-users CPE from ECI HH5A and other FTTC modems where the modem can't do G.INP on the upstream and yes it's annoying when you know your modem can do both G.INP US and DS but after a while we will just get used to it as being the norm.
Sorry i forgot to ask Tommy45 which FTTC modem they are using at the moment.
-
That's where the problem lies and why BT don't really give a p00 about me or you or any other end user, we are just a cash cow who is always happy to pay so matter what they do , About time that ended
-
How do you know that G.INP on ECI cabs is any good at all?
If it's as poor as claimed, there may be further compromises needed to be added to Huawei cabs.
-
It is a shame the DSLAM's can't figure out the maximum that each connected modem/router can use, and just let them use it!
-
It is a shame the DSLAM's can't figure out the maximum that each connected modem/router can use, and just let them use it!
Yes it is underzone it's kind of like having a Quad core processor then find the OS is only able to use 2 out of 4 cores.
-
Sorry i forgot to ask Tommy45 which FTTC modem they are using at the moment.
The HG Huawei HG612 3B modem , in use since G.inp was first rolled out back in March, and has an uptime of iirc 54days not that that means jack to these fools,
-
Well i just noticed that my SNR has suddenly plummeted to below 6 db and lotts of FECS BT you fix has broken my connection you muppets!!!""!!!!!!!!
-
I presume that I have just had the update applied to my Huawei cabinet here in Bath, lost over 10Mb, might recovered a bit, interleave has gone from 8 down to 4.
Stats recorded 02 Jun 2015 07:59:18
DSLAM/MSAN type: BDCM:0xa44f / v0xa44f
Modem/router firmware: AnnexA version - A2pv6C038m.d24j
DSL mode: VDSL2 Profile 17a
Status: Showtime
Uptime: 6 hours 52 min 59 sec
Resyncs: 0 (since 02 Jun 2015 07:57:45)
Downstream Upstream
Line attenuation (dB): 20.1 0.0
Signal attenuation (dB): Not available on VDSL2
Connection speed (kbps): 31370 4999
SNR margin (dB): 12.4 9.9
Power (dBm): 13.5 5.3
Interleave depth: 4 4
INP: 51.00 55.00
G.INP: Enabled
RSCorr/RS (%): 0.0966 62.5924
RSUnCorr/RS (%): 0.0000 0.0000
ES/hour: 234 130
[Edit by admin: I've put code tags round your stats to improve the formatting]
Thanks, still half asleep. :)
-
I presume that I have just had the update applied to my Huawei cabinet here in Bath, lost over 10Mb, might recovered a bit, interleave has gone from 8 down to 4.
Ive just tried to compare your before and after stats, have you only just started using MDWS?
-
But why does it reduce the upstream attainable which in some cases will result in loss of some actual sync speed on the US ? it would seem to do this by ramping up the US signal and line attenuation levels somehow, though this doesn't impact the US SNR levels, IMO they have botched it again as the US attainable should increase not decrease if it is fast path
Because as mentioned previously the fix appears to be turning off interleaving, but applying Error correction? - See update (http://forum.kitz.co.uk/index.php/topic,15283.msg288188.html#msg288188) and further explanation (http://forum.kitz.co.uk/index.php/topic,15283.msg288270.html#msg288270)
We really must now differentiate between interleaving and error correction. Interleaving causes delay. Error correction causes overheads and reduced sync speed. The two are totally independent of each other and we can no longer assume that because Interleaving is switched off that there isnt any error correction.
-
Well going by my stats I just had the so called G.inp rollout fix, G.inp was switched off on my upstream for some reason, my stats show a slight gain in DS attainable, SNR is no higher than it has been whilst fully g.inped US SNR back to the higher level but surprisingly the us attainable is slightly lower ???? it should have increased!!! I guess this is going to pee some off as they may lose full us sync speed the inp value increased on the ds by 1 to 48 and us power increased a little as did the signal & line attenuation levels,why?
Sorry I missed a couple of these what may be important posts in the midst of some others which Ive now split off. It is indeed beginning to look like the 'fix' may be a one solution fits all scenario. :(
Previously g.inp worked or if a non g.inp modem was identified it got stupid latency and an extremely high level of Error Correction which caused massive overheads. Now theyve tweaked something on the upstream that appears to have removed upstream G.INP for all, removed any interleaving but applied Error Correction. I'd already suspected a couple of weeks ago that this would perhaps be the case (http://forum.kitz.co.uk/index.php/topic,15283.msg288188.html#msg288188).
I'd seen on the likes of the BTcommunity forums that people were cheering because they had their latency back and the one thing that Ive been harping on about for a few weeks that they didnt appear to have received the return of any lost sync speed :-\
I bet Openreach are amused that the likes of Homehub users are praising their fix which is a bodge, but just wait until it hits the mainstream users who have more than half a clue if it does affect all. :no:
I was really hoping that it wasn't going to be a one solution fits all, but we shall see if things do stabilise after a few days and wait to see if things do return to normal. We need to see a bit more evidence yet before jumping to conclusions.
Tommy can I see your full stats please. [connection xdsl --stats] I want to look at things like your 'R' value - ie these for both bearers. The easiest way to get them may be from DSLstats > Telnet data > Connection stats.
adsl info --stats
adsl: ADSL driver and PHY status
Status: Showtime
Last Retrain Reason: 0
Last initialization procedure status: 0
Max: Upstream rate = 31468 Kbps, Downstream rate = 84772 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
Trellis: U:ON /D:ON
Line Status: No Defect
Training Status: Showtime
Down Up
SNR (dB): 7.0 13.7
Attn(dB): 0.0 0.0
Pwr(dBm): 14.3 6.3
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
Same with KIAB please.
-
I presume that I have just had the update applied to my Huawei cabinet here in Bath, lost over 10Mb, might recovered a bit, interleave has gone from 8 down to 4.
Ive just tried to compare your before and after stats, have you only just started using MDWS?
Sorry Kitz, a over sight by me, all sorted now, just registered. :-[
And here is the info you need
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 7972 Kbps, Downstream rate = 43984 Kbps
Bearer: 0, Upstream rate = 5000 Kbps, Downstream rate = 39999 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 7.2 8.4
Attn(dB): 19.9 0.0
Pwr(dBm): 13.5 4.6
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 81 73
M: 1 1
T: 0 0
R: 8 14
S: 0.0647 0.4662
L: 11120 1510
D: 8 8
I: 90 88
N: 90 88
Q: 8 8
V: 4 5
RxQueue: 136 12
TxQueue: 34 6
G.INP Framing: 18 18
G.INP lookback: 31 6
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 610 110
RS: 565651760 1559523
RSCorr: 297678 101228
RSUnCorr: 0 0
Bearer 1
OHF: 572326 574578
OHFErr: 5 363
RS: 3433588 2298313
RSCorr: 287 1170
RSUnCorr: 8 0
Retransmit Counters
rtx_tx: 12466815 1355735
rtx_c: 9147766 438749
rtx_uc: 8612455 278988
G.INP Counters
LEFTRS: 5807 2831
minEFTR: 40005 4997
errFreeBits: 52963075 278880082
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 706285387 0
Data Cells: 2094391 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 2848 1629
SES: 1667 680
UAS: 918 648
AS: 9193
Bearer 0
INP: 52.00 41.00
INPRein: 1.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 40368.53 5059.32
Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87
Bitswap: 1239/1239 209/209
Total time = 1 days 3 hours 6 min 54 sec
FEC: 155183142 4316779
CRC: 81647 6434
ES: 2848 1629
SES: 1667 680
UAS: 918 648
LOS: 12 64
LOF: 102 64
LOM: 40 0
Latest 15 minutes time = 6 min 54 sec
FEC: 126734 32029
CRC: 170 13
ES: 5 8
SES: 3 5
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 41 29
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 3 hours 6 min 54 sec
FEC: 297749 101843
CRC: 1201 110
ES: 42 44
SES: 23 24
UAS: 34 23
LOS: 1 0
LOF: 10 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 154484369 3976817
CRC: 79914 6156
ES: 2731 1535
SES: 1635 646
UAS: 861 602
LOS: 11 61
LOF: 92 61
LOM: 40 0
Since Link time = 2 hours 33 min 13 sec
FEC: 297678 101228
CRC: 610 110
ES: 31 44
SES: 12 24
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
Both before the botch and after it for easy comparison
-
But why does it reduce the upstream attainable which in some cases will result in loss of some actual sync speed on the US ? it would seem to do this by ramping up the US signal and line attenuation levels somehow, though this doesn't impact the US SNR levels, IMO they have botched it again as the US attainable should increase not decrease if it is fast path
Because as mentioned previously the fix appears to be turning off interleaving, but applying Error correction? - See update (http://forum.kitz.co.uk/index.php/topic,15283.msg288188.html#msg288188) and further explanation (http://forum.kitz.co.uk/index.php/topic,15283.msg288270.html#msg288270)
We really must now differentiate between interleaving and error correction. Interleaving causes delay. Error correction causes overheads and reduced sync speed. The two are totally independent of each other and we can no longer assume that because Interleaving is switched off that there isnt any error correction.
kitz did you miss my post? you seem to have forgotten error correction has always been enabled on US FTTC.
We both have FEC stats on our fast path connections.
Or is it you mean the new error correction is higher than the old default?
Here is the R value on my fast path connection.
R: 0 16
-
But why does it reduce the upstream attainable which in some cases will result in loss of some actual sync speed on the US ? it would seem to do this by ramping up the US signal and line attenuation levels somehow, though this doesn't impact the US SNR levels, IMO they have botched it again as the US attainable should increase not decrease if it is fast path
Because as mentioned previously the fix appears to be turning off interleaving, but applying Error correction? - See update (http://forum.kitz.co.uk/index.php/topic,15283.msg288188.html#msg288188) and further explanation (http://forum.kitz.co.uk/index.php/topic,15283.msg288270.html#msg288270)
We really must now differentiate between interleaving and error correction. Interleaving causes delay. Error correction causes overheads and reduced sync speed. The two are totally independent of each other and we can no longer assume that because Interleaving is switched off that there isnt any error correction.
kitz did you miss my post? you seem to have forgotten error correction has always been enabled on US FTTC.
We both have FEC stats on our fast path connections.
Or is it you mean the new error correction is higher than the old default?
Here is the R value on my fast path connection.
R: 0 16
attached are my stats from when i was fast path again the R value on the upstream is 16
-
yeah so imo tommy, your US is exactly back how it was before on fast path. With D set to 1 and R set to 16.
So openreach did what I told them to do a month ago. Leave US on fast path config.
-
yeah so imo tommy, your US is exactly back how it was before on fast path. With D set to 1 and R set to 16.
So openreach did what I told them to do a month ago. Leave US on fast path config.
If they had done this correctly then, I shouldn't be having issues, and shouldn't have loss some attainable, Something isn't right with this botched profile,They should just offer 2 profiles fully g.inp or fully fast path and have done with it, so then those that have service affecting error rates can buy a modem that is G.inp/ vectoring compatible
I hate to think what mcrea and co will "fix" next
-
What they should have done 'years ago' is look at how other countries were rolling it out and instead of the usual 'we at BT know best' attitude they should have watched and learnt.
So here we are 2015 several years down the road with a botched network made up of equipment from Huawei and ECI that is now out-dated and only part compatible with modern standards.
Way to go BT!!
-
simon but they clever people and know what they doing :)
-
simon but they clever people and know what they doing :)
They just don't seem to learn though ;-)
-
Telling me i have just lost 7mbps off my US attainable for no apparent reason other than the incompetent fools at BT rolling out a fix that actually breaks peoples connections ,and we are talking about connections that worked fine with Fast path or when fully G.inp ed
-
Have you raised this with your ISP?
Surely a huge drop would be deemed a fault especially if you have lost more than 30% line speed (guessing you were 19mbps US).
-
Have you raised this with your ISP?
Surely a huge drop would be deemed a fault especially if you have lost more than 30% line speed (guessing you were 19mbps US).
It was attainable speed , my sync is still 19999 (20mbps) as the attainable is still above now by only 2mbps But the point but never the less it is still of concern it's like i have a malformed circuit in some way thanks to bt's meddling in things they know nothing about I'm also seeing some SES seconds and until this borked fix was rolled out the circuit hadn't generated any since the 18th march 2015,
-
Thanks for the stats guys, Ive not had chance to look at them and wont be able to tonight or tomorrow, but when I get time I'll have a look in detail.
kitz did you miss my post? you seem to have forgotten error correction has always been enabled on US FTTC.
I may have because I missed several posts the other day. I think I replied to one, then it reloaded on the last past with the talk of modems and hence me splitting.
But yes I did know. I think its mentioned in one of my posts further up in the same thread... and this is why I wanted to compare the 'R' value.. which in itself is proof that Openreach has for a while been applying FEC on the upstream. - which we knew anyhow that theyve been doing this for at least 18months now.
What we do have to be really careful about now is stressing the difference between Error Correction (FEC) and Interleaving.. and yes they do appear to have ramped Error Correction up :( We may also have to be careful about the definition of FAST path and Interleaved with depth of 1 even though the result for the EU is practically the same :/
-
yeah so imo tommy, your US is exactly back how it was before on fast path. With D set to 1 and R set to 16.
So openreach did what I told them to do a month ago. Leave US on fast path config.
Having just had a quick look at the R and N values, then yep. Theyve rolled back on the upstream as to how things were before they applied g.inp.
The MSGc value has changed though (Number of bytes in the overhead channel message.) but Im not sure what impact that will have on the line. Theres more overhead than with g.inp, but less than previous :-\
I value (Interleaver block size) is also less and its interesting that its now exactly half of the N value. These are config params so not sure how or if it will make any difference because Interleaving depth is one so effectively non-interleaved. But it certainly looks like theyve been tweaking some parameters so that if interleaving and RS is switched on it will have less impact. WWwombat is best when it comes to working out how much of an impact.
No idea what RRC bits are.
-
>> No idea what RRC bits are.
To help control the retransmission operation, a Retransmission Request Channel (RRC) is
supported in the opposite direction of transmission. The RRC transfers information regarding the status of received DTUs and allows the transmitter to determine the DTUs that are acknowledged as correctly received and those that require retransmission.
So seems ok and expected if g.inp is enabled on the downstream.
-
Had another resync this morning, Interleave has gone from 4 to 8 & now 16. :no:
xdslcmd info --stats
xdslcmd: ADSL driver and PHY status
Status: Showtime
Retrain Reason: 1
Last initialization procedure status: 0
Max: Upstream rate = 8571 Kbps, Downstream rate = 45184 Kbps
Bearer: 0, Upstream rate = 5000 Kbps, Downstream rate = 40000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 8.4 9.1
Attn(dB): 19.8 0.0
Pwr(dBm): 13.4 5.1
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 178 73
M: 1 1
T: 0 0
R: 12 14
S: 0.1424 0.4662
L: 10727 1510
D: 16 8
I: 191 88
N: 191 88
Q: 16 8
V: 2 5
RxQueue: 22 12
TxQueue: 11 6
G.INP Framing: 18 18
G.INP lookback: 11 6
RRC bits: 24 24
Bearer 1
MSGc: 90 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 10.6667 16.0000
L: 24 16
D: 1 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 0 0
RS: 635773008 1719849
RSCorr: 2552 570
RSUnCorr: 0 0
Bearer 1
OHF: 1415097 371995
OHFErr: 0 0
RS: 8490210 1387320
RSCorr: 0 67
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 12625463 1373459
rtx_c: 9192298 444215
rtx_uc: 9673856 295831
G.INP Counters
LEFTRS: 6174 3167
minEFTR: 39991 4997
errFreeBits: 1621406120 291400781
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 1748404193 0
Data Cells: 6031039 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 3234 1901
SES: 1855 769
UAS: 1077 776
AS: 22731
Bearer 0
INP: 47.00 41.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 40055.74 5059.32
Bearer 1
INP: 2.50 4.00
INPRein: 2.50 4.00
delay: 0 0
PER: 16.06 16.06
OR: 47.81 31.87
AgR: 47.81 31.87
Bitswap: 6497/6497 45/45
Total time = 1 days 56 min 23 sec
FEC: 156546764 4666304
CRC: 90405 7656
ES: 3234 1901
SES: 1855 769
UAS: 1077 776
LOS: 14 67
LOF: 117 67
LOM: 43 0
Latest 15 minutes time = 11 min 23 sec
FEC: 49 6
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 50 44
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 56 min 23 sec
FEC: 269 70
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 14502 2907
CRC: 552 0
ES: 10 0
SES: 10 0
UAS: 33 23
LOS: 1 0
LOF: 7 0
LOM: 0 0
Since Link time = 6 hours 18 min 49 sec
FEC: 2552 570
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
#
-
Hmmm.
Maybe as my connection is so slow in the upstream direction it doesn't actually need the updated profile?
Max: Upstream rate = 4951 Kbps, Downstream rate = 21072 Kbps
Bearer: 0, Upstream rate = 5000 Kbps, Downstream rate = 21432 Kbps
(Possibly a slight chance that BT have actually got it right)?
It took a while for G.INP to be activated in the initial rollout, maybe it is also taking a while for the profile change to hit (despite the claims that all connections have been updated)?
Current Bearer 0:-
RxQueue: 18 15
TxQueue: 6 5
G.INP Framing: 18 18
G.INP lookback: 6 5
RRC bits: 24 24
-
Hmmm even more.............
For some unknown reason, my connection has just resynced.
I certainly didn't cause it intentionally as I was in the middle of a VPN session to the server at work.
Hi Bald_Eagle1,
This email is to alert you that the connection resynced at approximately Fri Jun 05 18:49:41 2015
Current Stats Previous Stats
============= ==============
Downstream Sync 21454 Kbps 21432 Kbps
Upstream Sync 3826 Kbps 5000 Kbps
Downstream Attainable Rate 21304 Kbps 20864 Kbps
Upstream Attainable Rate 3879 Kbps 4970 Kbps
Bearer 0 Downstream INP 47.00 47.00
Bearer 0 Upstream INP 41.00 46.00
Bearer 0 Downstream G.INP Framing 18 18
Bearer 0 Downstream Interleaving 8 8
Bearer 0 Upstream Interleaving 2 4
Please see the attached xlogfile.txt file for ALL the current stats.
My US has indeed been clobbered, but G.INP still appears to be active.
It does 'appear' to have been some sort of DLM action:-
05/06/2015 18:50 - RESYNC detected (DS 21454 Kbps, US 3826 Kbps), AS = 23, Retrain Reason: 1)
18:49 does seem a very 'odd' time for DLM to take action.
The xlogfile.txt file referred to is attached for reference.
Perhaps it's a 'fault' as I seem to have completely lost all bitloading from the U0 band (see attached current & ongoing stats montages).
-
Is G.INP likely to help my line?
-
Further to my previous post, also see the combined Bitloading & SNR graph.
I sense another 'epic' thread coming on :lol:
-
BE can I see your stats please (xdslcmd info --stats) for prior to tonight, and also from pre- G.INP MKI.
The figures Im wanting to look at are those starting MSGc - specifically the R and N values
-
The Plink log from 18:00 today - not much before the resync is attached (which includes the stats you requested).
The latest pre-G.INP Plink log is also attached.
-
Further to my previous post, also see the combined Bitloading & SNR graph.
I'm not sure what I am supposed to see (and understand). :-\
-
The Plink log from 18:00 today - not much before the resync is attached (which includes the stats you requested).
The latest pre-G.INP Plink log is also attached.
Eh? ??? Are they attached? :-X
-
Further to my previous post, also see the combined Bitloading & SNR graph.
I'm not sure what I am supposed to see (and understand). :-\
A complete lack of any Bitloading & SNR for U0 band - tones 7 to 32.
Edit:
Looking at the logs, the first tone with ANY bitloading/SNR is actually now tone 53!!!!!!
-
The Plink log from 18:00 today - not much before the resync is attached (which includes the stats you requested).
The latest pre-G.INP Plink log is also attached.
Eh? ??? Are they attached? :-X
They are now (in the original post).
I had to change their extensions to *.TXT from *.log in order to upload them.
-
I'm not sure what I am supposed to see (and understand). :-\
A complete lack of any Bitloading & SNR for U0 band - tones 7 to 32.
Oh . . . :-\ :-X ::)
-
They are now (in the original post).
I had to change their extensions to *.TXT from *.log in order to upload them.
Thank you. :)
-
The Plink log from 18:00 today - not much before the resync is attached (which includes the stats you requested).
The latest pre-G.INP Plink log is also attached.
I am looking at MDWS the US BO INP has decreased and US BO Interleaving has decreased since the retrain reason 1
-
Its weird how G.INP is still there, and not only that, but Error Correction Redundant data has increased from 10->16. Obviously this means more overheads and less available sync speed.
Interleaver block size has gone up to 245 from 141
The RS code word size has increased to 245 from 141
Not sure what the Q value or V value is. Ive only just got back from the vets and need to sort a couple of things but I'll try have a search later and a proper look at the stats.
There were some stats and values further up in the thread, If wwWombat is around he may also be able to throw some light on whats happening.
It really isnt looking too good atm, I dont know if DLM will relent over the next couple of days, but I can only re-iterate what I said after seeing posts on the BT forums cheering in that they were saying it was fixed. Yeah interleaving may have gone but they didnt seem to care about loosing a chunk of their upstream for error correction. I have a horrible syncing feeling [deliberate typo]
-
The pre-cursor to the resync doesn't look too good (FEC/RSCorr, CRC & ES), so maybe it's not actually G.INP profiles related.
-
Also DS SES.
No problems showing for US though :-\
-
BE1 could i ask when the G.INP MK1 was enabled on your cabinet from MDWS it looks like it was on the 23rd of March ?
-
It really isnt looking too good atm, I dont know if DLM will relent over the next couple of days, but I can only re-iterate what I said after seeing posts on the BT forums cheering in that they were saying it was fixed. Yeah interleaving may have gone but they didnt seem to care about loosing a chunk of their upstream for error correction.
I might leave it a day or so before forcing a resync to see what happens.
I have a horrible syncing feeling [deliberate typo]
:lol: :lol: :lol:
-
BE1 could i ask when the G.INP MK1 was enabled on your cabinet from MDWS it looks like it was on the 23rd of March ?
It was indeed 23rd March - at 07:48.
-
BE1 could i ask when the G.INP MK1 was enabled on your cabinet from MDWS it looks like it was on the 23rd of March ?
It was indeed 23rd March - at 07:48.
I don't think your issue is related to the MKII G.INP rollout as when the MK1 G.INP was enabled on my line on the 25th of March if the new rollout continues as it did on the last one we are many weeks away before the DSLAM is updated.
-
Bald_Eagle1, I suspect something is going horribly wrong there. exactly what I don't know. Could be like I had, a flooded cable duct less than 50 meter from my house. Maybe some noisy equipment near you causing havok.
I think another impending problem could be HG612 related for many people, the power regulation caps in the HG612 ( 4 x 1000uf ) are cheep crap Lelon caps, which doesn't bode well for long life in 24/7 usage.
-
The pre-cursor to the resync doesn't look too good (FEC/RSCorr, CRC & ES), so maybe it's not actually G.INP profiles related.
Looking at the full Monty, these are the graphs that struck me, along with the SES one - amongst the traditional graphs.
The downstream retransmission counters go haywire too, with increases visible in the rtx-c counter (the blocks that get retransmitted successfully), the rtx-uc counter (the ones that never get through, despite a number of retransmissions), and the LEFTRS counter that shows when throughput drops to an unacceptable level.
All those suggest your downstream was almost totally borked, which might explain why DLM intervened.
But, at first glance, the only profile changes seem to have been upstream. It isn't immediately obvious why.
I need to look at the files more, but I'm on a tablet at the mo.
-
Looking at the full Monty, these are the graphs that struck me, along with the SES one - amongst the traditional graphs.
The downstream retransmission counters go haywire too, with increases visible in the rtx-c counter (the blocks that get retransmitted successfully), the rtx-uc counter (the ones that never get through, despite a number of retransmissions), and the LEFTRS counter that shows when throughput drops to an unacceptable level.
I imagine those increases were due to the increased ES/SES/CRC counts?
Ragnorak might have a point (i.e. the power regulation caps).
This modem has been connected & active 24/7 since I obtained it from a visiting engineer (but unfortunately, I can't recall exactly when that was - it was quite a while ago though).
-
But, at first glance, the only profile changes seem to have been upstream. It isn't immediately obvious why.
I need to look at the files more, but I'm on a tablet at the mo.
Looking back, I had 'similar' stats data & resyncs 19th & 24th May (both also Retrain Reason 1).
19/05/2015 15:03 - RESYNC detected (DS 21912 Kbps, US 4999 Kbps), AS = 25, Retrain Reason: 1
24/05/2015 18:46 - RESYNC detected (DS 21432 Kbps, US 5000 Kbps), AS = 57, Retrain Reason: 1
05/06/2015 18:50 - RESYNC detected (DS 21454 Kbps, US 3826 Kbps), AS = 23, Retrain Reason: 1
To me, this indicates either a line issue or some really severe interference from somewhere.
(Possibly a modem issue).
-
Apologies to everyone if this actually has nothing to do with the G.INP rollout/profile revision issues.
At this stage, I'm not sure whether it's related or not, but I do now suspect that it is not.
-
No worries BE. I was in the process of splitting off any linestats from the main G.INP thread anyhow :)
Whatever it is, I hope it sorts.
What I find new though is DLM intervention in the late afternoon/evening. This was also experienced with Tommy's line. Its possible that Tommy's line also has some sort of issue :-\
The fact that G.INP is still applied to your upstream would seem to indicate that yours may not be related to the Mk2 g.inp update :/
-
The downstream retransmission counters go haywire too, with increases visible in the rtx-c counter (the blocks that get retransmitted successfully), the rtx-uc counter (the ones that never get through, despite a number of retransmissions), and the LEFTRS counter that shows when throughput drops to an unacceptable level.
I imagine those increases were due to the increased ES/SES/CRC counts?
I'm pretty sure they're related too ... but we haven't seen too many stats that have shown how the severity in one measure (eg, the sudden high level of RScorr) maps to severity in others (eg, the rtx_uc accumulating thousands, and LEFTRS changing by 70ish).
I suspect those stats probably give us some really good benchmark figures for future comparison ... so I really must try to save them somewhere.
The downside is that it means your line has probably gone to s***.
-
But, at first glance, the only profile changes seem to have been upstream. It isn't immediately obvious why.
I need to look at the files more, but I'm on a tablet at the mo.
Looking back, I had 'similar' stats data & resyncs 19th & 24th May (both also Retrain Reason 1).
19/05/2015 15:03 - RESYNC detected (DS 21912 Kbps, US 4999 Kbps), AS = 25, Retrain Reason: 1
24/05/2015 18:46 - RESYNC detected (DS 21432 Kbps, US 5000 Kbps), AS = 57, Retrain Reason: 1
05/06/2015 18:50 - RESYNC detected (DS 21454 Kbps, US 3826 Kbps), AS = 23, Retrain Reason: 1
To me, this indicates either a line issue or some really severe interference from somewhere.
(Possibly a modem issue).
I agree that the event on the 24th May around 18:00 looks significant. The 19th appears a little less significant - and looks to be a longer, slower event judging by the LEFTRS graph.
However, that same LEFTRS graph shows another event on the 29th that seems to elude most other graphs (we can see some evidence on the rtx_* graphs) and the 2nd.
What is good is that these events seem to be, with a wide 20-day view, relatively short-lived.
-
Also DS SES.
No problems showing for US though :-\
yeah so an issue started occuring on your line.
However like everyone else to me the US DLM action is baffling.
What was your US sync speed before g.inp was rolled out? is it now lower than that?
-
Pre-G.INP:-
Max: Upstream rate = 4816 Kbps, Downstream rate = 22432 Kbps
Bearer: 0, Upstream rate = 4992 Kbps, Downstream rate = 22399 Kbps
-
so your RS is the same as pre g.inp yet the sync is lower?
-
@BE1
I was looking at the Plink file from just before the resync, which made me realise something I missed yesterday ... The "Bearer 0 US INP" value decreased during yesterday's resync, from 46 to 41, and the Bearer 0 US INPrein" value stayed at zero.
That change strikes me as meaning DLM is de-intervening. It was getting out of the way, not adding more intervention. Just like old-style DLM, the lower values represent less of an intervention.
During the resync, the modems have negotiated larger RS block sizes (245 now, vs 141) for upstream, and slightly less FEC overhead (16/245 now, vs 10/141). The latter especially isn't much of a change, but they have both moved in the direction you'd expect for a lesser amount of intervention.
Although the interleaving depth changed, the delay caused by interleaving didn't change by much: (2 * 245 now, vs 4 * 141). The increase in interleaver block size (which is the same as the RS block size here) offsets the reduction in interleaving depth. I've noticed that this part of the negotiation doesn't always work out so logically - and can sometimes appear very perverse (I wish I had logged data from all my power cuts).
On balance, the resync doesn't look to have been a DLM reaction to anything happening in the upstream. However, the resync does appear to have caused some new upstream parameters to have taken hold ... but they are an improvement. The reason there has been a marked loss of speed must be down to the loss of US0. There is little indication why.
Having now understood this side of things, and having also seen no change to the DLM parameters for downstream, I'm wondering why this resync happened...
And now I don't think DLM triggered it at all.
If you take a look at the xlogfilex that @BE1 uploaded (I couldn't get it on the tablet yesterday), you can see that the 15-minute statistics show 1 LOS and 10 LOF (loss of signal and loss of framing, respectively). These events are the kind of thing that also cause a modem to resync, and they also cause retrain reason 1.
I now suspect the resync was caused by the line conditions that caused all those errors ... which also happened to cause enough LOS and LOF to trigger a resync.
On a separate front ... Did the resync stop all the downstream errors?
-
While looking at @BE1's issue yesterday, my eye caught a couple of earlier issues, so I thought I'd reply to them.
First, @tommy45's changes...
yeah so imo tommy, your US is exactly back how it was before on fast path. With D set to 1 and R set to 16.
So openreach did what I told them to do a month ago. Leave US on fast path config.
Having just had a quick look at the R and N values, then yep. Theyve rolled back on the upstream as to how things were before they applied g.inp.
I agree. It looks very typical of a pre-G.INP setup. with one little proviso that I'll mention later.
The MSGc value has changed though (Number of bytes in the overhead channel message.) but Im not sure what impact that will have on the line. Theres more overhead than with g.inp, but less than previous :-\
I haven't really paid much attention to the changes of these before, but I think the overhead channel is the part that moves into bearer 1 when G.INP is running. As G.INP was turned off upstream, the overhead channel in that direction has moved back into bearer 0. This matches the relative changes seen in MSGc between the two bearers; I have no idea what a "-6" signifies though.
I value (Interleaver block size) is also less and its interesting that its now exactly half of the N value. These are config params so not sure how or if it will make any difference because Interleaving depth is one so effectively non-interleaved. But it certainly looks like theyve been tweaking some parameters so that if interleaving and RS is switched on it will have less impact. WWwombat is best when it comes to working out how much of an impact.
When depth is 1, then the interleaver block size being half the RS block size is a little strange - on the face of it, there is no apparent need for it to be. But I don't think it has any impact on either the FEC overhead amounts or on the interleaving delay.
Note that, as far as I'm aware, the R, D, I and N parameters are all negotiated by the modems independently of DLM. The value negotiated have to achieve the settings that DLM *does* send into the DSLAM (INP, INPrein and delay), but otherwise it is for the modems to negotiate.
No idea what RRC bits are.
RRC = Retransmission Return Channel. It has 12 bits, to which 12 bits of FEC are added, and carries the ACKs and NACKs for the received blocks, telling the transmitter what needs to be re-transmitted.
If re-transmission only happens downstream, then the RRC only needs to exist upstream.
kitz did you miss my post? you seem to have forgotten error correction has always been enabled on US FTTC.
... But yes I did know. I think its mentioned in one of my posts further up in the same thread... and this is why I wanted to compare the 'R' value.. which in itself is proof that Openreach has for a while been applying FEC on the upstream. - which we knew anyhow that theyve been doing this for at least 18months now.
I just wanted to point out that Openreach have had FEC running (without interleaving) on upstream forever. My earliest stats, November 2011, show this effect on an original 40/10 line, though these stats were taken shortly after BT had started to use the 17a profile, but shortly before they started to allow 80/20 profiles.
However, and this is the proviso I mentioned earlier, my impression has largely been that upstream FEC protection has only appeared when it is effectively free - i.e. where the FEC overhead can be applied freely because attainable is higher than the package speed. I know that isn't 100% true, as some places had upstream FEC when their speeds were lower, but "largely".
Obviously FEC is added deliberately alongside interleaving when DLM intervenes properly on the upstream, but that is a different process.
What we do have to be really careful about now is stressing the difference between Error Correction (FEC) and Interleaving.. and yes they do appear to have ramped Error Correction up :( We may also have to be careful about the definition of FAST path and Interleaved with depth of 1 even though the result for the EU is practically the same :/
Yes. VDSL2 has two latency paths: one fastpath, and one interleaved path. However, the interleaved path can be configured with a depth of 1, making it acts the same as the fastpath, even though it isn't actually the fastpath.
Unfortunately, some people read D=1 to mean fastpath, when it isn't necessarily strictly true.
I recall reading that, with G.INP active, all user data goes down the interleaved latency path - though it might still be configured with D=1.
It was attainable speed , my sync is still 19999 (20mbps) as the attainable is still above now by only 2mbps
Looking at MDWS, that drop of US attainable speed is mysterious. It isn't caused by a resync (or any change of parameters, whether G.INP, FEC or otherwise), and neither is the recovery back to the higher speed. Power remains the same, and the only matching graph is a slight rise in upstream signal attenuation for U1.
I have seen my line do an equivalent jump between US attainable values before now. It was equally mysterious.
I note that an attainable of around 30Mbps seems out of line - far too high - compared with the downstream attainable of 83Mbps. I do wonder about the effects of UPBO on the statistics we see upstream, and whether we only ever get to see an artificial picture.
If I look at the graph of your line over 90 days - from before G.INP started - the US power appears to gradually climb over the entire period. This obviously *ought* to make a difference to the US attainable values over that time, but doesn't. That suggests your noise environment is also changing.
I'm also seeing some SES seconds and until this borked fix was rolled out the circuit hadn't generated any since the 18th march 2015,
As you had G.INP active in the upstream for all of the intervening period, alongside FEC+interleaving combined, your line would have experienced a very different error picture. Errors would have been more likely to be fixed (because interleaving makes FEC more effective); errors that caused a block to fail would have been retransmitted, and likely transmitted successfully. Considerably fewer ES's would have happened and, as a consequence, there's a considerably lower likelihood that ES's would ever get severe enough to be classed as SES's.
-
Thank's for that explanation,But when i look at stats a little further back i see higher attainable rates snr levels and lower power on the us
It also would appear that G.inp hasn't given any increases in attainable rate on the DS , the Snr levels have decreased a little my upstream was higher than it is now when fast path I can see that the power has been at 3.8 before g.inp There where some changes following the last fault that wasn't on the D side but on the E side So why that would affect things i don't know all the engineer did at my house was remove the vdsl filtered face plate and plug in the JDSU
As you say the upstream appears to have the same values as when on fast path ,maybe the lower SNR levels and attainable are due to G.inp being half on,
-
I now suspect the resync was caused by the line conditions that caused all those errors ... which also happened to cause enough LOS and LOF to trigger a resync.
Me too, but I can't think what could have caused it.
On a separate front ... Did the resync stop all the downstream errors?
Yes. 18 hour & 24 hour montages attached.
The xlogfile.txt file is also attached from immediately after I had forced the resync.
I forced a resync today & U0 came back into use, at just a shade lower speed than the usual 4999 Kbps.
Bearer 0 INP remains the same as following last night's resync, but Bearer 0 US Interleaving depth has increased from 2 back to 4:-
Current Stats Previous Stats
============= ==============
Downstream Sync 21496 Kbps 21454 Kbps
Upstream Sync 4951 Kbps 3826 Kbps
Downstream Attainable Rate 21228 Kbps 21304 Kbps
Upstream Attainable Rate 4985 Kbps 3883 Kbps
Bearer 0 Downstream INP 47.00 47.00
Bearer 0 Upstream INP 41.00 41.00
Bearer 0 Downstream G.INP Framing 18 18
Bearer 0 Downstream Interleaving 8 8
Bearer 0 Upstream Interleaving 4 2
Downstream SNRM 6.2dB 6.3dB
Upstream SNRM 5.9dB 5.8dB
-
Although the interleaving depth changed, the delay caused by interleaving didn't change by much: (2 * 245 now, vs 4 * 141). The increase in interleaver block size (which is the same as the RS block size here) offsets the reduction in interleaving depth. I've noticed that this part of the negotiation doesn't always work out so logically - and can sometimes appear very perverse (I wish I had logged data from all my power cuts).
FWIW, I have noticed from a few G.INP active connections that are unable to achieve the full 80/20 sync speeds that when interleave depth (D:) decreases, sync speeds tend to decrease.
This is the complete opposite to non-G.INP connections where sync speeds tend to increase when interleave depth decreases (unless the connection's sync speeds have been banded).
Edit:
On a completely different note, I see you are still using HG612 Modem Stats V 5.0.0.3 23/03/2015
Is there any particular reason as to why you haven't updated to V 5.1.0.0 16/05/2015 yet?
-
I now suspect the resync was caused by the line conditions that caused all those errors ... which also happened to cause enough LOS and LOF to trigger a resync.
Me too, but I can't think what could have caused it.
An operative from M J Quinn or Kelly Communications at the PCP, maybe? :-\
-
As the time of the resync was 18:49, I wouldn't have thought so.
PlusNet did send one of their service status emails earlier in the week to say some BT network maintenance was to be carried out 'overnight' 5th June, but 18:49 seems too early & I don't think it would have caused those types of errors anyway.
-
As the time of the resync was 18:49, I wouldn't have thought so.
Understood.
Chavs or other undesirable elements giving the PCP or fibre cabinet a good kicking? :-X
-
One thing I have learnt from ongoing stats is not to jump the gun until you have observed the stats over a 24 hour period ;)
-
As the time of the resync was 18:49, I wouldn't have thought so.
Understood.
Chavs or other undesirable elements giving the PCP or fibre cabinet a good kicking? :-X
For no apparent reason I lost synch at 5.27pm the same day and I'm with Plusnet
(https://forum.kitz.co.uk/proxy.php?request=http%3A%2F%2Fs29.postimg.org%2Ftp6qflpif%2FUntitled_2_fw.png&hash=7fd8873679df311726f1f62816bf7319135ca8e6) (http://postimage.org/)
I also had my PPOE session terminated for 5 mins some 8 hrs later which probably was Plusnets doing.
Thankfully my line is very stable on the Fritzbox so no harm done.
-
I'll look at the rest later, but for now, this bit is easy...
Edit:
On a completely different note, I see you are still using HG612 Modem Stats V 5.0.0.3 23/03/2015
Is there any particular reason as to why you haven't updated to V 5.1.0.0 16/05/2015 yet?
Because all my access rights/permissions are still mucked up, and I don't want to induce more faults by trying to write updated executables into the folder. When I take delivery of the next circular tuit, I want to start again - complete new folder, complete new permissions etc ... and get back to a vanilla working setup.
-
I'll look at the rest later, but for now, this bit is easy...
Edit:
On a completely different note, I see you are still using HG612 Modem Stats V 5.0.0.3 23/03/2015
Is there any particular reason as to why you haven't updated to V 5.1.0.0 16/05/2015 yet?
Because all my access rights/permissions are still mucked up, and I don't want to induce more faults by trying to write updated executables into the folder. When I take delivery of the next circular tuit, I want to start again - complete new folder, complete new permissions etc ... and get back to a vanilla working setup.
O.K.
Fairy Nuff :)
-
Hi all,
I was wondering if you could possibly shed some light on a question I have.
I had a Netgear D6400 running for 8 days with the following stats:
Max: Upstream rate = 26040 Kbps, Downstream rate = 80441 Kbps
Bearer: 0, Upstream rate = 20000 Kbps, Downstream rate = 74000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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): 7.5 9.7
Attn(dB): 17.5 0.0
Pwr(dBm): 13.6 7.5
VDSL2 framing
Bearer 0
MSGc: -6 -6
B: 174 97
M: 1 1
T: 0 0
R: 8 8
S: 0.0752 0.1554
L: 19456 5457
D: 16 8
I: 183 106
N: 183 106
Q: 16 8
V: 3 2
RxQueue: 42 39
TxQueue: 14 13
G.INP Framing: 18 18
G.INP lookback: 14 13
RRC bits: 24 24
Bearer 1
MSGc: 154 58
B: 0 0
M: 2 2
T: 2 2
R: 16 16
S: 6.4000 16.0000
L: 40 16
D: 3 1
I: 32 32
N: 32 32
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 0
OHFErr: 2 13
RS: 2515510368 2428593
RSCorr: 554115 61355
RSUnCorr: 0 0
Bearer 1
OHF: 43355392 533362
OHFErr: 0 0
RS: 433553307 2301221
RSCorr: 2129 299
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 388043 5110
rtx_c: 19178 17972
rtx_uc: 2 73044
G.INP Counters
LEFTRS: 456 84
minEFTR: 74006 19997
errFreeBits: 785859680 1521542996
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 317187817 0
Data Cells: 325251717 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 2 3
SES: 0 0
UAS: 31 31
AS: 696400
Bearer 0
INP: 49.00 47.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 0.00
OR: 0.01 0.01
AgR: 74132.27 20102.08
Bearer 1
INP: 4.50 4.00
INPRein: 4.50 4.00
delay: 3 0
PER: 16.06 16.06
OR: 79.68 31.87
AgR: 79.68 31.87
Bitswap: 85324/85329 9058/9063
Total time = 8 days 1 hours 27 min 11 sec
FEC: 554115 61355
CRC: 2 13
ES: 2 3
SES: 0 0
UAS: 31 31
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 15 minutes time = 12 min 11 sec
FEC: 65 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 15 minutes time = 15 min 0 sec
FEC: 84 16
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Latest 1 day time = 1 hours 27 min 11 sec
FEC: 1515 92
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Previous 1 day time = 24 hours 0 sec
FEC: 62119 2103
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Since Link time = 8 days 1 hours 26 min 39 sec
FEC: 554115 61355
CRC: 2 13
ES: 2 3
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
#
I've now switched to a Netgear D7000 and have the following stats:
Max: Upstream rate = 16449 Kbps, Downstream rate = 75685 Kbps
Bearer: 0, Upstream rate = 16445 Kbps, Downstream rate = 74000 Kbps
Bearer: 1, Upstream rate = 0 Kbps, Downstream rate = 0 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 5.9
Attn(dB): 17.2 0.0
Pwr(dBm): 13.6 7.6
VDSL2 framing
Bearer 0
MSGc: -6 22
B: 174 237
M: 1 1
T: 0 64
R: 8 16
S: 0.0752 0.4605
L: 19456 4413
D: 16 1
I: 183 127
N: 183 254
Q: 16 0
V: 3 0
RxQueue: 42 0
TxQueue: 14 0
G.INP Framing: 18 0
G.INP lookback: 14 0
RRC bits: 0 24
Bearer 1
MSGc: 154 -6
B: 0 0
M: 2 0
T: 2 0
R: 16 0
S: 6.4000 0.0000
L: 40 0
D: 3 0
I: 32 0
N: 32 0
Q: 0 0
V: 0 0
RxQueue: 0 0
TxQueue: 0 0
G.INP Framing: 0 0
G.INP lookback: 0 0
RRC bits: 0 0
Counters
Bearer 0
OHF: 0 644458
OHFErr: 1 55
RS: 1139730832 2304611
RSCorr: 9942 194
RSUnCorr: 0 0
Bearer 1
OHF: 1340077 0
OHFErr: 0 0
RS: 13400155 0
RSCorr: 0 0
RSUnCorr: 0 0
Retransmit Counters
rtx_tx: 558028 0
rtx_c: 759 0
rtx_uc: 2 0
G.INP Counters
LEFTRS: 12 0
minEFTR: 73983 0
errFreeBits: 24290186 0
Bearer 0
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 3063133807 0
Data Cells: 31261661 0
Drop Cells: 0
Bit Errors: 0 0
Bearer 1
HEC: 0 0
OCD: 0 0
LCD: 0 0
Total Cells: 0 0
Data Cells: 0 0
Drop Cells: 0
Bit Errors: 0 0
ES: 1 44
SES: 0 0
UAS: 35 35
AS: 21525
Bearer 0
INP: 49.00 0.00
INPRein: 0.00 0.00
delay: 0 0
PER: 0.00 7.39
OR: 0.01 30.28
AgR: 74132.27 16475.70
Bearer 1
INP: 4.50 0.00
INPRein: 4.50 0.00
delay: 3 0
PER: 16.06 0.01
OR: 79.68 0.01
AgR: 79.68 0.01
Bitswap: 2180/2262 655/655
Total time = 5 hours 59 min 20 sec
FEC: 9942 194
CRC: 1 55
ES: 1 44
SES: 0 0
UAS: 35 35
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
Latest 15 minutes time = 14 min 20 sec
FEC: 214 5
CRC: 0 1
ES: 0 1
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
Previous 15 minutes time = 15 min 0 sec
FEC: 175 1
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: N/A
Latest 1 day time = 5 hours 59 min 20 sec
FEC: 9942 194
CRC: 1 55
ES: 1 44
SES: 0 0
UAS: 35 35
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
Previous 1 day time = 0 sec
FEC: 0 0
CRC: 0 0
ES: 0 0
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
Since Link time = 5 hours 58 min 45 sec
FEC: 9942 194
CRC: 1 55
ES: 1 44
SES: 0 0
UAS: 0 0
LOS: 0 0
LOF: 0 0
LOM: 0 0
Retr: 0
NTR: mipsCntAtNtr=0 ncoCntAtNtr=0
#
#
It appears that G.INP has been removed from my Upload as what others have noticed.
Would this be the reason for the drop in max attainable for the upload?