Sorry aside from the line tap, what are we missing?
I'll link Wayne to this thread, see what he says :) two heads are better than one, so hopefully he'll be of the opinion that the collective knowledge of many geek geniuses is a valuable resource ;)
ChillingSilence: Sorry aside from the line tap, what are we missing?
I'll link Wayne to this thread, see what he says :) two heads are better than one, so hopefully he'll be of the opinion that the collective knowledge of many geek geniuses is a valuable resource ;)
It it were me, I would pick back though this entire thread post for post and confirm that each and every suggestion that has been made has been addressed by Chorus.
If there is any issue for which you do not have an answer, that someone has raised, I would represent it.
I would then present a consolidated list to the community here and let them advise which they feel are important and which are not.
Clearly this fault is not going away and clearly we're not getting on top of it.
...but that's just me :)
Promote New Zealand - Get yourself a .kiwi.nz domain name!!!
OK so I think the only things that haven't been covered, or could be further investigated are: - The line tap possibility - The DMT Tools results, Cyril7 says it shows it's not using the top end of the spectrum? I'm unsure of the implications of this - The cable trace, where does it physically run from the Cabinet to my house - Triple-check the joints at their end and along the way to the demarc at my place - Have a tech install a filter (If they don't trust mine), though I'd suggest that a fault filter isn't consistent with the semi-regular intermittent fault - Have they got somebody at their end, such as a Client Relationship Manager (Not just a regular helpdesk job-logger) who can arrange for somebody who is experienced with complex faults that fall outside of the scope of the regular cheat-sheet to look into it and actively follow up on the situation?
Have you tried removing the filter during a disconnection? Just the ADSL and nothing else to confirm that filter is not a problem. I could go around there and wire in a master filter for you if you like, or just test a spare filter I have.
Since the disconnections sound related to time of day instead of weather or just being totally random, I would agree with Cyril that a line tap is highly likely, which might cause more crosstalk/noise at peak times, but it sounds unusual for it to be quite that unstable. Frequent resyncs used to be more of an issue before cabinetisation, but one would expect now to just see the speed reduce a bit whenever noise is bad.
If you cant get Slingshot to request your line be changed to a different pair, perhaps a new connection on a second line (hopefully wthout contract!) would achieve that and allow you to test it before cancelling Slingshot.
webwat: Have you tried removing the filter during a disconnection? Just the ADSL and nothing else to confirm that filter is not a problem. I could go around there and wire in a master filter for you if you like, or just test a spare filter I have.
Yup tried that, though I appreciate the offer :-) I've tried with and without the filter, multiple routers, multiple filters, getting one of them installed by a Chorus tech at the demarc, which they later subsequently removed...
webwat:Since the disconnections sound related to time of day instead of weather or just being totally random, I would agree with Cyril that a line tap is highly likely, which might cause more crosstalk/noise at peak times, but it sounds unusual for it to be quite that unstable. Frequent resyncs used to be more of an issue before cabinetisation, but one would expect now to just see the speed reduce a bit whenever noise is bad.
Yeah it's an interesting one because it's regular with its irregularities...
webwat:If you cant get Slingshot to request your line be changed to a different pair, perhaps a new connection on a second line (hopefully wthout contract!) would achieve that and allow you to test it before cancelling Slingshot.
They've already changed the pair I was running off, though I think I was with a previous ISP at that point, but I'm certain it's been done. They also tried changing the pairs that I use internally from the router to the demarc.
Thing is I don't actually *want* to cancel Slingshot. All things considered they're good bang for buck, their first-level helpdesk is pretty darn decent (And they took my complaint about the guy who was a jackass very seriously, as well as my compliments to the helpdesk guys who've been very helpful and gone over and above what a normal tech would), and their speeds are always my max line speed... So basically as far as an ISP is concerned, everything within their immediate control has been quite good! It's just this ongoing issue which relies on them getting blood from a rock (Chorus) which is outside of their direct control, which has been a problem. This sort of thing wouldn't be fixed by jumping ship to another ISP unless it's something wrong with the kit in the Cabinet, though AFAIK there is *only* Chorus equipment in the TAT/R cabinet I'm running off... At least I think it's TAT/R, but I've seen inside it and there wasn't any Orcon or Vodafone gear etc in there.
Cloud spending continues to surge globally, but most organisations haven’t made the changes necessary to maximise the value and cost-efficiency benefits of their cloud investments. Download the whitepaper From Overspend to Advantage now.
I spoke with Jo on the phone today and have now read through this thread. We do appreciate all the feedback and ideas that have been suggested.
At this stage we will go for:
1. Work with our wholesale network provider and Chorus to select an appropriate and skilled Chorus technician to 'manage' this case from now until resolution. 2. Talk through the linetap scenario with Chorus 3. Work with Jo to get his router logs to share with Chorus 4. Continue to work with our wholesale network provider and the Geekzone community! ;)
So if you have suggestions that haven't been raised, please post them.
I spoke with Jo on the phone today and have now read through this thread. We do appreciate all the feedback and ideas that have been suggested.
At this stage we will go for:
1. Work with our wholesale network provider and Chorus to select an appropriate and skilled Chorus technician to 'manage' this case from now until resolution. 2. Talk through the linetap scenario with Chorus 3. Work with Jo to get his router logs to share with Chorus 4. Continue to work with our wholesale network provider and the Geekzone community! ;)
So if you have suggestions that haven't been raised, please post them.
Cheers,
-Wayne
Wayne, nice post! :)
I'm a bit confused here sorry people, so this might sound silly.
If I understand it, this is not a naked service, there is a POTS service on the same line?
If that's the case, where is the POTS service coming from? (Exchange or Cabinet?)
If there is a POTS service, can you get Chorus to put the POTS on a different pair to the DSL service so that the DSL service fault is isolated and can be pinned down?
At this point, given the number of site visits, it seems to me that there needs to be a resource focus on proving this fault in a direction by removing everything that's not required, filters, POTS, etc, until the DSL service is stable again (and at a speed that would be expected based on physical distance from the line card).
Once the service is proven stable, then rebuild it. However, at present there seems to be tail chasing and a growing amount of wasted resource just to get this sorted?
Promote New Zealand - Get yourself a .kiwi.nz domain name!!!
DonGould: If I understand it, this is not a naked service, there is a POTS service on the same line?
If that's the case, where is the POTS service coming from? (Exchange or Cabinet?)
If there is a POTS service, can you get Chorus to put the POTS on a different pair to the DSL service so that the DSL service fault is isolated and can be pinned down?
Yes, it's a POTS service.
I'm not entirely sure what this will be achieving though, as the phone line quality is fine during that time-frame. If it helps, as far as I've been able to tell, the DSL router loses all track of the DSL signal on the line, as opposed to it just losing authentication for example. I'm hoping to confirm this tonight when I turn on logging on the router (Though we have a big family dinner to organise as soon as I get home, so I may not get to it tonight before the disconnections begin).
I'd *love* to go Naked-only, but the reliability isn't enough for our VoIP line.... I used to work in VoIP so Naked is ideal, everything of mine is VoIP.
Previous home was on Naked DSL for around 9months. Only had one disconnection when Orcon had issues with their authentication. Other than that, it was up pretty much the *whole* time :D
But yes, that sounds like a good idea, depending how long it takes to get things changed over should it all go belly-up :)
ChillingSilence: I'd *love* to go Naked-only, but the reliability isn't enough for our VoIP line.... I used to work in VoIP so Naked is ideal, everything of mine is VoIP.
Previous home was on Naked DSL for around 9months. Only had one disconnection when Orcon had issues with their authentication. Other than that, it was up pretty much the *whole* time :D
But yes, that sounds like a good idea, depending how long it takes to get things changed over should it all go belly-up :)
I'm wondering if you're missunderstanding me a bit here. What I'm proposing is that Chorus light up a second pair to you. They still supply you a POTS service (in pair 1) and the DSL service on Pair 2. It's not ideal for Chorus, because the idea from Chorus point of view they're wanting to deliver 2 services on the same bit of copper from their RSC.
However in your case, it would seem to make sense to me that they push the POTS on to one pair and the DSL on to another until they can prove out where this fault is coming from.
I made this suggestion because I had a dsl fault myself a few years back that was caused by the B leg going to ground within the line card for the POTS service. This should not have effected the DSL service, and it should have resulted in the phone service being a problem. Once the POTS service was jumpered from one port to another the fault sorted it self out.
I'm wondering if the Chorus guys are being constrained by 'ya, that's how we do it... and have always done it...' thinking here.
Something that I am a bit perplexed about is the lack of information from the Chorus end. DMT tools were able to tell you about the line from your modems pov. But how is it that Chorus are not able to see this sort of stuff? It this level of diag not built into the head ends?
Promote New Zealand - Get yourself a .kiwi.nz domain name!!!
Are you subscribed to our RSS feed? You can download the latest headlines and summaries from our stories directly
to your computer or smartphone by using a feed reader.
Trusted
Slingshot
