DSL loses sync a few times a week for extended periods of time

1

I have a 12/2 bonded DSL service from Frontier which loses sync 3-4 times a week for 1-3 hours on average. I have been working with the local techs who say they have checked everything and that they have 'done all they know how to do'. They replaced the gateway once. I have replaced the wire from the NID to the inside jack. Currently I am working with level two support. They have verified the loss of sync issue — but say that the only test that fails is the sync test (and they can no longer ping my gateway). Level 2 support is recommending replacing the modem (this will be the 3rd) and testing the inside wiring. Level 2 support is also suggesting that the signal to noise ratio may be to high to push a 12/2 (which is really 3 up at this point) and that I may have to switch to the 6/1. None of the 6 or so techs that have been to the house have mentioned the signal to noise ratio being an issue.

Details

  • Replacing the wire to the NID seemed to help my overall speed a bit. Generally, I am getting almost 12 down, and 3 up.
  • Level 2 support showed 1 sync issue at 1am, when no one was actively using the connection. However my computer may have been updating.
  • Generally, the gateway loses sync and then continually tries to resync for 2-4 hours on one or both sides.
  • Recently the modem rebooted by itself when I was streaming a video from my computer to AppleTV and someone else was streaming a video on demand. One side lost sync for several hours. We could not replicate this crash
  • Recently it lost sync for 3 hours when I opened approximately 15 tabs to unique web pages.
  • The majority of the sync issues happen later in the afternoon — between 4 and 6pm
  • I am using the Actiontec F2250 Gateway.
  • Provisioned link speed: 13923 / 2282 kb.
  • Rebooting the Gateway has no effect in resolving the sync issues.
  • There appears to be an issue with buffer bloat
  • 2.8% packet loss on ping while downloading software update or uploading
  • High latency during download or upload
  • 7400 feet to DSLAM
  • The side with better SNR will go down, and the side with worse SRN will stay up. (See screen shot)

    UPDATE 12-14-2016
  • New router on Dec 14 — after installation of new router there were fewer bit errors on line 1, and improved SNR on line 2.
  • 2 hours after new router installed both lines went 'silently down' and immediately re-synced, For line 1: After 14 minutes of up time, there are 239,738 bit errors, 2984 HEC errors, 8121 Super frames errors ( SNR Margin is 11.8 ). Line 2 which has been up for 10 minutes, has 1225 bit errors, 21 HEC errors, 4097 Super framers error (SNR Margin is 10.3 ).
  • Error: xt_TCPMSS: bad length (589 bytes), two minutes before last sync issue

    UPDATE 12-17-2016
  • On the 12-14 tech visit, I asked the tech if he could switch out the DSLAM card for line 1 and if there was a another line available. (There was an obvious issue with line 1.
  • On 12-15 the router lost sync around 7pm.
  • Something has changed for the positive after this sync loss — the gateway has now been up for 1 day and 15 hours. I am hoping it has been resolved.

    UPDATE 12-18-2016
  • Lost sync today for 1.5 hours.
  • High error seconds (up to 521) around this issue on BOTH lines
  • Screenshot below

enter image description here

enter image description here

enter image description here


Interruptions that I have noticed since I started tracking

Sept 26, 2016 — 2:55pm — Confirmed modem offline. Rebooted modem via admin. Back up at 3:06 with 5.44 down and .52 up. 1 line is down. Intermittent lines at 3:52.  Both lines back before 4:19. Running at 7.5 down, 2.0 up
Sept 28 — 9:20 AM — Low bandwidth. 3.5 Mbps down. Resolved by 9:30    
Sept 30 — 4:35PM: — Low bandwidth 1.5 Mbps down, .81 up. One line down. Back up by 5:00pm    
October 1 6:00pm Low bandwidth. 1 line down. 2.55 down, 1.07 up    
October 4, 5:55 pm — Both lines down. 6:00pm, 1 line down.    
October 11, noon — very low bandwidth. — back up before 12:30
October 11, 3:30pm  down.
October 11, 5:52pm  down — back by 6:45    
October 12, 4:54pm — 1 side down. 2.96Mbps/.89Mbps    
October 13, 5:20pm — very low bandwidth. Unusable. One/both sides down.  1.64Mbps up, 1.76down    
October 18, 5:55pm — very low bandwidth. Unusable. .77 Mbps down, 2.88up. Unable to login to modem    
October 19, 6:30 — low bandwidth, 4.33 down, .72 up. High latency -- 408ms, high Jitter 836ms    
October 23, 6:17 – low bandwidth, 3.37 down, 1.22 up. 1 side down    
October 24, 3:37 – no bandwidth, one/both sides down.    
October 25, 5:25 – no bandwidth down - up works fine, one/both sides down, able to ping. Back by 6:30    
Nov 1, 8:15 — no bandwidth. Both sides down.    
Nov 2, 3:50 — low bandwidth, 3.57 down, 1.31 up One side down.    
Nov 4 — Frontier tech replaced wall jack    
Nov 7, 10:00 — one side down, both sides down. No bandwidth down. No bandwidth up. Cannot connect to modem. 1 side still down at 5:30p.    
Nov 11, 1:40 — both sides down. No bandwidth — back at 1:43
Nov 11, 5:40 — both sides down. No bandwidth — back by 6:20    
Nov 15, 4:30 — both sides down.    
Nov 18 3:50 — both sides down, one side back by 4:00    
Nov 23 10:00p — very low bandwidth    
Nov 24, 8:56a — both sides down.
Nov 24, 4:50p — both sides down.    
Nov 25, Noon — 1 side down. Low bandwidth, then both sides down.    
Nov 27, 2:40  both sides down
Dec 2, 5:55  One side down    
Dec 4 — Replaced wire from NID to gateway (1 wire now).    
Dec 6 6:30 - Router went offline, rebooted automatically (Crashed, this has happened before, but rarely). 
Dec 6 6:55 - One side down    
Dec 8 — two short drops possible. (Lost connectivity with GotoMeeting)    
Dec 9 — 2:40 — Down — appeared to happen by sending multiple HTTP requests. Still down at 5:45. Keeps trying to sync.

Packet loss

enter image description here

enter image description here

Side with better SNR shows less up time

enter image description here Bad length

Scott Simpson

Posted 2016-12-10T18:51:43.850

Reputation: 111

2I have bad news for you. This is only something your ISP can identify and fix. – Ramhound – 2016-12-10T18:55:56.553

2"the local techs who say they have checked everything" -- Get the details. Did they "condition" the lines, i.e. perform a (TDR) scan to locate and remove bridged taps (and load coils)? Read http://www.exfo.com/corporate/blog/2010/bridged-tap-detection-made-simple – sawdust – 2016-12-10T20:19:41.180

3This is not a PC or internal network error, not at all, it is purely outside or DSL equipment... there is a line problem outside, the L1 vs L2 side-by-side proves it, they should be nearly identical, but L2 has a much higher SNR, probably indicative of a tap off the pair in the field somewhere. And @sawdust is absolutely correct, a simple run with a TDR SLA on each line should show something, if not, they should start at the MDF and trace the pairs from the CO to the premise one AP/CP, ped, or terminal at a time and verify the line is spliced properly and clean. If I had a $ for every time... – acejavelin – 2016-12-11T21:28:07.250

1Impressive details. (Especially the logs. At least, it's impressive by the standards of typical questions here.) Good job. – TOOGAM – 2016-12-14T02:51:44.437

I have come to realize that the main source of interference is from a neighbor's ham radio. And — it turns out they had not correctly identified the drop from the NID to the pedestal as being the old 'C style' which does not shield interference. – Scott Simpson – 2017-01-28T00:37:33.033

Answers

1

Scott - I'm a co-founder of Firebind. Our new cloud solution focuses on continuous testing of last-mile ISP circuits. We do a series of 11 tests every 5 minutes, gathering 3,168 data points a day. I agree that this sounds like a problem only the ISP can fix. But if you'd like to gather more data and see the patterns over a few days or even a few weeks, feel free to use our free trial. Our flagship test simulates a G.711 VoIP call for 25 seconds in each direction every 5 minutes, sending a total of 360,000 packets a day across the intervals. Since the test is 50 packets per second using UDP (as opposed to ICMP) payloads, it provides a much more reliable view of actual user data loss.

By testing every 5 minutes for a few days, you might end up seeing certain time-of-day patterns that could possibly be cross-referenced with something happening on the ISP network.

The link below shows a screenshot of the results of our simulated G.711 VoIP call. The left part of the chart before Dec 4 was a Wave Broadband connection in California. The blue spikes show download loss due to the "Netflix effect".

Then on December 4th that site switched to Comcast and you can see the loss problem almost completely went away.

Packet Loss Wave Broadband then Comcast

best of luck,

Dave

Dave

Posted 2016-12-10T18:51:43.850

Reputation: 11

Asked: 2016-12-10T18:51:43.850

Viewed: 716 times

Active: 2016-12-19T02:24:23.557