Kitz Forum
Broadband Related => ISPs => Topic started by: Chrysalis on May 11, 2017, 03:08:03 PM
-
Link to my graph here
https://www.thinkbroadband.com/broadband/monitoring/quality/share/2c7929f86f40f9234633198ceb0a161e
Notice how the max latency increases during dusk hours (this has been daily for weeks now), of course that is not peak usage time of day, so it is odd, I have not done any speedtesting during that time.
My ipv6 graph does not show this issue.
https://www.thinkbroadband.com/broadband/monitoring/quality/share/ec6acc210ba8cc3f2c08a166f017a582
-
That is a puzzling observation, for which I cannot offer any possible explanation.
-
The peering routeing will probably be different maybe the issues lie on 3rd parties network(links) failing that if they use the same routes, then maybe they have one reversed? As the TBBQM etc will only show the route in one direction
-
well its not just tbb, here is a jittery set of pings, tbb speedtest is perfect tho so whatever it is doesnt seem to affect throughput.
C:\Windows\system32>ping -t bbc.co.uk
Pinging bbc.co.uk [212.58.244.22] with 32 bytes of data:
Reply from 212.58.244.22: bytes=32 time=10ms TTL=56
Reply from 212.58.244.22: bytes=32 time=12ms TTL=56
Reply from 212.58.244.22: bytes=32 time=11ms TTL=56
Reply from 212.58.244.22: bytes=32 time=9ms TTL=56
Reply from 212.58.244.22: bytes=32 time=9ms TTL=56
Reply from 212.58.244.22: bytes=32 time=10ms TTL=56
Reply from 212.58.244.22: bytes=32 time=9ms TTL=56
Reply from 212.58.244.22: bytes=32 time=10ms TTL=56
Reply from 212.58.244.22: bytes=32 time=10ms TTL=56
Reply from 212.58.244.22: bytes=32 time=13ms TTL=56
Reply from 212.58.244.22: bytes=32 time=10ms TTL=56
Reply from 212.58.244.22: bytes=32 time=10ms TTL=56
Reply from 212.58.244.22: bytes=32 time=10ms TTL=56
Reply from 212.58.244.22: bytes=32 time=9ms TTL=56
Reply from 212.58.244.22: bytes=32 time=10ms TTL=56
Ping statistics for 212.58.244.22:
Packets: Sent = 15, Received = 15, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 9ms, Maximum = 13ms, Average = 10ms
-
have tried to raise it via official tech support but hitting a brick wall, as I cannot put 100% into trying to say its something like congestion given the time of day so I am unsure myself, I am pretty sure its not my network tho.
So will have to report this via the backdoor directly to a senior network bod.
-
fault report accepted now, even tho the peak time graphs are not in the same state, speeds are down during peak and below my guaranteed minimum speed from sky so they accepted the report and escalated it.
Apparently was a fault in the sky network which was fixed 3 weeks ago, but seems to tie in with when this issue started.
Obviously there is a chance the peak time slowdown may be completely unrelated to the 4am behaviour, but hoping they both linked.
-
I'm a little uncertain as to what you mean. :-\
Are you still seeing the problem? Or has it now disappeared?
-
I still have the dusk hours issue.
I ran a speedtest last night which was not able to saturate the line, barely managed about 60-70%.
Reported the slow speedtest as a fault as that was a much easier thing to do.
Sky then told me they had fixed a fault 3 weeks ago but is no known faults to cause this issue but raised my issue as they guarantee the speed.
-
Ah, now I understand. Thank you. :)
-
But which guaranteed speed will your ISP use as your attainable rate is 68779 Kbps and your sync rate is 73971 Kbps a difference of 5192 Kbps because of crosstalk
-
For me sky always take the sync. They arent interested in my usually poor attainable versus high sync. Now been told will not look i to it further till my sync hits 60.5 which is the guranteed minimum sync..
-
Your a long way from 60.5 Mbps guranteed minimum sync with your current sync yet only 8 Mbps above this if your modem did a retrain after your crosstalkers went live.
-
The last bout of 568 ses and 4 resyncs seems a bit more than crosstalkers lol..... at one point the sync dropped to 29mb..
-
newt on signup sky give you an estimate and a min guaranteed speed.
the min speed is not just for the sync but also for throughput over their network.
-
Hows it going Chry hope all is well :fingers: I see what your saying the Sync rate and throughput are two different things and me having a Sync rate of 38867 Kbps the maximum throughput i can get with Ookla is 36.27 Mbps and a ping of 18ms
Now when testing with say Speed of Me it goes upto 39..47 Mbps with a ping of 22ms this can't be correct as the throughput is higher than the current sync rate :no:
-
yeah is ok, by the way was a storm here last night, if you curious can check my mdws, wasnt much of an increase of ES tho.
-
Had 3 days of T/storms around 5pm but not local more like 20 miles away it shows up well when looking at CRC's it has less impact when you have G.INP active, it's the longer lines on ECI cabs on fastpath that worry's me even with this Wide Area Event monitor users were still being penalize last year
So lets hope this year the WAE is working as it should
-
looks like its fixed, about a week or two after I emailed the sky uk CEO
also latency is back to old behaviour as well both ipv4 and ipv6 8ms or under.
C:\Windows\system32>ping -4 -t bbc.co.uk
Pinging bbc.co.uk [212.58.246.78] with 32 bytes of data:
Reply from 212.58.246.78: bytes=32 time=8ms TTL=57
Reply from 212.58.246.78: bytes=32 time=7ms TTL=57
Reply from 212.58.246.78: bytes=32 time=8ms TTL=57
Reply from 212.58.246.78: bytes=32 time=8ms TTL=57
Ping statistics for 212.58.246.78:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 8ms, Average = 7ms
Control-C
^C
C:\Windows\system32>ping -t bbc.co.uk
Pinging bbc.co.uk [2001:41c1:4008::bbc:3] with 32 bytes of data:
Reply from 2001:41c1:4008::bbc:3: time=7ms
Reply from 2001:41c1:4008::bbc:3: time=7ms
Reply from 2001:41c1:4008::bbc:3: time=8ms
Reply from 2001:41c1:4008::bbc:3: time=7ms
Ping statistics for 2001:41c1:4008::bbc:3:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 8ms, Average = 7ms