Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[cbdeakin]

I've been getting hundreds of packet discards per minute (reported by my Asus DSL-N16 router) on a FTTC line (connected to an ECI cabinet), but only when uploading files. Router settings are all at default.

In general I've noticed some packet loss on the line during video calls and streaming services like Google Stadia (connected to the router via ethernet). I reported the issue to my ISP (also mentioning that the line at the time was syncing below BT's 'downstream handback threshold', who sent a couple of engineers to investigate.

This is what their fault notes said:

Engineer has resolved the fault located at the D-side, including aerial cables / lead-in / block terminal.

There was a fault outside the customer's curtilage caused by general wear and tear. This was fixed by changing the pair node to node. Customer's router is plugged into the NTE master socket.

All tests were passed to confirm line is ok.

I also get retransmissions constantly when I run an Mlab test (via the London server apparently), found here:
https://speed.measurementlab.net/#/

I've asked about the reliability of this tested on another forum, only to be warned not to post or mention that test again (I don't think people liked the results of the test reported to them). Apparently, this test only uses a single connection, compared to many tests that allow multiple streams. Full explanation here:
https://support.measurementlab.net/help/en-us/6-measurement-services/11-why-are-my-m-lab-results-different-from-other-speed-tests

One interesting thing I discovered before any work was done on the line, is that limiting the upstream modem sync speed to around 500kbps reduced the retransmissions reported by Mlab's test to 0%. I also noticed no packet loss while streaming in Stadia. The line is not really usable like this though, as this constrains download speeds.

[j0hn]

Have you tried another modem/router and if so do you experience the same thing?

The Asus contains a Mediatek MT7510 xDSL chipset which isn't exactly favourable on these forums.
My Asus DSL-AC68U had the same chipset and it was a better doorstop than it was a modem.

Does the Asus report any CRC errors (shown in the DSL statistics page) during periods of packet loss?

I'd recommend trying another modem/router if you have 1, not just because it's 1 of the Asus devices but because that's generally a great way of ruling out that specific piece of hardware to help determine if the actual line is the issue.

The only thing that should be causing packet loss from the DSL side is ES/CRC errors.
If that's fine then the next layer to look at would be the PPP session to your ISP.

Setting up a Broadband Quality Monitor / BQM on the ThinkBroadband site is a great way to get a visual graph of packet loss on the line and can help pin point issues.
You would need to enable ICMP ping responses on the Asus for that to work.

[cbdeakin]

Thanks for your advice.

All I can say regarding other routers I've tried is that they had similar line stats (slightly different attenuation). I was still getting packet loss / retransmission on the last router I tried, which was a Broadcom based Technicolor router that the ISP sent. I could see this in both Google Stadia and Mlab's line test. Changing the routers again is not really an option for me, as it effects others using the line.

In terms of errors, there's currently 37 CRC upstream errors after about 4 hours, 50 minutes. The line had over 2 billion downstream FEC errors after about 2 days, before I resynced the line.

I setup a BQM a couple of days ago. Here's the results for the 17th of Feb.

https://www.thinkbroadband.com/broadband/monitoring/quality/share/1ed40b227eda5f344fbaad7a25e45b4fc397c6f3-17-02-2022

There's a lot of packet loss / drops when I was downloading a large file (GTA V) for a few hours yesterday, after 5PM.

And today:
https://www.thinkbroadband.com/broadband/monitoring/quality/share/9430aae8057fd69f9636238a211ba6f0f32248cd-18-02-2022

I resynced the line with Bitswap enabled earlier, which is why there's 100% loss for about 1 minute at about 6PM, to see if that would help.

[burakkucat]

Both of those links return a "404 - Page Not Found" to me. 

[cbdeakin]

Sorry, corrected with shareable links above.

[burakkucat]

Thank you. Both are now viewable.

I resynced the line with Bitswap enabled earlier, . . .

All xDSL circuits should have bit swapping enabled. I cannot think of one valid reason for it to be turned off.

[cbdeakin]

I've had issues with it in the past on a previous router (TP Link Archer VR200), which used to report thousands of CRC errors on sync when it was left enabled. But I'm sure this is a debate for another day...

