TPG Community

Get online support

200ms latency during evenings from around 5pm till 12:30am

alanguide
Level 8

That aim here is to fix your latency problem, and the important thing is *are your results on Wi-Fi or wired connections?* If Wi-Fi then local interference remains the most likely cause. If wired then we need to consider another cause. If WIfi, as an alternative can you lash up an Ethernet connection and try that?

going2churn
Level 2

You didn't ask me that though, and only posted now. You didn't phrase your response as a question to me, you phrased it as a retort.

 

My results are indeed on wi-fi, all of them are. That's why I was posting traceroutes on here, rather than something like Reddit, so someone at TPG could get information to help fix the problem.

 

I've been using the Internet for a very long time, since the WWW was first available, and you'd run through your bad connection, and they'd say it is dependent on distance to exchange, port in exchange, so on, so forth. And then you'd switch provider and everything would be better (I was with iiNet for quite some time back in the day), did the new provider make the exhange closer to your home? No. For some reason the main aim of tech support for ISPs is retention of the client by buying time, and obfuscation, rather than by fixing problems.

 

I even had a time, where my Internet was shot with shocking latency, and they ran their line test, and it was super a-ok. It can't possibly be the line they said. The tech came out and the adsl line was hanging on by a thread, he was amazed I was even getting any Internet at all.

 

If your modems aren't fit for wifi, don't supply them.

 

 

alanguide
Level 8

@going2churn wrote:

 

My results are indeed on wi-fi, all of them are. That's why I was posting traceroutes on here, rather than something like Reddit, so someone at TPG could get information to help fix the problem.

...

If your modems aren't fit for wifi, don't supply them.

 

I'm not with TPG staff. Just a normal user trying to help you find the problem. TPG (or any other RSP) would have no way of finding the source of possible local interference at your end, and there is no router/modem that would automatically eliminate local interference. It would be great if you could wire up an ethernet connection and try that at the historically bad times. Is that easy at your end?

 

 


 

going2churn
Level 2

No it isn't. And I don't think that is the cause of the issue either. While I appreciate that as a normal user you are trying to help. Your help is also limited by the fact that you are a normal user. As to why TPG isn't helping is beyond me.

 

When I switch, and I will probably be contacting Aussie Broadband tonight. I will post a traceroute on here whether it is good, bad or otherwise. To show whether it was local interference or TPGs network. I have no real idea one way or the other to be honest with you. But I do have a hunch.

 

alanguide
Level 8

Sorry I couldn't help you. I'm a normal user but I am technical. My original statement remains the same. The most likely reason for time-based Wi-Fi latency problems is indeed  local WiFi interference. I hope you get this resolved, but if that is the cause in your case it will be the same with the other RSP, if the WiFi settings are the same. It's a pity you are not easily able to lash up Ethernet to try for yourself. I wish you well, whatever. It is frustrating to have an internet problem.

going2churn
Level 2

You're a good person Alanguide. They should hire you. I know it will be the same if I switch if the local interference is the issue. Then I will also invest in a better WiFi modem too (this TPG one is bad to be honest, it's worse than the TPG supplied one we had in Brisbane), if I have a to.

 

That's just the way it is however. They supplied the modem, they also had the opportunity to fix an issue. I'm just glad the consumer has the ability to switch.

 

david64
Master

@going2churn .

Presumably, the NBN box is in an inconvenient spot, along with the router, which is why you are all on wifi. Can the router be relocated using a longer ethernet cable?
You can put the wifi interference to bed with some testing using a wifi laptop.
Use this command in Windows: netsh wlan show all
It shows surrounding networks and channel and signal strength. You can check at different places around the house.
Do it when you are getting good and bad response times. Compare the results. When response time goes off, is there any difference with the other networks?


You can also use ping to check performance. Open 2 command windows.
In one, ping the router: ping -t 192.168.1.1
In other, ping -t the second address on the tracert display, ie, the address in external network.
Use Control C to stop.
Have the laptop as close to router as possible (speed drops with distance). Use 5GHz band if possible (faster).
Run the test for a few minutes each time. Try to arrange for other users to cease their activity while test runs. You could just leave them running until problem arises.
Response times vary a bit because one computer is doing two things. Other users will cause response times to vary.
Each ping will settle to its own average value. When response time goes off, I expect the router response time to be same and other response time goes high. Wifi interference would cause ping to router to increase.

going2churn
Level 2

Here's the ping to the router:

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=16.3 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.970 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.70 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.61 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=1.02 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.67 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.05 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.06 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=1.05 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=1.03 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=0.982 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=1.04 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=1.51 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=1.01 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=1.01 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=0.983 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=1.01 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=1.01 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=0.900 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=0.923 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=1.16 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=0.835 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=1.01 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=1.06 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=0.877 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=0.929 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=1.84 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=0.996 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=0.856 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=0.921 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=64 time=1.61 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=64 time=1.50 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=64 time=1.58 ms
64 bytes from 192.168.1.1: icmp_seq=34 ttl=64 time=1.82 ms
64 bytes from 192.168.1.1: icmp_seq=35 ttl=64 time=0.922 ms
64 bytes from 192.168.1.1: icmp_seq=36 ttl=64 time=1.02 ms
64 bytes from 192.168.1.1: icmp_seq=37 ttl=64 time=0.985 ms
64 bytes from 192.168.1.1: icmp_seq=38 ttl=64 time=0.948 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=0.808 ms
64 bytes from 192.168.1.1: icmp_seq=40 ttl=64 time=1.13 ms
64 bytes from 192.168.1.1: icmp_seq=41 ttl=64 time=0.941 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=64 time=0.967 ms
64 bytes from 192.168.1.1: icmp_seq=43 ttl=64 time=0.885 ms
64 bytes from 192.168.1.1: icmp_seq=44 ttl=64 time=1.95 ms

 

