![]() ![]() ![]() |
|
Sounds like its something that i will just have to deal with until its fixed by who ever. Not much we can do if its not an issue on my end or sparks end!
RekujaNZ:
I've also noticed micro disconnections through various games and even while browsing.
Steam will drop connection randomly for 5-6 seconds, friend list goes offline and back up.
YouTube will stream perfectly fine sometimes, but the video will stop downloading and buffer for 5-6 seconds before it picks up again and downloads the entire video at full speed.
Have also disconnected from World of Warcraft and have seen the micro disconnect cause a freeze lag in PUBG before it comes back to normal after 5-6 seconds.
Wellington region, modem doesn't disconnect according to the VDSL page in the modem settings, uptime still solid.
Steam dropping for 5-6 seconds is normal, normally relates to their elastic servers scaling.
Videos buffering and disconnections like this does sound like peaks of SES (large errors) causing dropoffs is data flow.
Could be purely dropping the PPP session though?
This would require monitoring and checking into by team.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
Been having issues all night tonight on and off, Disconnections from WoW, random drops from Mumble but not an actual disconnect (voip just stopped).
This is a snippet of my pings to 8.8.8.8 quite the difference from earlier in the day :<.
Pinging 8.8.8.8 with 32 bytes of data:
Request timed out.
Reply from 8.8.8.8: bytes=32 time=127ms TTL=56
Reply from 8.8.8.8: bytes=32 time=118ms TTL=56
Reply from 8.8.8.8: bytes=32 time=109ms TTL=56
Request timed out.
Reply from 8.8.8.8: bytes=32 time=124ms TTL=56
Reply from 8.8.8.8: bytes=32 time=117ms TTL=56
Reply from 8.8.8.8: bytes=32 time=81ms TTL=56
Reply from 8.8.8.8: bytes=32 time=122ms TTL=56
Reply from 8.8.8.8: bytes=32 time=124ms TTL=56
Reply from 8.8.8.8: bytes=32 time=120ms TTL=56
Reply from 8.8.8.8: bytes=32 time=119ms TTL=56
Reply from 8.8.8.8: bytes=32 time=122ms TTL=56
Reply from 8.8.8.8: bytes=32 time=124ms TTL=56
Reply from 8.8.8.8: bytes=32 time=129ms TTL=56
Reply from 8.8.8.8: bytes=32 time=121ms TTL=56
Reply from 8.8.8.8: bytes=32 time=125ms TTL=56
Reply from 8.8.8.8: bytes=32 time=120ms TTL=56
Reply from 8.8.8.8: bytes=32 time=116ms TTL=56
Reply from 8.8.8.8: bytes=32 time=46ms TTL=56
Gamgetta:
Been having issues all night tonight on and off, this is a snippet of my pings to 8.8.8.8 quite the difference from earlier in the day :<.
Pinging 8.8.8.8 with 32 bytes of data:
Request timed out.
Reply from 8.8.8.8: bytes=32 time=127ms TTL=56
Reply from 8.8.8.8: bytes=32 time=118ms TTL=56
Those times seem a bit high, please provide a traceroute to go with.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
I would but ill have to try and catch the lag happening at the right time to do the tracert. Everything looks fine once it goes back to normal tho.
Gamgetta:
I would but ill have to try and catch the lag happening at the right time to do the tracert. Everything looks fine once it goes back to normal tho.
please do next time, as that i suspect will be exposing where the problem lies.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
hio77:
please do next time, as that i suspect will be exposing where the problem lies.
I will try my best tomorrow night. Just to give you an idea, this is what im seeing with not much else going on:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.254 - 0 | 1792 | 1792 | 0 | 0 | 5 | 0 |
| No response from host - 100 | 358 | 0 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 358 | 0 | 0 | 0 | 0 | 0 |
| ae8-10.akbr6.global-gateway.net.nz - 1 | 1788 | 1787 | 19 | 22 | 81 | 20 |
| ae7-2.akbr7.global-gateway.net.nz - 1 | 1788 | 1787 | 19 | 23 | 81 | 22 |
| xe5-0-4.sgbr3.global-gateway.net.nz - 1 | 1787 | 1786 | 44 | 48 | 107 | 52 |
| ae2-10.sgbr4.global-gateway.net.nz - 0 | 1791 | 1791 | 43 | 47 | 106 | 44 |
| 72.14.217.100 - 0 | 1791 | 1791 | 43 | 47 | 113 | 44 |
| 108.170.247.33 - 0 | 1791 | 1791 | 43 | 47 | 105 | 44 |
| 209.85.251.53 - 1 | 1784 | 1782 | 43 | 46 | 104 | 45 |
| google-public-dns-a.google.com - 0 | 1791 | 1791 | 45 | 48 | 106 | 45 |
|________________________________________________|______|______|______|______|______|______|
WinMTR v0.92 GPL V2 by Appnor MSP - Fully Managed Hosting & Cloud Provider
I'm seeing a bit of jitter there to your router - how are you connected to the router?
Past that, noticeable jumping upstream, which i would suspect to be upstream congestion in bursts.. on a 55/22 connection i'd normally not expect to see this, but none the less.
DM me your line/account and i'll start tests about 5pm so that we can capture your evenings data by 11pm to skim over as that seems to be your pain period.
no promises about being onto anything here, but a few tell-tail signs popping up
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
Ive been chatting with Hio77 and attempted things he has suggested and still having issues )=
We thought maybe there was some AC leakage into the modem, but switching multiboards/direct to the power socket has not seemed to make any change im still getting frequent drops in games and im stumped as where to go next :/
Gamgetta:
Ive been chatting with Hio77 and attempted things he has suggested and still having issues )=
We thought maybe there was some AC leakage into the modem, but switching multiboards/direct to the power socket has not seemed to make any change im still getting frequent drops in games and im stumped as where to go next :/
This has actually been a sizable improvement, Moving from an average of 100K errors per second to just shy of 1K errors.
Purely being on the upstream band, this is where we can't consider it to be a fault (chorus will say NFF on sight) however does open to a few other options now that things have dropped down into much more respectable numbers!
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
Yeah for sure, i know how chorus is with NFF lol, but in a way im glad that this seems to have helped fairly significantly thats for sure!
Hi All
Had put this thread to bed.. gaming all good other than the first couple of days when the swap to Spark happened..
Slight twist to the story, had VF call to say you owe us money, and according to them not only had we not been disconnected.. we are currently accruing data usage ??
called Spark Help, and they confirmed we are with them, and have data usage accruing with them as well..
Any of the Spark sages have a clue as to how this can be ??
Was advised by Spark all good to tell VF to disconnect, which I did.. They then rang back 15 minutes later and said maybe hold fire.. No clue as to whether my internet will die in the near future.. Both sides indicated that swapping from a plan with a land line to naked can break the provisioning system..
Cheers Chris
Lemming:
Hi All
Had put this thread to bed.. gaming all good other than the first couple of days when the swap to Spark happened..
Slight twist to the story, had VF call to say you owe us money, and according to them not only had we not been disconnected.. we are currently accruing data usage ??
called Spark Help, and they confirmed we are with them, and have data usage accruing with them as well..
Any of the Spark sages have a clue as to how this can be ??
Was advised by Spark all good to tell VF to disconnect, which I did.. They then rang back 15 minutes later and said maybe hold fire.. No clue as to whether my internet will die in the near future.. Both sides indicated that swapping from a plan with a land line to naked can break the provisioning system..
Cheers Chris
Now this twist could indicate a few details.
If you flick me your account number, i will ensure your service IS running on spark, If that is the case the only case that you could still be using data on vodafone is if you had a device plugged into the ONT port for that.
Could be a case of Port 2 being assigned for spark and your using Port 1 or something.
While with copper there is a changeover period, because of how fibre is provisioned you may have to notify the loosing party.
#include <std_disclaimer>
Any comments made are personal opinion and do not reflect directly on the position my current or past employers may have.
|
![]() ![]() ![]() |