Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: burakkucat on March 06, 2017, 11:48:33 PM
-
I've been monitoring the circuit since it was migrated from VF back to EE and have been waiting for G.998.4 (a.k.a. G.Inp) to be re-applied.
Something happened this evening . . . :ouch:
-
Very odd. I would expect the SNRM dropping to cause the increase in ES, his has shot up though. I have no idea as to what could have happened.
I would be performing a resync at the earliest opportunity if that were my line.
Do let us know if you know what happened N'Star.
-
Whatever it was, it seems to have returned to normal at midnight.
-
Twas a battle against the crosstalker and for some reason two retrains on the 6th 14:24 started the roller coaster ride and a retrain came in this morning 8:am with more interleaving as was expected due to errored seconds going above 2880
Just thinking maybe EE is on the DLM Speed Profile same as the other BT family Plusnet & EE
-
Just thinking maybe EE is on the DLM Speed Profile same as the other BT family Plusnet & EE
Yes, it is looking that way.
There has now been two resynchronisation events, so far, today. One at 8030 hours (RDI) and the second at 1901 hours (MIS).
-
It's now got G.Inp enabled. :thumbs:
-
That's the 2nd time G.INP has been enabled in the past 2 months and both came in on the 11th day after ISP activation date.
-
Lucky you. I'm over 5 weeks in and still on fastpath. That's despite smashing the ES threshold over and over. DLM appears to be ignoring my line.
-
indeed john have you as my second pane on MDWS and also waiting for something to happen you would have thought interleaving would have been applied by now but no it's like a stuck DLM.
This is a new Huawei cabinet you where moved to yes ?
-
Yes he's on a new Huawei having got off an ECI
-
The curse of leaving his ECI cabinet..
;);) :lol:
-
Yes he's on a new Huawei having got off an ECI
Just wondering if his Cabinet has had the firmware upgraded for G.INP if you remember way back 2015 Kitz said ->
http://forum.kitz.co.uk/index.php/topic,15283.msg284195.html#post_updates (http://forum.kitz.co.uk/index.php/topic,15283.msg284195.html#post_updates)
Stage One - Update DSLAMs in the cabinet.
Involves 5-10 minutes downtime during the wee small hours whilst configuration changes are made to the DSLAMs in the fttc cabinets.
14th Jan Some users start to report small over-night outages.
Stage Two - G.INP & DLM profile applied to line.
Rollout at a rate of 45,000 lines per day†
Feb - Users on Huawei cabs start to see G.INP appear in their line stats.
Mar - ECI cab in Martlesham Heath G.INP live†
-
Don't think this old circuit is performing like it used to having seen when the SNRM goes to it's lowest point of the day it then becomes erratic with a retrain, the image with my blue arrows shows those events clearly.
-
Now that G.998.4 (a.k.a. G.Fast) has been enabled, I suspect that the circuit may need a day or two to "settle down". :-\
In terms of the "traffic lights", everything is now green. A distinct improvement when compared with the last few weeks.
-
Hmm settle down if only have plumbers heating engineers coming in on Monday to remove & replace 21 year old oil tank and oil burner & radiators also to make the open fire back boiler safe but if they take the heating fuse out that should not interfere with are normal wall socket circuit :fingers:
-
Just wondering if his Cabinet has had the firmware upgraded for G.INP
No idea. brand new cabinet so you would hope so.
DSLAM/MSAN type: BDCM:0xa48c / v0xa48c
Is that what everyone else has?
The curse of leaving his ECI cabinet..
;);) :lol:
looks like it lol. i was looking forward to G.INP but at least it's not stuck on interleaving.
-
That's the same DSLAM firmware as I have, and I've had G.Inp enabled for many months.
-
The maximum duration for G.INP to be enable that i've seen in these forums was 7 weeks, TBH I can't ever remember seeing a line being stuck on fastpath before the DLM is normally very quick to act in cases like yours.
John you started off manually capping you sync from the start just thinking if that had anything to do with it :-\
-
Thinking back to the tail-end of last year, it was late November when the DP "block and tail" was replaced. All seventeen subscribers connected via that DP then had good circuits. However there was not that much time to get a "feel" for your circuit with the EE service, as Christmas was fast approaching (flashing lights, etc) and then you migrated to Vodafone. :-X
Now back with EE, it does seem as if the circuit is allowed to synchronise when the DS SNRM is at its minimum (the Radio China International, Radio Romania, etc, effect) such that the DS SNRM remains above 6 dB for the entire 24 hour period, then it is very stable. With just one and a half hours to go before today becomes tomorrow, I see that the circuit has 18 ES DS, 3 ES US and 0 Retrains.
On thing I have noticed (but cannot explain) is the occasional "blip" in the SNRM traces. For the higher of the two traces the blip goes upwards and for the lower of the two traces the blip goes downwards. Perhaps it is something that WWWombat may be able to explain . . . :-\
-
#Decloak :paperbag:
On thing I have noticed (but cannot explain) is the occasional "blip" in the SNRM traces. For the higher of the two traces the blip goes upwards and for the lower of the two traces the blip goes downwards. Perhaps it is something that WWWombat may be able to explain . . . :-\
Not exactly, sorry. Just add more mystery ...
When I zoom into MDWS, down to a couple of hours, I see that the upstream & downstream blips are actually separated by a minute. When one direction blips, the other is normal.
Looking at upstream alone, but looking at the 3 bands, you can see that U0 and U2 both are at low levels, but those levels are encountered regularly ... but just "chance" that both are low at the same time in this minute. U1, however, seems to take an irregular dip. The cumulative effect shows up.
Downstream alone shows a blip for both D1 and D2. Interestingly, there is a similar blip around 40 minutes earlier that isn't visible on the aggregate SNRM chart.
It makes me wonder just how volatile the line is ... and how it appears when sampled very frequently instead of once per minute.
-
Thank you for the analysis and your observations.
I'm prepared to just regard the blips as "one of those things".
-
Thanks WWWombat it's been ages since we last conversed could run DSLstats on the PC at 15 second intervals and see how it looks.
Burakkucat when I was with Vodafone they sent two engineers out which found no fault the second engineer did replace the NTE/A & SSFP MK3 to a NTE5C & SSFP MK4 and a DLM reset, if I remember correctly the MK2 had issues when the SNRM went below 4.5dB and then a retrain occurred it seemed the MK3 was more tolerant.
Just wondering if this MK4 is also impeding the SNRM level swing like the SSFP MK2 it's a just a theory and not much evidence just have to keep the DS SNRM from going below 5dB ;)
-
could run DSLstats on the PC at 15 second intervals and see how it looks
Depending on how fast your system is, you might be able to run it at 5 second intervals. You won't be able to upload to MDWS while this is happening though.
-
Depending on how fast your system is, you might be able to run it at 5 second intervals. You won't be able to upload to MDWS while this is happening though.
I understand the RPI is gathering the stats for MDWS at 1 minute intervals but can run DSLstats on the PC at the same time at a lower interval the 8800NL is happy with multiple telnet access's
-
That's true.
-
It might be worthwhile as a sanity check.
My gut feel is that if the line was really volatile, it would show up as varying results even at minute intervals. Which we don't see.
But this reminds me of something to be cautious of...
I'm not fully up-to-speed with Nstar's monitoring setup, but I recall one case of mixed monitoring where (IIRC) running DSLStats at 1 minute intervals caused a noticeable dip in SNRM as measured by RouterStatsLite at 5 second intervals.... Yes: one reading in 12 on RSL was 0.5dB lower than the other 11, and coincided with the timestamp of the DSLstats operation.
It wasn't at all obvious why.
-
I'm not fully up-to-speed with Nstar's monitoring setup, . . .
A R-Pi, connected to a Billion 8800NL and running DSLstats. The latter is responsible for the upload to MDWS.