Print

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

[broadstairs]

Lets get something straight here over timings. The initial testing started at around 14:26 and finished at about 15:25 and I reconnected the router while the engineer was with me and showed him the re-sync stats. Now if he was going to do some testing it would take him probably 5 minutes to get to the cabinet park up (which is not easy where my cabinet is situated), then open it and cause a disconnect which would have lasted more than a minute which means that neither DSLStats or my router would have missed the disconnect - IT DID NOT HAPPEN. So IF he went to the cabinet and did anything it DID NOT cause a disconnect and re-sync - so frankly my interpretation of what he said which WAS that whet he was going to do WOULD cause a disconnect is bull***t as I suspect was his description of how FTTC works. This guy was in my opinion significantly less than effective than the previous broadband guy who at least viewed my graphs and agreed I had a problem which he agreed had probably gone away but at least he did a reset which put me back to around 65mbps d/s and 20mbps u/s which lasted for about 11 days!

So now I am left with a line which is connected at less than the worst speed which the Wholesale Speed tester says I should get if impacted and well below what it has been performing at prior to all this happening. TT are probaly goping to say that DLM will over time put it back but previous experience says it will not happen.

Yes believe me I am only too well aware from personal experience when I was working as to how difficult it is to try to fix intermittent faults but that does not mean you do a test and GIVE UP, which is what OR are doing in my opinion. OK it does not help at all when TT do not take these issues seriously and try to get OR on site while the simply MUST be able to see an issue is live. If this were the first call out I might accept it but this is the third call on the same issue and has not been resolved. None of this is acceptable and I will not put up with this situation. Believe me TT and OR do not know what will hit them if they don't take an indisputable issue seriously.

Rant off 

Stuart

[burakkucat]

I can offer no advice as how to progress this fault to a satisfactory resolution . . . but will follow this thread with a significant degree of interest. 

[Black Sheep]

I'm confused ............. NS states .................

"Engineer No3 and no fault found and your modem is showing your line has been in sync since 8:01am 20/7/2016 when they test with this JDSU do they not take the modem offline during the tests and then plug the modem back in after all is done and this would show up as new resync"

Yet Stuart states the circuit was out of synch during .... "The initial testing started at around 14:26 and finished at about 15:25"

The two are contradictory.

[broadstairs]

Forget what MDWS may show as the router was not shutdown but the OR guy simply pulled the plug, so believe me in what I said and I have the DSLSTats Eventlog to prove it, the router was disconnected at 14:36 and the first and so far only re-sync was at 15:25 so that was about the time the OR guy left to go to the cabinet. I was with him the whole time. There is NO ambiguity about this.

Stuart

[Black Sheep]

Not being one who uses MDWS, it appears that there is ambiguity when reading the various comments. I can only pass comment on what is asked .......... which in effect was, is there any modem downtime during the engineers tests ??

There is, and from your own comments a whole 50mins of it. Is it normal for MDWS to miss this amount of time ??

[burakkucat]

Taking a close look at B*stairs' circuit data on MDWS, I see that there is a recorded uptime of just over 6 hours. That fits into the time frame which Stuart has reported. 

[Black Sheep]

NS ..............  were you looking at MDWS through a blindfold, mucker ?? 

[NewtronStar]

NS ..............  were you looking at MDWS through a blindfold, mucker ?? 

I seen the uptime and it showed 0.4hrs but my focus was on Resyncs MDWS is still showing 20-7-16 08:01 which is kind of confusing to me.

[broadstairs]

MDWS has a slight issue with re-syncs, it relies on DSLStats on the other monitor to tell it there has been one. In my case DSLStats could not do this because the OR guy simply pulled the plug and then I stopped DSLStats recording and filling up its event log with No DSL connection messages. In fact it also had a slight hiccup and so I closed the program and restarted it with recording stopped until such time as the router was in sync therefore no reporting to MDWS of a re-sync. I think this is an issue for Eric and Tony to review and perhaps record monitor start ups but that is for them to decide.

I'd still like a view on this OR guys description of each end user having their own piece of fibre - just does not make sense to me. Also should one expect diagnostics to be done at the cabinet and should those always cause a disconnect?

Stuart

[Black Sheep]

Absolutely not ...... you have your own port, but not your own fibre.

Diagnostics at Cab ?? Absolutely yes ......... capacitance readings between A-E and B-E are better monitored on a 'dead' pair of wires ....  ie: Cab to NTE .......... also 'Tapping' fault conditions that a one-shot test like a PQT may miss can be observed, this (obviously) will cause a dis-connect.

[burakkucat]

I can understand the confusion.

The mode of operation of MDWS, to detect resynchronisation events between the modem and DSLAM, relies upon the metallic pathway being contiguous immediately prior to and post the event. If the metallic pathway has "just disappeared", as in this case, then a resynchronisation event may be logged but it is not possible to update the database. We must remember that there is a two stage process involved before any of us third parties can see the data as graphical plots . . . the harvesting software (DSLstats, in this case) and the database updating & displaying software (MDWS).

Perhaps I should also add that just like a physical broadband service, DSLstats, HG612_stats & MDWS are "best effort" software services. We have to accept that what can be deduced may need to be a compromise after the consideration various basic data sets.

[guest3]

Sounds a bit like the trouble I had... One of the main issues was poor sync rates. several visits by fibre engineers were unable to diagnose the issue and from the tests done said the line was normal. The last engineer only spotted an issue when the port at the cab was not giving out an 80mb sync after a lift and shift.. could not figure out what was wrong with it so referred back to noc who passed it to pcr engineers.
My line was never at fault.

[broadstairs]

Thanks BS

I suspect the cab visit was more bulls**t since he obviously did not cause any disconnect, plus the fact that about 10-15 minutes after he left I drove past the cab and there was no sign of him or his van, and this cab is by double yellows on a corner and the road is usually full of cars where parking is allowed. Obviously I cannot prove this BUT I do feel it was highly unlikely he did anything.

Stuart

[NewtronStar]

Very helpful indeed thanks broadstairs and burakkucat into how the stats up-loader can miss resyncs

[tbailey2]

MDWS has a slight issue with re-syncs, it relies on DSLStats on the other m to tell it there has been one. In my case DSLStats could not do this because the OR guy simply pulled the plug and then I stopped DSLStats recording and filling up its event log with No DSL connection messages. In fact it also had a slight hiccup and so I closed the program and restarted it with recording stopped until such time as the router was in sync therefore no reporting to MDWS of a re-sync. I think this is an issue for Eric and Tony to review and perhaps record monitor start ups but that is for them to decide.

Thanks B*cat...

The 'Uptime' value shows your router actually resynced at around 14:57 but you didn't restart DSLstats until 15:25. If you had restarted DSLstats within 15 mins of sync being established, the resync would have been caught. And, as noted, no guarantees mind you as there are too many variables involved in running the system for it to be totally reliable. MDWS already does way, way more than I had ever envisaged but isn't and never will be infallible so please don't expect it to be.


I could add in the record manually if you want, the reason in the data is '1 RDI'