|
|
ID Verified Lifetime subscriber
Trusted
Chorus
OldGeek:
I have since seen in other threads on Geekzone that you can loose service for 30 minutes or more with a transfer. Given that this can only be done during normal business hours (ie not evenings or weekends) and Chorus will only commit to a schedule of 'morning' or 'afternoon' this is not tolerable to those of us who exclusively work from home,
This is not entirely correct. A transfer order can be ordered for a specific time - anywhere from 6am through to 9pm on ANY day of the week (inc weekends). All the RSP has to do is select the exact time their customer wants it. The only caveat is that it must be at the top of the hour as shown in the example below:
[EDIT: Just to add that our system clock is extremely accurate - some transfers may be initiated a few minutes early depending on how large the batch of orders is for that hour, but none are ever completed late. The same applies for intact activations, plan changes, disconnections etc - these are all precisely timed]
As for losing service "for 30 minutes or more", I concur that could potentially be true in some cases but not due to any Chorus limitation. By and large all transfer requests on the Chorus network go through almost instantaneously - so the connection is with RSP A one minute, and the very next minute RSP B's connection is online. Where it might fall over is if the new RSP delays any required config at their end to give you internet signal. That is not something that Chorus can control. Many RSPs have good B2B processes in place so that as soon as Chorus sends the Service Given notification to the RSP, their automation picks it up and completes the connection & commences billing at their end. For some of the larger RSPs that I handle, this happens within a minute or so. Generally it takes longer to swap out your router (or reconfigure your existing one).
I don't disagree with your sentiment though - for some people for whom uninterrupted internet service is critical, then using the Multiple Primary function to have a crossover period is the best way to go. It also means you have a failover option if the new service doesn't work for whatever reason (such as a faulty router etc).
The views expressed by me are not necessarily those of my employer Chorus NZ Ltd
ID Verified Lifetime subscriber
ID Verified Lifetime subscriber
Update: I am seeing a lot of short disconnects reported through my Samknows whitebox (wired connection to a Sky router LAN port):
Note that the problem starts on Friday May 20 when I moved the whitebox from the Voyager router to the Sky router.
There is no noticeable impact on the users, including those working from home. Hovering over each red sector shows a time range, disconnect count and disconnect duration - for the last red sector on the 25th, this is 19:56:07-20:46:20, 34, 4 minutes.
Sky is running on Port 3, Voyager on Port 2. I have swapped over the WAN cables (router to ONT) with no change, so logically only the Port connection and router are the variables.
I am curious about how a device like the whitebox can detect disconnects with this level of granularity. I would welcome feedback from GZers on this before I raise the issue with Sky.
--
OldGeek.
Voyager referral code: https://refer.voyager.nz/
ID Verified Lifetime subscriber
ID Verified Lifetime subscriber
ID Verified Lifetime subscriber
ID Verified Lifetime subscriber
ID Verified Lifetime subscriber
ID Verified Trusted Lifetime subscriber
ID Verified Lifetime subscriber
|
|
|