Here's the ping to the first hop outside of the router.

 

traceroute to www.google.com.au (142.250.70.163), 30 hops max, 60 byte packets
1 _gateway (192.168.1.1) 0.988 ms 0.931 ms 1.269 ms
2 10.20.26.173 (10.20.26.173) 87.617 ms 87.953 ms 93.142 ms
3 27-32-160-199.static.tpgi.com.au (27.32.160.199) 93.677 ms 93.581 ms 93.574 ms
4 74.125.51.92 (74.125.51.92) 93.704 ms 93.589 ms 93.581 ms
5 * * *
6 142.250.230.160 (142.250.230.160) 93.455 ms 92.905 ms mel04s02-in-f3.1e100.net (142.250.70.163) 92.641 ms

 

PING 10.20.26.173 (10.20.26.173) 56(84) bytes of data.
64 bytes from 10.20.26.173: icmp_seq=1 ttl=254 time=119 ms
64 bytes from 10.20.26.173: icmp_seq=2 ttl=254 time=99.7 ms
64 bytes from 10.20.26.173: icmp_seq=3 ttl=254 time=110 ms
64 bytes from 10.20.26.173: icmp_seq=4 ttl=254 time=92.1 ms
64 bytes from 10.20.26.173: icmp_seq=5 ttl=254 time=114 ms
64 bytes from 10.20.26.173: icmp_seq=6 ttl=254 time=113 ms
64 bytes from 10.20.26.173: icmp_seq=7 ttl=254 time=104 ms
64 bytes from 10.20.26.173: icmp_seq=8 ttl=254 time=99.1 ms
64 bytes from 10.20.26.173: icmp_seq=9 ttl=254 time=115 ms
64 bytes from 10.20.26.173: icmp_seq=10 ttl=254 time=111 ms
64 bytes from 10.20.26.173: icmp_seq=11 ttl=254 time=93.4 ms
64 bytes from 10.20.26.173: icmp_seq=12 ttl=254 time=98.8 ms
64 bytes from 10.20.26.173: icmp_seq=13 ttl=254 time=110 ms
64 bytes from 10.20.26.173: icmp_seq=14 ttl=254 time=95.3 ms
64 bytes from 10.20.26.173: icmp_seq=15 ttl=254 time=101 ms
64 bytes from 10.20.26.173: icmp_seq=16 ttl=254 time=101 ms
64 bytes from 10.20.26.173: icmp_seq=17 ttl=254 time=103 ms
64 bytes from 10.20.26.173: icmp_seq=18 ttl=254 time=93.4 ms
64 bytes from 10.20.26.173: icmp_seq=19 ttl=254 time=102 ms
64 bytes from 10.20.26.173: icmp_seq=20 ttl=254 time=98.2 ms
64 bytes from 10.20.26.173: icmp_seq=21 ttl=254 time=97.9 ms
64 bytes from 10.20.26.173: icmp_seq=22 ttl=254 time=94.9 ms
64 bytes from 10.20.26.173: icmp_seq=23 ttl=254 time=101 ms
64 bytes from 10.20.26.173: icmp_seq=24 ttl=254 time=107 ms
64 bytes from 10.20.26.173: icmp_seq=25 ttl=254 time=92.6 ms
64 bytes from 10.20.26.173: icmp_seq=26 ttl=254 time=92.9 ms
64 bytes from 10.20.26.173: icmp_seq=27 ttl=254 time=83.0 ms
64 bytes from 10.20.26.173: icmp_seq=28 ttl=254 time=86.9 ms
64 bytes from 10.20.26.173: icmp_seq=29 ttl=254 time=79.4 ms
64 bytes from 10.20.26.173: icmp_seq=30 ttl=254 time=86.1 ms
64 bytes from 10.20.26.173: icmp_seq=31 ttl=254 time=99.6 ms
64 bytes from 10.20.26.173: icmp_seq=32 ttl=254 time=95.2 ms
64 bytes from 10.20.26.173: icmp_seq=33 ttl=254 time=97.9 ms
64 bytes from 10.20.26.173: icmp_seq=34 ttl=254 time=96.7 ms
64 bytes from 10.20.26.173: icmp_seq=35 ttl=254 time=103 ms
64 bytes from 10.20.26.173: icmp_seq=36 ttl=254 time=87.6 ms
64 bytes from 10.20.26.173: icmp_seq=37 ttl=254 time=92.2 ms
64 bytes from 10.20.26.173: icmp_seq=38 ttl=254 time=91.4 ms
64 bytes from 10.20.26.173: icmp_seq=39 ttl=254 time=84.4 ms
64 bytes from 10.20.26.173: icmp_seq=40 ttl=254 time=87.6 ms
64 bytes from 10.20.26.173: icmp_seq=41 ttl=254 time=101 ms
^C
--- 10.20.26.173 ping statistics ---
41 packets transmitted, 41 received, 0% packet loss, time 40057ms
rtt min/avg/max/mdev = 79.390/98.322/118.580/9.042 ms

 

kate_
Moderator

Hey @going2churn, we appreciate your patience so far, our Team has been a bit busier than usual over the last few days. We are dedicated to getting this resolved for you as quickly as possible, so you don't need to worry about switching providers.

 

If you can send a PM our way, we will run some tests on your service to find out what's going on when your latency is higher in the evening.

 

- Kate_

magichands
Level 2

I'm having the same problem and they were trying to tell me it was probably my wifi router etc LOL. Anyone with half a brain can tell this is a TPG issue.  It's not even an NBN issue.