Kitz Forum
Broadband Related => FTTC and FTTP Issues => Topic started by: maybecrazy on March 25, 2016, 06:57:08 PM
-
My interferer is my immediate (semi-detached) neighbour, please check my graph, the sudden drops are when they use their internet but I don't know if it's crosstalk or bad RFI from their PC or modem/router, the HG612 does hold on to sync even though the attainable drops below the sync.
Should I even be worried ?
The problem is they're not very approachable, the sort that won't even lift their head to say good morning !
Any advice would be welcome.
-
That is a lot of DS errored seconds for a G.INP line I would not jump to the conclusion this is caused by your nextdoor neighbours those errors are just to intense for a crosstalker or RFI a line issue would be more like it.
There is a 18 minute cycle going on look at the G-Retransmit TX graph
-
Thanks for replying.
The sudden SNR drops are definitely caused the neighbours, they have just come back from 2 weeks away and there was not a single SNR drop during that 2 weeks. Soon as they come back they start again. I've been monitoring this since I switched from Virgin over a year ago
They also both work so no drops during the day only evenings and weekends.
I agree the line is not perfect but I've had the ES ever since changing form Virgin, They have recently changed my original cabinet for a new one and for about a week I had regular resyncs but they eventually stopped and it settled again.
BTW G.INP was only activated this morning.
PS I only have basic knowledge of this stuff so most graphs don't mean alot to me :)
EDIT: Just noticed the G-Retransmit TX have only started happening since G.INP was activated this morning, so I can't see how that relates to SNR drops that have been happening since the beginning.
-
BTW G.INP was only activated this morning.
When G.INP has become active on a line we normally see a sudden drop off of errored seconds but your line has not seen this, only at the times from 14:00 to 18:00 the errored seconds show up as zeros for a short time.
The only option for you would be a BT OR Rein team to investigate to see if this is coming from your neighbors, I very much doubt you could ask them to turn off all appliances and sit in the dark for 24 hours while you monitor your stats.
-
Given that you sync at the full 80/20 and your a) attainable is higher than this and b) your modem holds the sync even when your SNRM falls I wouldn't worry too much about this - apart from a matter of academic interest.
-
I would agree with gt94sss2's comments.
Granted it is of interest to understand what is occurring but it is currently not service degrading. So if you did not have the ability to monitor the situation would you be aware, from ordinary service usage, that something is occurring?
-
I do agree about the monitoring comment but on the other hand how would anyone know when something was badly amiss without it :)
Even though the attainable drops below the sync during the SNRM falls ? Even though for example during this afternoons drop attainable was 72xxx this should not be a concern ?
-
in reality a 70s sync is great, my advice get over it, the real issue here is if any instability occurs which hopefully should not if you sync up when the SNRM is low.
On legacy intervealing corrected errors had a ongoing latency cost, on g.inp the cost is only when retransmit is used, this creates jitter tho but does keep base latency lower. If # of retransmits is low then jitter hopefully shouldnt really be noticeable.
-
I'm just amazed a line with 17.2dB attenuation has a sync so high must have very low crosstalk.
-
in reality a 70s sync is great, my advice get over it, the real issue here is if any instability occurs which hopefully should not if you sync up when the SNRM is low.
On legacy intervealing corrected errors had a ongoing latency cost, on g.inp the cost is only when retransmit is used, this creates jitter tho but does keep base latency lower. If # of retransmits is low then jitter hopefully shouldnt really be noticeable.
But Maybecrazy is also having G-Retransmit Uncorrected errors this is why they are seeing more errored seconds than normal with G.INP this is a cause of concern and compare it with my line
-
What is interesting about my G-Retransmit graph is the period either side of 16.00 which is mostly clear of G-Retransmit errors ties exactly with the drop of SNRM
So perhaps the suggestion of syncing when the SNRM drops would yield an altogether more stable connection ?
-
What is interesting about my G-Retransmit graph is the period either side of 16.00 which is mostly clear of G-Retransmit errors ties exactly with the drop of SNRM
So perhaps the suggestion of syncing when the SNRM drops would yield an altogether more stable connection ?
That may help or even better turn off the FTTC modem for 8 hours and see how it looks tomorrow
-
That may help or even better turn off the FTTC modem for 8 hours and see how it looks tomorrow
I'm willing to do that but why 8 hours, is that period of time significant in some way ?
-
That may help or even better turn off the FTTC modem for 8 hours and see how it looks tomorrow
I'm willing to do that but why 8 hours, is that period of time significant in some way ?
I call it MSAN relaxing it's supposed to return the BRAS and other parameters back to the normal state if things have gone out of kilter, and no harm will be done by doing it.
-
Thanks, going offline now :)
btw my line is approx 350m and the pic shows what the BT checker says.
-
So as suggested I unplugged the modem for 8+ hours, nothing much seems to of changed, the G-Retransmit UnCorrected errors are still there.
Attainables have both increased and I have for the moment one less amber traffic light.
I think I must out of curiosity resync the next time the the SNRM drops :)
EDIT: the remaining amber traffic light has just turned green !
-
Wow.
I can't get onto MDWS to investigate graphs beyond what I can see on here, but those look "interesting".
I can believe the SNRM drop from the disturber. But the UnCorr figures are the strange ones. That they occur at a regular interval is strange, but the fact that they get better when SNRM drops is counterintuitive.
Just how regular are the UnCorr peaks?
Does anything noticeable change on the FEC, CRC, or ES graphs when the SNRM drops? Or when the UnCorr peaks happen?
-
Yes, very odd.
3 graphs below, ignore the big blank in the middle as that's when the modem was off for the 8 hour period.
Look at March 25. 16.00, that's when the disturber was last online and the SNRM dropped, all errors seem to disappear !
-
I see you have done a modem re-sync at 16:03 and your sync rate has gone down quite a bit and no errored seconds or uncorrected errors and the DS SNRM is holding on at 6.6dB and it has just gone up to 10.6dB over 30 minutes ???
Chrysalis must have a better understanding on what your doing with your setup than we do ;)
I have say this is looking like Crosstalk :(
-
Yes, my disturber come online again so I was curious to see what happened and as expected it synced much lower but the errors disappeared !
Seems I can't have it all, it's either higher sync with errors or lower sync with few errors. Imagine trying to explain this one to an OR engineer.
Check my graphs now, disturber has gone offline again, attainable has gone back up, sync has stayed lower, errors have stayed mostly gone but the SNRM has settled at some weird value.
I really don't know what to do for the best.
-
I really don't know what to do for the best.
Don't make any other changes to the circuit. Please let it operate in that state for the next 24 hours. WWWombat will look and think and . . . :)
-
OK will do and thanks to all participating.
-
Seems I can't have it all, it's either higher sync with errors or lower sync with few errors. Imagine trying to explain this one to an OR engineer.
You can still sync at the higher speed if you don't mind seeing 165 errored seconds per-day your are still miles away from the DLM red 2880 on the speed profile.
I would have thought by now the Attainable rate would have lowered due to effects of crosstalk but as your crosstalk is not constant 24/7 then who knows.
-
Do you think it's a case of the cross talker turning off the modem at night to save £1 a year......
-
Do you think it's a case of the cross talker turning off the modem at night to save £1 a year......
Sounds like it, If they had a DLM re-sync it would show up in the SNRm graph as a large spike and his crosstalker looks like they are turning the modem off and leaving off until they need to use it
It sounds silly but some people do this either to save money or to reduce the possible house fire
-
Do you think it's a case of the cross talker turning off the modem at night to save £1 a year......
Yes exactly this, more than that I believe they only turn it on when they go online !
Around 10pm when they go to bed I can hear them pull the TV plug from the socket so I think they're old school thinking, just in case it blows up ::)
-
You can still sync at the higher speed if you don't mind seeing 165 errored seconds per-day your are still miles away from the DLM red 2880 on the speed profile.
If I do sync higher will the G-Retransmit UnCorrected errors cause me any problems ?
-
If I do sync higher will the G-Retransmit UnCorrected errors cause me any problems ?
apart from the increased error seconds and some minuscule extra latency added during the G-Retransmit error period I can't see the DLM taking action.
Just leave your line as it is because there could be some valuable info in here the experts can use since this new ECI G.INP rollout.
-
I am looking at the SNRM graph, attached below, having zoomed in around the time of the forced re-synchronisation event. It has me puzzled. ???
At 1430 hours, the SNRM is 6.7/12.2 dB (DS/US).
At 1528 hours, the cross-talk begins and the SNRM drops to 3.1/11.6 dB (DS/US).
At 1603 hours, the circuit is caused to resynchronise and the SNRM is then 6.4/9.2 dB (DS/US).
At 1748 hours, the cross-talk ends and the SNRM rises to 10.6/10.4 dB (DS/US).
I am troubled by those values. It was the anomalous behaviour of the US that first caught my eye.
Consider the US SNRM. Before the cross-talk began and before the re-synchronisation event it was 12.2 dB. After the re-synchronisation event and after the cross-talk had ceased it was 10.4 dB. A delta of -1.8
Now consider the DS SNRM. Before the cross-talk began and before the re-synchronisation event it was 6.7 dB. After the re-synchronisation event and after the cross-talk had ceased it was 10.6 dB. A delta of +3.9
-
I agree the errors are high considering g.inp is active, but my advice is based on what I believe the openreach response will be which I think will disappoint you, openreach will probably see this line as well within spec so nothing to fix.
Regarding the fluctuating snrm it could be crosstalk but it also could be a device they have that's emitting interference.
-
I really don't know what to do for the best.
Don't make any other changes to the circuit. Please let it operate in that state for the next 24 hours. WWWombat will look and think and . . . :)
I'm afraid my superpowers are waning... though being on a narrowboat, with limited access and the fact I can't get on MDWS this way may be more effective than kryptonite.
The original impact is strange - that UnCorr happen in such a patterned way suggests, perhaps, a modem artifact, rather than a noise impact. I really need to correlate all the (error) graphs at once to say more.
The later impact, where errors don't appear with the lower sync, is the conventional expectation.
To @maybecrazy - what should you do? I don't see anything critical either way, but the key thing to watch is the ES graph, making sure the ES total per 24hrs stays reasonable. A few hundred or less.
@b*cat For upstream noise margin, you always need to factor in any adjustments to the power too. I suspect that UPBO works by adjusting power relative to "excess" noise margin, at least when the package speed can be achieved. I can't tell if that's the case here...
@anyone
The graphs for CRC vs UnCorr (on one of @maybecrazy's post above) are both described as "per min", but (in my mind) ought to end up as the same value. That UnCorr peaks at 60, while CRC peaks at 4 suggests that one isn't being converted from a "15 min" statistics value into a per minute value.
Thinking on from that, I recall that UnCorr are counted in the section on retransmission, while CRC probably come from the 15 minute bins that are in the --stats output. I wonder how the two raw values change over a 30 minute period, vs conversion into "per min" values.
-
Thanks to everyone who has participated in this thread, it's been, erm, interesting !
It seems to me G.INP has been of absolutely no benefit to me what so ever, the way I see it it's made my line worse.
If we ever get offered FTTPoD at a reasonable cost I'll be at the front of the queue, this last mile copper or whatever it's called is such a lottery.
btw, I've attached a screenshot of today's mess.
-
I see you have decide your sync rate is more important than stability and I don't blame you and seeing your MDWS there is no reason why your line could not perform like Roseways at 2.1dB and he has a load of crosstalkers
-
This is crazy. Just about every type of error rate is behaving exactly the opposite to what you would expect. I dont think Ive ever seen anything quite like that before. ???
Dont like the look of the jitter effect thats been picked up since last resync either. I have seen similar to that before when a modem starts behaving silly after a power surge & outage (My Voyager 2100 was notorious for doing it if you flicked power off at the main fuse box or after power cuts. It would jitter like that until I did a full modem power cycle again).
I'd certainly try a reboot to see if you can get rid of it.
-
As I am (usually) more interested in the physical infrastructure for a circuit, I will always take a look at the Hlog and QLN plots.
Reviewing the Hlog plot, I see nothing of significance. Even the rapid droop, at around tone 4000, does not cause concern.
However the QLN plot, with its "block-like" structure in the US segments and the very "fine fuzz" in the DS segments, has me puzzled. Could it be due to a defect with the modem? A defect with the DSLAM line-card?
All I can say, which is stating the obvious (a trait of Sybil Fawlty (https://en.wikipedia.org/wiki/Sybil_Fawlty), whilst using the telephone when in full-gossip mode), is that something is definitely wrong! :(
-
Morning, just before midnight the 'jitter' disappeared as quickly as it appeared without intervention from myself and around 1am I changed the modem for a 2nd unlocked HG612 which I have as a backup, I guess this will at least eliminate modem problems.
DS attainable has increased and the DS SNRM increased slightly with the 2nd modem.