The downstream has an interleaving depth of 2899 at the moment.

I forgot to mention that there was no change in the SNR graph on my router, or the line attenuation, after the engineers completed their work.

[cbdeakin]

So, why would hundreds of packets per minute get discarded by the router when uploading files?

Does this even matter, if it doesn't correspond with an increase in CRCs?

EDIT - So, I fixed the 'outDiscards' issue by simply limiting the router's upload rate to 16mbps (the line syncs at 17mbps for the upstream) via the QOS settings.

[j0hn]

The line had over 2 billion downstream FEC errors after about 2 days, before I resynced the line.

That's roughly 700,000 FEC per min which is on the high side but not unheard of.
My line often received 100,000 FEC per min but that would jump to 1,000,000 per min if my Powerline adapters/Homeplugs were connected.
Do you have any powerline adapters running in the home?

I resynced the line with Bitswap enabled earlier, which is why there's 100% loss for about 1 minute at about 6PM, to see if that would help.

As mentioned already bitswap should always be enabled.

The downstream has an interleaving depth of 2899 at the moment.

That sounds like it might be High Interleaving.

Could you provide a screenshot of the DSL Statistics page or post all of the stats available on that page. Also could you post your DSL settings.

So, I fixed the 'outDiscards' issue by simply limiting the router's upload rate to 16mbps (the line syncs at 17mbps for the upstream) via the QOS settings.

That was going to be 1 of my recommendations.

Your BQM between 5pm - 9pm on the 17th looks really really bad. The green line is almost always perfectly flat on an FTTC circuit.
For 4 hours every ping every second almost doubled in response time. On average it more than doubled. It also shows around 1% to 3% had no response at all (packet loss).

That doesn't look like it's an issue with the copper pair/xDSL circuit. It's either buffer bloat on your router or congestion from your provider.
You could also try capping your downstream throughput to a couple Mb/s below what the line can achieve.

What do the routers CPU and RAM usage graphs look like when you're maxing out a download like that?

[cbdeakin]

Tried downloading with no download rate limit, but it always effects the line like this.

So, I limited the download bandwidth to 85%, then tried downloading. So far, no noticeable packet loss.

Then tried a game on Stadia, only got about 0.04% packet loss (just 40 packets) during a 10 minute stream (this can be checked with the the Stadia enhanced extension).

This is today's BQM graph:
https://www.thinkbroadband.com/broadband/monitoring/quality/share/4c5a080f93553f2b22f54271ac76e27603fc4d00-19-02-2022

Regarding the FECs, I think bitswap must help to reduce these. I also enabled ESNP (stability mode) on my router earlier.

[cbdeakin]

So, the Mlab Chrome extension doesn't report any packet retransmissions, which is good news. Link here:

https://chrome.google.com/webstore/detail/m-lab-measure/leijmacehibmiomcnpaolboihcdepokh/related

I suppose the Mlab website test is just faulty, or outdated...

[cbdeakin]

So, the line stability is looking fairly good now, after applying QOS downstream limits of 85% and an upstream limit of 11mbps. I had to reduce the upstream a bit further to stop the router discarding packets, but it appears to be coping with these settings.

Here are my line stats, 21 hours after the last sync:



So, I think what I will do at this point is request a DLM change to the most stable DLM profile available, which I think is likely to clear up the upstream CRCs (and probable Errored Seconds).

I think the current profile is set to standard at the moment.

[gt94sss2]

Have you tried disconnecting the modem and leaving it off overnight?

Sounds odd, but sometimes letting the DSLAM port 'rest' overnight can help

[Reformed]

The discards are your router being unable to send packets fast enough and them overwhelming its buffers. That is not normal behaviour - downloading shouldn't cause such high upload rates that it overwhelms your bandwidth.

[Alex Atkin UK]

So, I think what I will do at this point is request a DLM change to the most stable DLM profile available, which I think is likely to clear up the upstream CRCs (and probable Errored Seconds).

I think the current profile is set to standard at the moment.

Considering its interleaved at a really high level, AFAIK that IS the most "stable" profile available.  The only way it would be more stable is banding which should not be necessary, something odd is going on.  But as has been said before, ASUS DSL modems are highly suspect.