Forum Discussion

Bill_Carson's avatar
Bill_Carson
On our wavelength
5 years ago
Solved

SYNC Timing Synchronization failure - Loss of Sync

Hi All,

 

first post here, and its for syc timing errors. this issues started a few days ago , the internet was cutting out and then coming back. i have rebooted all the kit. switched it off for 10 mins and then turned it back on etc etc. still getting the same issue. called VM and the automated system said they needed to send a signal to the kit, did that and it rebooted everything. still same issue.

Network Log:

Time

Priority

Description

22/06/2020 10:35:56

Warning!

RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

22/06/2020 10:35:56

critical

SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

22/06/2020 09:00:45

Warning!

RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

22/06/2020 06:41:17

Error

DHCP REBIND WARNING - Field invalid in response;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

21/06/2020 23:10:52

Error

DHCP RENEW sent - No response for IPv4;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

21/06/2020 18:03:14

Warning!

RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

21/06/2020 17:58:32

critical

SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

21/06/2020 17:28:4

Warning!

RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

21/06/2020 15:40:31

Error

DHCP RENEW sent - No response for IPv4;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

21/06/2020 09:14:47

Warning!

RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

21/06/2020 09:13:50

critical

SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

21/06/2020 08:22:22

Warning!

RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

21/06/2020 00:39:48

Error

DHCP RENEW sent - No response for IPv4;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

20/06/2020 21:58:27

Warning!

RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

20/06/2020 21:58:27

critical

SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

20/06/2020 21:57:0

Warning!

RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

20/06/2020 21:18:8

critical

SYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

20/06/2020 21:16:36

Warning!

RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

 

 

  • It obviously isn't a WiFi problem. Can you check that all your coax connections are tight?

  • Andrew-G's avatar
    Andrew-G
    5 years ago

    Synchronisation failure is where the hub can't maintain a lock on one or more of the 28 channels it uses to connect with the gear in the street cabinet.  And when it does lose synch, that loss of one or more channels becomes a "partial service".  What that means for the customer is slowdowns, disconnection and poor latency.  The hub does try and renegotiate the lost channel, but that takes time, and the problem will recur.

    The underlying cause is usually noise on the upstream, because it is those channels that the hub uses to communicate with the gear in the street cabinet.  The upstream looks OK on the data you've posted, but that's most likely because you've recently rebooted the hub (I can tell that from the low error counts).  Rebooting causes the hub to renegotiate all 28 channels, and usually provides a temporary fix, but because the underlying cause isn't fixed, it will recur.  Replacing the hub won't make a blind bit of difference - that's a cheap fix by agents who know nothing about the technology.  If they'd looked at your network log and knew what it meant they'd have sent out a technician to find the real problem.  

    You can try dialling it in, but chances are you'll get more of a run around by the utter clowns that VM use as offshore technical support.  Better to wait (maybe a day or two) for the UK based VM forum staff to get round to this post and advise on next steps.  They're usually very helpful, but don't accept the excuse "I've had a look and everything appears OK from our side" - the Network log is crystal clear on the fault and the impact on your service, and that's been recorded by VM's own equipment.  You need a technician.

  • Andrew-G's avatar
    Andrew-G
    5 years ago

    There's no harm in plugging in the replacement hub (other than the inconvenience of setting it up, getting it activated, and reconnecting all your wireless devices).  And at least you've then gone along with VM's initial (if misguided) effort to resolve the problem.  Who knows, MAYBE it will work, I just don't expect it to.

    If/when it doesn't work then VM have to accept that any subsequent problems aren't down to the hub, and will have to send a technician.

