Virgin media issues - ping test?

Soldato
Soldato
Joined
26 Oct 2013
Posts
10,053
Location
Leicester
Hi all

I have had an issue with VM few weeks, they came out yesterday and replaced the hub but it didn't help. Basically, internet works fine, then cuts for 10-1 minute, then fine, cut, fine, cut. Rinse and repeat. When it works, works great. When it's dead, it's dead.

Is there a way I can do constant ping test with timestamps so I can see when and how long the internet drops? I'm aware of ping -t but one with timestamps would be ideal

Thanks!
 
Hi all

I have had an issue with VM few weeks, they came out yesterday and replaced the hub but it didn't help. Basically, internet works fine, then cuts for 10-1 minute, then fine, cut, fine, cut. Rinse and repeat. When it works, works great. When it's dead, it's dead.

Is there a way I can do constant ping test with timestamps so I can see when and how long the internet drops? I'm aware of ping -t but one with timestamps would be ideal

Thanks!

Think broadband monitor should do it. Just go on the site and create one
 
ThinkBroadband is possibly not going to be granular enough if the periods of packet loss are short, it'll also not work if your WAN IP address changes.

I'd do it with powershell. Open 2 powershell windows.

In the first powershell window issue this command:

Code:
ping -t 8.8.8.8 | ForEach {"{0} - {1}" -f (Get-Date),$_} > c:\users\MyUsername\downloads\ping.txt

Change 'MyUsername' to your username, so if your username is ShivP then the command would be:

Code:
ping -t 8.8.8.8 | ForEach {"{0} - {1}" -f (Get-Date),$_} > c:\users\ShivP\downloads\ping.txt

Press enter. It'll appear that nothing is happening but look in your Downloads folder and there will be a file called 'ping.txt' which will contain the following:

15/05/2022 11:56:45 -
15/05/2022 11:56:45 - Pinging 8.8.8.8 with 32 bytes of data:
15/05/2022 11:56:45 - Reply from 8.8.8.8: bytes=32 time=6ms TTL=116
15/05/2022 11:56:46 - Reply from 8.8.8.8: bytes=32 time=6ms TTL=116
15/05/2022 11:56:47 - Reply from 8.8.8.8: bytes=32 time=7ms TTL=116
15/05/2022 11:56:48 - Reply from 8.8.8.8: bytes=32 time=7ms TTL=116
15/05/2022 11:56:49 - Reply from 8.8.8.8: bytes=32 time=7ms TTL=116
15/05/2022 11:56:50 - Reply from 8.8.8.8: bytes=32 time=7ms TTL=116
15/05/2022 11:56:51 - Reply from 8.8.8.8: bytes=32 time=6ms TTL=116

In the second window issue this command:

Code:
ping -t 8.8.8.8 | ForEach {"{0} - {1}" -f (Get-Date),$_}

It does the same thing as in the first powershell window but this time it'll send the output to the screen so you'll effectively be seeing the contents of the logfile. The idea of that is that you know when there's been a period of packet loss. If you're not bothered about seeing it in real time then ignore the second window.

When you want to stop the pings press CTRL C.
 
ThinkBroadband is possibly not going to be granular enough if the periods of packet loss are short, it'll also not work if your WAN IP address changes.

I'd do it with powershell. Open 2 powershell windows.

In the first powershell window issue this command:

Code:
ping -t 8.8.8.8 | ForEach {"{0} - {1}" -f (Get-Date),$_} > c:\users\MyUsername\downloads\ping.txt

Change 'MyUsername' to your username, so if your username is ShivP then the command would be:

Code:
ping -t 8.8.8.8 | ForEach {"{0} - {1}" -f (Get-Date),$_} > c:\users\ShivP\downloads\ping.txt

Press enter. It'll appear that nothing is happening but look in your Downloads folder and there will be a file called 'ping.txt' which will contain the following:



In the second window issue this command:

Code:
ping -t 8.8.8.8 | ForEach {"{0} - {1}" -f (Get-Date),$_}

It does the same thing as in the first powershell window but this time it'll send the output to the screen so you'll effectively be seeing the contents of the logfile. The idea of that is that you know when there's been a period of packet loss. If you're not bothered about seeing it in real time then ignore the second window.

When you want to stop the pings press CTRL C.
Great, that's really useful thanks. I've booked the virgin media bloke in again so hopefully they'll be able to fix it
 
I'd recommend using SmokePing if you've got a machine to run it on 24/7 locally, can run it in Docker.
 
