Drop to 0.0 upload speed for the past month

Upstream connection looks dreadful - can you do this first.

______________________________________________

Switch the Hub off and unplug it from the mains supply for five minutes. Whilst it's off, do a quick check that all of your coax and ethernet cable connections are in nice and "finger" tight - at the Hub and wall box and also at any connectors etc. Ensure there are no “unterminated cable loose ends. Disconnect all the connections and reconnect to be sure. Also check that the internal wiring is ok with no kinking or chaffing. When its light, check that all looks good with the outside cabling and wall box (no “staples, etc.,) piercing the cables. Then switch the Hub back on and leave ~5 minutes When all done, check back in the settings and ensure that the RS error counts and T3 errors have all reset to 0. Then check every hour or so to see if they start reappearing - they shouldn't. If they do (particularly the postRS and T3 ones) you have a problem (noise) that only a Tech visit will sort.
Also check the Upstream QAM’s are all at 64 - if they are still dropping (to 32/16) then see message 3 here…

https://community.virginmedia.com/t5/Networking-and-WiFi/Regular-Intermittent-Upstream-dropouts/td-p/5202486

Please have a look at this thread and then possibly hook up with the poster.

https://community.virginmedia.com/t5/Networking-and-WiFi/Packet-loss-every-day-between-4pm-and-12am-exactly/td-p/5552657

If you are in the same locality as the other person, there is an area issue (the other OP has checked with neighbours and they have the problem too).  If you are in a different locality - as in nowhere near - it gets even more interesting as there is a common mode somewhere.

Focus first on these VM connection items ...

3.0 Upstream channels (QAM 64 is the expected mode, QAM 32 or 16 reflect line noise degradation)

3.0 Upstream channels

These ones are difficult to fix because difficult to pinpoint the noise or whatever is affecting your upstream.  For example, a VM business user on an industrial estate nearby with electrically noisy equipment.  Takes some pinning down.

Just to say, that the 'estimated fix date' is artificial.  I advise you to request the ticket number and priority from the Forum Team.  If it's a 'P4' then the estimate is worthless.  Area noise should be a P1 and there is no estimable fix date until the source of noise has been determined.

Thanks, Beth.   For the benefit of the user, obviously P1 is highest priority and gains management attention. This priority is typically assigned to large scale outages.  P1s also arise when P2s have passed their resolution target time - or so it should be in any good service organisation.  P1s should be resolved within a certain number of hours, in my experience less than 4 - but I don't know VM's policy on this.

P2 sits behind P1 and gains top attention when there are no P1s outstanding.  But they are also worked on if the resources used by P1s don't affect P2s.  In my experience, P2s need resolution within 8 hours and should be worked on within 2 hours of ticket issue.

P3 tickets are supposed to be of a more 'routine' nature, requiring a response within same day or next morning and resolution within 24 hours depending on policy.

SNR issues, as I've stated, are notoriously difficult to pinpoint, requiring special tools and methods for tracking the source down over a potentially wide area and often out of office hours.  In other words, resolution time is indeterminate - yet a priority must be assigned.  It can't be P1/P2 because of the strict resolution targets; it can't be P4 which is the bottom of the pile because it is an area fault.

What I've said won't get it resolved any faster, but it might help knowing how the problem system is supposed to work.