SNR varying wildly

[#1]

@Gandalf @ejs Thanks both. Yes SuperStable would explain the issue, with the red threashold an MTBE at 3600s - I don't get that even at 15dB margin. Since my line reset to 15dB at 4am yesterday, had 85 ES before midnight, for a MTBE of 847s (two batches 8am-3pm, and 5pm-midnight). So under SuperStable that counts as a red period - but to me it was very stable - had a very low fec rate.

Now when my MTBE goes below about 300s, then my line has a stead flow of fec, line fighting to stay up - but it does; still can't be much margin. This is what I have at 3dB margin.

So my gut feeling is that a "Stable" profile would probably be best (e.g. red=300s, green=6000s). "Standard" would also work (have me at 3dB) - but fec all the time.

As for @Gandalf custom levels (red=1s green=86400s), less comfortable with that - it means whatever happens I'll be in amber, so the margin would never change. That would be fine if at 6dB, but maybe not what is intended if at 3dB or at 15dB, all of which would be amber.

So if you are OK, I'd prefer a "Stable" or "Standard" profile.

Thanks.

[#2]

I've placed an order to put you on the Standard profile.

This should complete either tomorrow or on the 04/12/2018. Let us know how things look next week..

[#3]

Woah - that was quick - the DLM just made the change. And back to 6dB margin! So looking good so far.

I'll monitor for a few days, then mark as fixed ...

Its upped me to interlacing of 64 - but that fine, latency causes me no worries at all!

[#4]

The order to change the stability profile hasn't gone through yet.

[#5]

Strange! Well the DLM definitely just reset my line to 6dB margin. From the stats I didn't think it could do that on superstable. Anyway I'm happy

[#6]

Ah fair. Maybe the setting has changed in the background prior to the order completion.

Either way I'm glad to hear that and let us know how things go over the next few days.

[#7]

Well the line has stayed up for two resets of the DLM. It has stayed at 9Mbps download speed, and margin at between 3 and 6 dB. So the problem seems solved.

I'll give @ejs the credit for the fix, we each saw the data, but he was the one that saw the possible cause of the wrong setting in the DLM. @Gandalf, I hope you are OK with this, I know you implemented the fix, and for that I'm grateful, but can only give one fixed flag.

My script I'll have to update, its currently recording in detail anything over 1000fec per sec - but I must have 30 or so such events (all false alarms) per day. But I know that when the fec per sec reaches the 4k sample rate, that the DSLAM is taking the line down. So don't have much margin. I'll probably switch to CV per sec.

I'll also change the code for calculating mean time between ES, in the past I taken a time period, e.g. 24 hours, counted the ES, and divided one by the other to get the mean time. What I'll change to is recording the time since the last ES, for each and every ES. There aren't so many a day, and the average of those times is also the mean time between ES - or rater the long term average is. There are various possible ways to define mean time between ES, this has the advantage that its easily calculable but gives a time for each ES. This way I can see when the bad ES happen during the  day. So it will give good indication of any repetitive errors.

Thank you both for you time spend helping. Its good to have a solution.

[#8]

Glad to hear that your speeds are stable now. 

No problem from me in giving @ejs the fix as he diagnosed the issue, I just pushed the buttons.

Let us know if you need any further assistance at all.