suggestion to PN for user connection stats

[#1]

Quote from: Chris

It's something that I'm looking at getting into a project, I can't make any promises or timescales at the moment as we haven't even considered any potential extra load on the RADIUS servers.

Then don't process the logs in situ, move them to another host first and then draw the graphs, or log directly to an SQL table.

[#2]

Hi,
I'm afraid that there's been no update on this currently.  I know that Chris has been picking this up as a request in another project but I'm not sure if he made any progress.
He's off this week, so I'd check with him on Monday.

[#3]

Any progress on this idea,
Toby

[#4]

It looks like it was only taken as an idea, and nothing came of it

[#5]

Unfortunately not, it's still a 'nice to have' but no guarantees.

[#6]

Chris,
I suggest that it is more than nice to have, given the customer support work load on PN staff.  The availability of this diagnostic would give users a clearer insight to what is happening on their line without the need for day on day effort from the DCT / CSC.
This idea as been floating around for over two years!
Happy New Year btw!
Kevin

[#7]

On the one hand it would, but it'd also end up with a lot more faults being raised based on disconnections and would also add considerable load to our RADIUS platform as well - both of those things need taking into account before we can look at this really from what I can see.

[#8]

Matt,
Point well understood and thought about before posting.  The issue pivots on would people use this to see IF they have a problem (thereby generate more support demand) or because they DO have an issue which they want to monitor (thereby reduce the load on the support team)?  Education sees important / applicable here - a few random disconnections is not an issue and in most cases can be ignored as they do not adversely impact the DSL characteristics.  Frequent disconnections or those associated with a specific event (for example noise at similar times of day) are the ones which point to an issue impacting DSL characteristics thereby requiring resolution.
How viable might it be to only provide access whilst a fault ticket is open?  Personally I do not think it should be restricted, users should be able to inspect their service performance history.
Cheers,
Kevin

[#9]

I'm not sure but will certainly make sure it's passed on. The fault ticket thing is a tricky one, on the one hand it'd seem to be when it's most useful but on the other a connection graph is usually added to the ticket each time the diagnostics are done, especially on a dropping connection issue.

[#10]

Matt,
Thanks, but adding it to the ticket (from experience) requires a request - which looses the ticket's place in the queue - needs to wait until the ticket comes back to the top of the queue and then needs PN support staff effort.
Note I edited my previous post to add the idea if adding education to the use of such a tool, which would help to mitigate false issues.  This is a three cornered issue - usefulness when here is a problem - reduction of PN effort when there s a problem - interest when there is no real problem creating a support load.  If people want to go looking for issues, they could devise means of monitoring disconnections themselves, so not making the radius gaps available does nt negate the potential for non-issue support workload
Kevin

[#11]

Quote from: Townman

Thanks, but adding it to the ticket (from experience) requires a request - which looses the ticket's place in the queue - needs to wait until the ticket comes back to the top of the queue and then needs PN support staff effort.

I've just checked your account for faults and can see that on ticket 69872306 the radius log graph was added on 3 occasions, only the last one was (going by the responses on the ticket) following a request from yourself. As I said above, it's normally added to a fault ticket when our agents do the diagnostics as the connection logs are a major part of diagnosing a dropping connection.
I realise there are many good reasons for doing this and as I said I'll pass the feedback on, but I'm afraid there are still other priorities for our development team at the moment. We'd also need to be sure either that a) we're not going to get a lot more fault requests if we do this or that b) if we do we have the resource in place to deal with the extra faults. From experience, no matter how many warnings or how much text is on the page advising of what can be seen as a fault, we will still get fault tickets raised because 'my connection dropped once' - trust me on this

[#12]

Matt,
Thanks - for the record, my PN faults management experience is much wider than my personal residential account as attached to this forum ID.  I'm advised that my BT circuit issue was one of the longest business line issues in recent history, largely thanks to BTOR's poor rural circuits.
The risk of more fault reports is well understood, but I'm bating for those with real issues, for whom waiting for ticket turnarounds might be less than ideal, especially when you are also very busy!
Cheers,
Kevin