102 Replies

  • Upstream bonded channels

    Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID

    13660000045512064 qam3
    24310000046.5512064 qam2
    33010009846.5512064 qam4
    42359999147512064 qam5
    54960000048.3512064 qam1



    Upstream bonded channels

    Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts

    1ATDMA0000
    2ATDMA0020
    3ATDMA0000
    4ATDMA0000
    5ATDMA0030

    Network Log

    Time Priority Description

    03/05/2024 07:19:28Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    03/05/2024 07:19:28criticalSYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    03/05/2024 06:31:36Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    03/05/2024 06:27:1criticalSYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    03/05/2024 05:04:18Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    03/05/2024 05:04:18criticalSYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 22:57:29Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 22:37:51criticalSYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 20:38:32Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 20:22:7criticalNo Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 19:51:27Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 19:51:27criticalSYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 11:51:40Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 10:53:35criticalSYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 08:04:0Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 07:50:41criticalSYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 07:15:6Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 07:08:14criticalSYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 06:19:16Warning!RCS Partial Service;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    02/05/2024 06:19:16criticalSYNC Timing Synchronization failure - Loss of Sync;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
    • jpeg1's avatar
      jpeg1
      Alessandro Volta

      Something seriously wrong there according to the RS numbers. You could start by removing the unused splitter and connecting the used cable straight into the Hub. 

      • jongosling's avatar
        jongosling
        Tuning in

        jpeg, Unfortunately, the fibre has been covered by floorboards and units, and the splitter is a metre away from the hub, coming from / going to the floor (madness). So unless I remove both in & out cables from the splitter, tape them together and hope to god I can pull them through to the hub, I’ll have to live with it / call out an engineer again to remedy (join the cables?)

  • jpeg1's avatar
    jpeg1
    Alessandro Volta

    You can't join the cables yourself. You could replace the splitter with a back-back connector, but this may not be the whole answer. In your place I'd get a technician in to sort it. May be a £25 cost depending what they find. 

  • jpeg1's avatar
    jpeg1
    Alessandro Volta

    Are you saying that your connection is still working normally even when the BQM shows complete packed loss?

    This suggests that for some reason your WAN IP address is changing. Next time the BQM starts showing red, check the IP and see if it is different from the other times.

    • jongosling's avatar
      jongosling
      Tuning in

      I assumed the same initially, but I can confirm that my current IP address is the same as the BQM graph.

      For example, I have 'gaps' in 100% packet loss on 2, 3 & 4th June. 1st, 5th and 6th (so far) are 24hrs of 100% packet loss.

      • David_Bn's avatar
        David_Bn
        Icon for Forum Team rankForum Team

        Thanks for coming back to us jongosling, and I'm sorry to hear of the ongoing issue.

        Do you have anymore BQM graphs that you can share with us to show the ongoing issue that we can perhaps present to the area field manager to report back to them, upon another potential engineer booking?

        Thanks,

        David_Bn

  • jpeg1's avatar
    jpeg1
    Alessandro Volta

    Time to make a formal complaint and insist on a substantial refund of your payments. This is not a broadband service. 

    • jongosling's avatar
      jongosling
      Tuning in

      I've managed to argue for 3 months 'free' due to this issue. Today, due to the horrendous connection since the most recent engineer visited, I removed the 10dB attenuator from the external connection and reattached the 6dB attenuator internally on the HUB (as was before the most recent engineer visit). This seems to have slightly improved the issues, but the Post-RS errors and T3 timeouts remain.

  • Sephiroth's avatar
    Sephiroth
    Alessandro Volta

    You might care to experiment with the attenuator removed entirely.  Clearly the 10dB attenuator was no longer relevant to your downstream power (they may have moved your cabinet tap point).  However, it is the upstream power that needs watching.  That should fall when you remove the internal attenuator (everything tightly screwed in, of course).   Attenuators can break down chemically, so to speak, and that would cause crosstalk = noise.  The downstream post-RS errors have to come from somewhere.

    Let us know.

    • jongosling's avatar
      jongosling
      Tuning in

      Thanks, I did try without either 10dB or 6dB and it wasn't good. Current upstream power levels range 45.3 - 47.5 dBmV - although the modulation varies from 64qam (see b elow). Downstream 3.7 - 7 dBmV, SNR mostly around 40 all modulation at 256qam. The current setup is the most reliable, but is prone to only last max 48hrs before a HUB reset is required to renegotiate the channels.

      Upstream bonded channels

      Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID

      13660000045.5512064 qam3
      23010000045.3512064 qam4
      34960000047.5512064 qam1
      42360000046.5512016 qam5
      54310000046.5512032 qam2
  • Sephiroth's avatar
    Sephiroth
    Alessandro Volta

    If you can work without an attenuator, it's best to do so.  By that I mean upstream power isn't pushing beyond 50 dBmv and downstream isn't much above 10 dBmv (otherwise noise is amplified to a more significant extent).

    But as you say you've tried that, then there are two usual possibilities:  (1)  Your modem stuffed; (2) there is a circuit problem.

    Can you check with any neighbours to see what's happening there?

    • jongosling's avatar
      jongosling
      Tuning in

      Seph / jpeg,

      The neighbours on VM have stated no issues. Either they're all fine or they're so old they don't notice the issues as they don't stress the connection / rely on it for WFH / streaming...

      Of note, the connection is much more stable with the 6dB attenuator on the hub (VM HUB 3.0, replaced the original HUB 3.0 during the second most recent tech visit about a month ago) and without the 10dB attenuator external to the house (I (re)established this at 0800 today, and the BQM below reflects the improved stability). This setup seems to keep the power levels as you state above. However, I have no doubt that this will begin to fail within the normal 48hrs, as the post-RS errors continue to rise.

      https://www.thinkbroadband.com/broadband/monitoring/quality/share/752393ea1f50bac4ddf1619a031439f0ec964171

       

  • Sephiroth's avatar
    Sephiroth
    Alessandro Volta

    Btw, clearly the 16QAM shows noise on the upstream and the BQM display is typically indicative of the upstream giving grief.  However, if the problem is crosstalk, then noise will occur on both upstream and downstream.  Evidence is there because of the post-RS errors.   

  • jpeg1's avatar
    jpeg1
    Alessandro Volta

    If you are on friendly terms with a neighbour using VM, it would be interesting to know whether they are having similar problems. 

  • So there was a street-wide issue last week that resulted in VM tech changing an amplifier (?) which seemed to temporarily resolve some issues. However, the disconnections have returned, PSB HUB 3 info:

    Downstream bonded channels

    Channel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID

    12030000002.740256 qam9
    2211000000240256 qam10
    32190000002.940256 qam11
    4227000000238256 qam12
    52350000001.738256 qam13
    62430000002.740256 qam14
    72510000003.240256 qam15
    82590000003.540256 qam16
    92670000003.740256 qam17
    102750000003.540256 qam18
    112830000003.740256 qam19
    122910000004.140256 qam20
    132990000004.640256 qam21
    143070000004.540256 qam22
    153150000004.440256 qam23
    16323000000440256 qam24
    173310000004.140256 qam25
    183390000004.140256 qam26
    193470000004.340256 qam27
    203550000004.140256 qam28
    213630000004.440256 qam29
    223710000004.340256 qam30
    233790000004.140256 qam31
    243870000003.740256 qam32



    Downstream bonded channels

    Channel Locked Status RxMER (dB) Pre RS Errors Post RS Errors

    1Locked40.33873928100
    2Locked40.34570151484
    3Locked40.34029723767
    4Locked38.93837538797
    5Locked38.95129534594
    6Locked40.34104814435
    7Locked40.3347839670
    8Locked40.9300538025
    9Locked40.9254036317
    10Locked40.9236185822
    11Locked40.9248946415
    12Locked40.3223046097
    13Locked40.3206275571
    14Locked40.3186584709
    15Locked40.3175174226
    16Locked40.9170253975
    17Locked40.3157843514
    18Locked40.3145723164
    19Locked40.9136582781
    20Locked40.3127102563
    21Locked40.3116962275
    22Locked40.9108332095
    23Locked40.3104581907
    24Locked40.388511620

    Upstream bonded channels

    Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID

    14960000049512064 qam1
    23660000047512064 qam3
    34310000048.3512064 qam2
    43010000147.8512064 qam4
    52360000049.3512064 qam5



    Upstream bonded channels

    Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts

    1ATDMA0000
    2ATDMA0080
    3ATDMA0040
    4ATDMA0080
    5ATDMA0030