Would you accept this from your ISP?

Forums › New Zealand Broadband › Would you accept this from your ISP?

1 | 2 | 3 | 4

richms

26418 posts

Uber Geek

Trusted

Subscriber

#506452 14-Aug-2011 20:47

Hmm, tough one, I would just cancel it and tell them to stick the contract termination fee as they were not providing you with the service. Only issue I have with snap is that they are officed in Chch so if it does get to disputes tribunal stage, then it means that bloody conferencing thing which is a PITA.

Richard rich.ms

MyHeritage

Shop MyHeritage and uncover your origins and find new relatives with a simple DNA test. (affiliate link).

GeoffisPure

456 posts

Ultimate Geek

#507109 16-Aug-2011 08:22

An update for those still following this saga:

From Snap to Me:
That's good to know the tech didn't charge the $200.00 fee. I've discussed this with our NOC team (they run our Core network infrastructure and manage all the POP sites up the country (point of presence) > in that respect, that is the highest you can go technically in the company. One of our senior engineers checked your line and according to him and tests on our network there is nothing on our core/backbone that is halting or causing the fluctuation; they noted that the only other 'main' cause would be oxidation on a joint somewhere a-long the line. The tech who went out, (I thought) would check for this.. but wholesale faults kept saying there is no fault :(. Oxidation would cause the exact fault you're getting (according to people I've discussed this issue with). Yes, if chorus are not willing to check the line for oxidation (time consuming process). They'll just tell you to go back to the ISP. Trying a different ISP could potentially be an idea; but this involves going through a full- sign up with a new ISP and also (may) dependent on the ISP would contract a minimum term of service etc. This option would honestly be up to you. If you'd like me to, I can amend the fault (before they close it off) asking them if they'd be willing to check the line for oxidation, but like I note above, it doesn't seem to be something they're willing to do. Please let me know how you'd like to proceed.

From Me to Snap:

I've been doing some research on the internet and came across this thread
where a few users at an Australian ISP were having the same problem.
http://forums.whirlpool.net.au/archive/1423919

These two posts are from a manager at the ISP:

http://whrl.pl/Rcfwfp

>As for the 30 second drop issue have found it is a VLAN issue so shouldhave that solved by tomorrow afternoon hopefully

I found this one interesting because I note that my local exchange was
upgraded to VLAN at the same time this problem began for me.

http://whrl.pl/RcfIy9
>I have been doing some testing and found the cause of the 30 second dropI have turned the equipment causing it off temporarily while I look to see
if there are any software updates.
>It is a pretty important bit of the network and I have a temporary workaround in at the moment however I may need to turn it back on but rest
assured now that i know what is causing the problem I will make sure it
gets resolved

This one was posted after the users confirmed the 30 second dropoff
problems had stopped! Quite reassuring! It really seems the fault is
equipment related! He doesn't mention what parts specifically, but maybe
with your network knowledge this might give some hints?

A user in that thread had posted this screenshot of the problem:
http://img39.imageshack.us/img39/2900/100mgdownloadtest.png
A user then posted this one showing the problem had been fixed:
http://i40.tinypic.com/eiwmcx.jpg

I'm pretty much convinced now that the problem is network equipment.
Assuming my problem is the same, is this within the scope of Snap or
Chorus? Or in other words, if I switch ISP, does this potentially bypass
the faulty equipment? If you think oxidation still might be a cause, then
by all means go ahead and have them test this.

I am curious to know why I'm the only one experiencing it, though. If it
was chorus equipment, wouldn't my neighbour (who is on Xtra) have the same
problem? I wonder if the problem would exist for her if she switched to
Snap? (I don't understand what physically happens, but was told equipment
at the cabinet is altered when somebody changes ISP).

If none of the above is helpful to you and the problem is not able to be
resolved soon, I'd really like for you to arrange for me being able to
churn to another ISP without an early disconnection fee from Snap. I think
this is only fair given the poor quality internet I've put up with for the
past few months, and all the running around I've had to do (I'm not saying
the fault is necessarily Snap's fault, but Snap is the party responsible
for sorting this problem out and so far haven't been able to).

I'd churn to an ISP with no minimum term, as ideally, despite everything,
I'd still like to be with Snap once this problem is identified and
resolved. I'd hope that after I churn away, you'd follow up with me to see
if doing so solved the problem.

GeoffisPure

456 posts

Ultimate Geek

#507112 16-Aug-2011 08:28

I also have download Bandwidth Meter Pro which is giving me some nicer graphs showing what is happening:

This downloading from iTunes (Snap's Akamai server):

This test shows a file being downloaded and then reuploaded. Interesting how the download breaks up in the middle, but uploads seem not to be affected by this dropping-out cycle.

GeoffisPure

456 posts

Ultimate Geek

#508748 18-Aug-2011 21:27

Snap is going to try switching me from EUBA to BUBA (if that makes sense to anyone).

It's frustrating that this issue is going on for so long, but I can't really fault them for not trying.

tdgeek

28622 posts

Uber Geek

Trusted

Lifetime subscriber

#508752 18-Aug-2011 21:39

GeoffisPure: Snap is going to try switching me from EUBA to BUBA (if that makes sense to anyone).

It's frustrating that this issue is going on for so long, but I can't really fault them for not trying.

EUBA to BUBA translates as from ADSL2+ to ADSL1. You can expect a max connect rate of 7616k downstream and 768k upstream. I guess this will isolate to a compatibility issue with ADSL2+, but it seems a step backward

Talkiet

4689 posts

Uber Geek

Trusted

#508775 18-Aug-2011 22:30

tdgeek:
GeoffisPure: Snap is going to try switching me from EUBA to BUBA (if that makes sense to anyone).

It's frustrating that this issue is going on for so long, but I can't really fault them for not trying.

EUBA to BUBA translates as from ADSL2+ to ADSL1. You can expect a max connect rate of 7616k downstream and 768k upstream. I guess this will isolate to a compatibility issue with ADSL2+, but it seems a step backward

I'm not 100% sure that the "EUBA->BUBA" move will limit to ADSL1 speeds. It's a reasonable attempt by snap as it will result in a significant reprovisioning component.

Keep us informed. Good to see Snap are still trying.

Cheers - N

Please note all comments are the product of my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

insane

3170 posts

Uber Geek

ID Verified

Trusted

#508778 18-Aug-2011 22:40

tdgeek:
GeoffisPure: Snap is going to try switching me from EUBA to BUBA (if that makes sense to anyone).

It's frustrating that this issue is going on for so long, but I can't really fault them for not trying.

EUBA to BUBA translates as from ADSL2+ to ADSL1. You can expect a max connect rate of 7616k downstream and 768k upstream. I guess this will isolate to a compatibility issue with ADSL2+, but it seems a step backward

Sorry but that is incorrect. Many ISPs are still using BUBA and providing ADSL2+, such as the service I'm on.

EUBA0 is the next progression to BUBA and is delivered to the ISP as an Ethernet service, with most users setup in a ATM over ethernet fashion as to not require adjustments on the customers side. EUBA actually delivers a smaller packet load by 8 bytes, ie MAX MTU is actually smaller, so apart from a less likely congested Ethernet handover, the service is not really any different to the end user. It does however make use of the new Chorus wholesale network but again unless there is congestion in a segment where you're traffic is transiting you won't notice.

The shape of the graphs provided almost look like the affects of buffering on an interface somewhere (read: policing/rate shaping/ traffic management), or the result of slight packet loss which results in increasing TCP re-transmits. Would be very interesting if the OP could test UDP traffic only and see whether the patterns are the same.

GeoffisPure

456 posts

Ultimate Geek

#508807 19-Aug-2011 00:36

OMG!!!

I am so happy to report that the problem (which has lasted months now) has been fixed!! Snap had told me that the change to BUBA would happen within the next 24 hours. Tonight at 10pm, my internet went down for a total of 90 minutes.

When it came back up, the problem was gone. Solid and stable download speeds. I can't actually express how relieved and happy I am right now. It has been months of self-doubt, arguing, testing, researching, being on hold, and so many emails back and forth...

It was by finding the answer on an Australian forum (link above) and emailing it to Snap that they finally tweaked and realised it might be something to do with VLAN (I had maintained all along that the fault happened at the same time as the recent cabinet upgrade...)

I'm just so happy that it's resolved. Now for Snap to pinpoint the exact nature of what caused the fault and (hopefully) to arrange me some compensation...

Some graphs to show it working properly:

Cachefly (Aus):

ThinkBroadband (UK)

YouTube (Akamai) So nice to be able to watch 720p!

Fraktul

836 posts

Ultimate Geek

Trusted

#508808 19-Aug-2011 00:49

insane:
tdgeek:
GeoffisPure: Snap is going to try switching me from EUBA to BUBA (if that makes sense to anyone).

It's frustrating that this issue is going on for so long, but I can't really fault them for not trying.

EUBA to BUBA translates as from ADSL2+ to ADSL1. You can expect a max connect rate of 7616k downstream and 768k upstream. I guess this will isolate to a compatibility issue with ADSL2+, but it seems a step backward

Sorry but that is incorrect. Many ISPs are still using BUBA and providing ADSL2+, such as the service I'm on.

EUBA0 is the next progression to BUBA and is delivered to the ISP as an Ethernet service, with most users setup in a ATM over ethernet fashion as to not require adjustments on the customers side. EUBA actually delivers a smaller packet load by 8 bytes, ie MAX MTU is actually smaller, so apart from a less likely congested Ethernet handover, the service is not really any different to the end user. It does however make use of the new Chorus wholesale network but again unless there is congestion in a segment where you're traffic is transiting you won't notice.

The shape of the graphs provided almost look like the affects of buffering on an interface somewhere (read: policing/rate shaping/ traffic management), or the result of slight packet loss which results in increasing TCP re-transmits. Would be very interesting if the OP could test UDP traffic only and see whether the patterns are the same.

IPERF + Wireshark ftw.

Incorrectly/poorly implemented policing/rate shaping/ traffic management would be my guess.

Talkiet

4689 posts

Uber Geek

Trusted

#508809 19-Aug-2011 00:56

GREAT to hear that the problem was finally resolved. Score one for persistence and detailed error reports. Congratulations.... I'm sure it took longer than it should, and l know it took longer that you (or anyone) would have liked, but congratulations on maintaining your composure and getting a good result (finally)!

Cheers - Neil G

Please note all comments are the product of my own brain and don't necessarily represent the position or opinions of my employer, previous employers, colleagues, friends or pets.

GeoffisPure

456 posts

Ultimate Geek

#509007 19-Aug-2011 14:19

Snap have provided an explanation and have also given me a one month credit on my account.

It seems that when Telecom Wholesale upgraded their equipment onto an Alcatel 7302 ISAM (which supports EUBA/BUBA), they've implemented an old firmware version on this card. Therefore, it was treating traffic incorrectly and confusing its self. There are a few ISAMs out there at the moment which do not have the latest firmware running on them, which can cause a variety of issues (including no DSL sync etc). - Unsure when they will upgrade this though.

Telecom Wholesale were aware of your issue from near day-1 when I originally logged the first fault. They hardly ever disclose information about firmware or specifics of their equipment. This is probably why they didn't diagnose that to be a cause for this fault.
(If snap had throttling issues or backhaul issues, you'd experience a more sporadic fault, not a consistent one every 30'ish seconds).

I hope not too many are effected by the same fault and that they don't through as much troubleshooting as I did... It does seem like the system isn't very efficient if Telecom are aware of their fault but choose to turn a blind eye to it even when customers come to them saying "something isn't right here".

I'm glad I started this thread so that it may help others in the same situation. As for me, I'm back to being a happy customer and glad to be with Snap.

insane

3170 posts

Uber Geek

ID Verified

Trusted

#509486 20-Aug-2011 23:39

While its nice that they fixed the issue, I claim BS on the explanation provided, whether from the ISP or wholesale faults.

Whether you use EUBA or BUBA you'll still be using the same Alcatel 7302 ISAM and will be connected to the same port and linecard.
What is different is where the traffic for EUBA and BUBA is aggregated after it passes through the 7302, and how it gets passed through to your ISP. For BUBA it's typically aggregated on a older Juniper ERX 1440 router or M40 I believe, and on a Alcatel 7750 for EUBA.

Would be interesting to see whether any users from different ISPs connected off the same exchange were experiencing the same issue. I guess most wouldn't even notice.

1 | 2 | 3 | 4