Are you using the SH in router mode or your own router?
Are your wired devices connected directly to the router using physical cables and not abomination like power line?
When it cuts out, what are you doing?
Is it all wired/wireless devices?
What do the modem logs show?
Presumably you - or someone else on your network - aren't doing something silly like saturating your uplink?

Ping based tools are great for some issues, but realistically at this point it's only going to tell you what you already know. What you actually need to understand is if this is a network issue on the VM side or your side. The answer to that dictates how you proceed.
 
Ping based tools are great for some issues, but realistically at this point it's only going to tell you what you already know.
You're not going to see the effect of any changes you or the ISP may make without tools to monitor your connection.
If your intention is to fix something you should always be monitoring to see the impact of anything you change.
It's also evidence that you can use to show the ISP.
 
You're not going to see the effect of any changes you or the ISP may make without tools to monitor your connection.
If your intention is to fix something you should always be monitoring to see the impact of anything you change.
It's also evidence that you can use to show the ISP.

In this scenario that’s largely irrelevant, op has clearly stated the connection is either up or down. The first thing to establish is if the connection is dropping at the router or before and try to establish why.
 
In this scenario that’s largely irrelevant, op has clearly stated the connection is either up or down. The first thing to establish is if the connection is dropping at the router or before and try to establish why.
It's definitely not 'largely irrelevant', it may not be the solution to his problem, but I don't think anyone was saying that.
Why shy away from someone monitoring their question especially if they're experiencing packet loss though?
It may narrow things down to understanding how often they face the issue, what times the issue may be most prevalent (during the day peak time etc...) or if it's just something that's persistent.

Never said what you're suggesting is wrong in terms of making sure he's plugged in via Ethernet, making sure no one is saturating the link etc, which are all important questions...
 
It's definitely not 'largely irrelevant', it may not be the solution to his problem, but I don't think anyone was saying that.
Why shy away from someone monitoring their question especially if they're experiencing packet loss though?
It may narrow things down to understanding how often they face the issue, what times the issue may be most prevalent (during the day peak time etc...) or if it's just something that's persistent.

Never said what you're suggesting is wrong in terms of making sure he's plugged in via Ethernet, making sure no one is saturating the link etc, which are all important questions...

You seem to be missing the point. Look at it another way, will a ping test tell you the i225 chipset is inherently flawed in its previous hardware revisions or that the power line adapters loose sync or something nearby like a failed suppressor on the fridge compressor causes all hell to break loose? No. The first thing that needs to be established is if the ‘loss’ is across both wired and wireless interfaces by connecting to the router as directly as possible, then interrogating the logs to see if the WAN connection is dropping when the loss of connectivity occurs. If it isn’t, then it’s not a VM issue and we need to look at the LAN side. If it is, then it’s a VM issue and it needs escalating. Your suggestion just tells op when the connection isn’t working… which op already knows, it has no significant value at this stage in the process and is therefore largely irrelevant as I said.
 
Are you using the SH in router mode or your own router?
Are your wired devices connected directly to the router using physical cables and not abomination like power line?
When it cuts out, what are you doing?
Is it all wired/wireless devices?
What do the modem logs show?
Presumably you - or someone else on your network - aren't doing something silly like saturating your uplink?

Ping based tools are great for some issues, but realistically at this point it's only going to tell you what you already know. What you actually need to understand is if this is a network issue on the VM side or your side. The answer to that dictates how you proceed.
I have tried Hub 3 in both router mode, and it previously was on modem mode through the USG Pro 4
Ethernet all round through switches. I have plugged my laptop directly into the Hub 3 and the dropouts mimic those on my desktop which goes through 2 switches
When it cuts out, anything. Could even be nothing (eg overnight)
Mix, using ubiquiti access points and ethernet. All devices drop
Not sure where to find modem logs
Yes correct, no change in usage since we started
 
I have tried Hub 3 in both router mode, and it previously was on modem mode through the USG Pro 4
Ethernet all round through switches. I have plugged my laptop directly into the Hub 3 and the dropouts mimic those on my desktop which goes through 2 switches
When it cuts out, anything. Could even be nothing (eg overnight)
Mix, using ubiquiti access points and ethernet. All devices drop
Not sure where to find modem logs
Yes correct, no change in usage since we started


1. Enter 192.168.0.1 into the address bar of your browser, the settings page will then load.

If you’ve enabled Modem Mode on the Hub you’ll need to use 192.168.100.1 instead.

2. When prompted, enter the settings password shown on the bottom of the Hub/Super Hub.
 
Back
Top Bottom