Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[S.Stephenson]

I just hope the problem is easy to see....

Otherwise I'll have to put a high-vis jacket on and break the cabinet open with a brick 

Also I need to make myself a Error Seconds record certificate 21686/86400 or 25%

I'm sure that if I didn't have two lines I wouldn't be so laid back about how terrible it is being, I've actually dropped it from the balancer due to how terribly unuseable it was especially for things like voip.

[NewtronStar]

You could still turn off the modem for 6-7 hours and let the MSAN relax your line to see if that helps if another no show happens as its a bank holiday

[S.Stephenson]

You could still turn off the modem for 6-7 hours and let the MSAN relax your line to see if that helps if a no shows happens as its a bank holiday

Will give it a go if they don't, what's happening with the MSAN then has it just gone completely mental after I did my ill thought out experiment?

In future I'll only try something like that on a G.INPed line as a fast path line obviously can't handle such a low snr.

[S.Stephenson]

If I thought yesterdays Error Seconds were bad today is completely insane its already had more and its not even halfway through the day, looks like I may have just got a DLM reset  that better not be their idea of a fix.

[kitz]

Brief response as Im pushed for time.

That is really annoying about the no show.   Need to get on to your ISP about that 
It's not your 'experiment' that buggered things up, seems like there is something else going on.
Ive had a quick look at your stats but cant see any sign of any changes in DLM parameters.

[WWWombat]

In future I'll only try something like that on a G.INPed line as a fast path line obviously can't handle such a low snr.

I probably wouldn't ever let my line go below 3dB, though the best measure is indeed the ES rate.

However, I don't see your experiment as having 'caused' anything. It just cannot have an enduring impact on causing bit errors.

Smart move to take it out of the load balancer. The latest graphs look terrible. But it begs an interesting question ... does the other line go into the same cabinet?

[kitz]

>>  It just cannot have an enduring impact on causing bit errors.

Yep my thoughts.    Powering down everything should allow it to start with a fresh Bit Allocation Table..  it shouldnt continue.

[S.Stephenson]

Both lines go to the same cab,

Technician has just been and done his tests after going through it all he's gone to do a port swap.

A thing he found strange is he couldn't reset the DLM the cabinet refused to.

[WWWombat]

And, as if by magic, all the CRCs have disappeared. Approx 10:35 - so probably fixed by something the guy did.

Cabinet refused to reset DLM? Something seriously borked with that port then... but I'm impressed that the cabinet's refusal was passed as a result all the way back to the engineer. It would have been easy to make a DLM reset in to a one-direction, fire-and-forget action.

[NewtronStar]

That's a hell of a lot better your errored seconds hit a max of 26586 nine times over the limit and the DLM never raised it's eyebrows the port must have lost all communication with the DLM some people here would love this to happen on there lines 

[kitz]

As I commented the other day, for some odd reason it never seemed to move from open profile.
I was expecting DLM to kick in after the E/Secs, but it didnt.

If it was still on 'open', then I wonder if that's why the engineer couldn't get it to reset.
Remember how newly enabled lines or DLM resets during the 2015 Mk2 period remained without any profile for ages and until everything else had caught up?