Line drops under load (random)

I have been having PPP drops on my Asus RT-AC68U so I converted it to a wifi AP and turned my ZyXel VMG-1312-B10A into a router which was being used as a bridge modem. I have 3 Zyxels and earlier in the year PPP was dropping so I swapped out the modems and it stopped. But recently it started happening again so I reconfigured the Zyxel as a router but it dropped at 8.34 this morning. I have a script to download a 1gb at 32 minutes past the hour every hour and the ZyXel was fine up til 8.34 this morning. It usually gets to about 800mb downloaded and then the PPP drops and its very random.

I have swapped the Zyxel with a 3rd 1312 and it has been fine all today, further testing needed. I have been talking to my ISP and they want to send an engineer but I doubt they will have the skills to diagnose this type of fault as it only drops when under load. Could it be I am not powering off the Zyxel often enough?

In reply to a post by Banger:

Could it be I am not powering off the Zyxel often enough?

No. Assuming this is FTTC (VDSL) then you might need a different make of modem, there seems to be a problem with the Zyxel's on your line.

See if you can get a Huawei HG612 from the famous auction site.

In reply to a post by jchamier:

In reply to a post by Banger:

Could it be I am not powering off the Zyxel often enough?

No. Assuming this is FTTC (VDSL) then you might need a different make of modem, there seems to be a problem with the Zyxel's on your line.

See if you can get a Huawei HG612 from the famous auction site.

I have an HG612 in the den but it is a bit slower on sync than the Zyxels, having said that this 3rd Zyxel is slower than the other 2. Looks like my next port of call is to try the HG612 and yes it is VDSL.

Each time you power off, the DLM thinks it’s fault. To keep the best speeds connect the 612 and leave it powered on for the next 7 days.

Right have connected the HG612 lost about 9mb/s speed but its worth a try. Testing for next 7 days.

So far so good.

Disconnected at 7.34 in the middle of a download. DSL on the HG 612 stayed up.

In reply to a post by Banger:

Disconnected at 7.34 in the middle of a download. DSL on the HG 612 stayed up.

Very strange. Good that the DSL stayed connected, but the PPP disconnecting is one for your ISP I would have thought. Depends how technical the ISP help team can get, they may just tell you to use their provided router.

Also happened the other day with a ZyXel router, and again today at 7.34, 11.34 and 15.34.

Edited by Banger (Sat 05-Sep-20 19:14:12)

Well this is getting frustrating. Uno are saying that port error in their session history could be anything. This has been going on for months and I have sent numerous routers back as faulty due to this PPP session disconnect fault.

I have now tried numerous makes of router and modem and it does it with all of them. Uno are also telling me it is unlikely OR will do a port swap or lift and shift as they term it as the line is likely to prove clear. It's like I dont exist and my swapping of routers counts for nothing. I am now using BT OR modem and Asus router with default settings which countless other users must be using successfully. Now considering A&A.

I've had a quick look at this.

In reply to a post by Banger:

Well this is getting frustrating. Uno are saying that port error in their session history could be anything.

It has been explained that this is a standard RADIUS session end reason. My colleague explained that it can be caused by several things and not to focus too much on it being a port issue because the error is not solely relative to the port, but just has the title "Port Error".

Uno are also telling me it is unlikely OR will do a port swap or lift and shift as they term it as the line is likely to prove clear.

What has been said is that it is unlikely OR will just go and do this as matter of course, when a line is testing entirely clear, prior to a visit. If the engineer deems this required on the visit it will be done but we're not even at that stage. You need to allow OR at least some time to look at it before assumptions are made as to what will and won't be done.

Matt

Edited by uno (Sat 05-Sep-20 21:56:19)

It has been explained that this is a standard RADIUS session end reason. My colleague explained that it can be caused by several things and not to focus too much on it being a port issue because the error is not solely relative to the port, but just has the title "Port Error".

Yes I understand that Matt but the fact that port error appears at the time the line drops which was 3 times today is a remarkable coincidence. Usually when I reconfigure my router to find a workaround for the drop it says User-request. Even when rebooting the modem User-request is in the session history.

What has been said is that it is unlikely OR will just go and do this as matter of course, when a line is testing entirely clear, prior to a visit. If the engineer deems this required on the visit it will be done but we're not even at that stage. You need to allow OR at least some time to look at it before assumptions are made as to what will and won't be done.

The two colleagues that have been assisting me with this have been helpful. One more than the other as one colleague left me with the impression OR will not investigate this any further if the engineer finds a clear line. This is not a DSL drop it is PPP disconnection under load which apart from the line card maybe further a field which your colleage failed to mention OR might investigate. I am a little wary as this is not the first ticket I have raised about this issue before although it was not as prolific as today on 08/09/2018 titled Admin Resets and I spoke to you on the ticket. I made some adjustments to my kit and felt it was liveable with but today was the last straw.

Let's see how things go once that fault is picked up on Monday.

The previous ticket you raised on 11/08 and then closed yourself the next day as you said you had found the cause. As it was closed, we'd not see it again so whilst this may not be the first, it is where we've progressed it further within a few hours of you advising the earlier changes didn't help. I'm not sure we could have done it any sooner from the testing you wanted to conduct from advice you were given elsewhere.

Matt

Edited by uno (Sat 05-Sep-20 22:38:08)

I agree that the term "port error" is a generic term used when there is no obvious explanation for the failure.

It's kind of like the term "syndrome" in health where it's used because the problem doesn't lie in any other category.

I've seen this problem, especially when saturating upstream bandwidth. Have a look at PPP Echo parameters (interval and maximum failures count) in your router config. Saturation of bandwidth in either direction can lead to PPP Echo packets either not getting to the far end, therefore not eliciting a response, or response packets being missed. Under sustained load, several Echo sequences can fail in a row. If the number of missed responses exceeds the maximum failures count, the router will assume that the PPP session has dropped when in fact it's alive and kicking, just otherwise engaged.

Increasing the max failures count may help, but the root cause is wrong prioritization of PPP Echo packets by the router OS at either or both ends. Like all other handshake-type traffic, they should have highest priority so that control traffic is never crowded out by payload, but designers of consumer-grade routers tend not to look for such edge cases in QA...

I was working on that assumption that PPP echo packets were not getting there and have tried various settings of max failure on my Asus router. As the Asus isnt approved I have turned my ZyXel VMG-1312-B10A into a router this morning and the Asus as a wifi AP.

It has dropped twice today, I am testing every hour with a 1gb file. Why so random if the upstream is congested or too low (Sync 63/13) as the Openreach specialist has suggested who called me today?

Unfortunately the ZyXel hasn't got the PPP echo settings in its configuration that I can find the Asus has. Has anyone come across PPP Echo settings on the VMG-1312-B10A on latest firmware?

I think it is more complex than that because it happens every 4 hours. In between the download is successful.

So I have had a port swap this afternoon. OR is also saying they can see interference on the line and want to send an SFI. Anyone had one before and know what it involves?

SFI = Special Fault Investigation

Sounds posh, but will just be a standard broadband faulting visit. Pair Quality test. Check the set up is OK (yours is) and a ‘close out’ VDSL test which tests both sync and connectivity to the test login.

SFI cancelled. Both OR and SP agree after port change there should be a noteable pause to monitor the line to see how it performs.

Thanks Zarjaz for info.

There was another PPP drop under load at 13.39 with the ZyXel router. In order to rule out ZyXel I have swapped it for a TP-Link WD9970. It ran for about 5 hours and then I did a download and it dropped at 00:27. Has to be ISP gateway/termination equipment?

I don’t know Tim .... it seems a very random/unusual fault.

I suppose, if pushed for a guess, now you have had a lift and shift done (that is what is implied by recent posts isn’t it ?) I would probably agree.

Will your service provider strip out and then rebuild your account on their home gateway ?

SP is banging on about an SFI/Engineer and they sent me extended data of a test which said interference at my property. I suppose a sudden burst of noise could drop the PPP session but the data said the interference was between 00:00 and 23:45.

In reply to a post by Banger:

SP is banging on about an SFI/Engineer and they sent me extended data of a test which said interference at my property. I suppose a sudden burst of noise could drop the PPP session but the data said the interference was between 00:00 and 23:45.

Are you able to collect any error stats from your modem/router? FEC & CRC errors would be the most useful. Also, looking at your BQM graph, do the line drops happen at the same time I see those regular latency spikes? Errors could be the cause of those spikes since data has to be buffered whilst it waits to be retransmitted.

As the other poster asked ? Do your stats give any inkling of interference ?

Heavy corrected error rate, variable SNR, packet loss ?

Here's my stats, last two drops in the monitoring window were 00:27 and 3:02.

Crc

https://ibb.co/KqSnxBz

FEC

https://ibb.co/mX1dJ5Q

ES per hour

https://ibb.co/1G5rwm1

SNR

https://ibb.co/yBfNHFp

BQM

https://www.thinkbroadband.com/broadband/monitoring/...

I cant see any particular blips around 00:27 or 3:02 on the graphs although I can see my Upload SNR is behaving rather eratically over the last hour or so. Can you take a look at my graphs above?

Edit I do see some packet loss around 00:27 and 3:02 on the BQM but that could also be the disconnect.

Edited by Banger (Wed 09-Sep-20 14:23:45)

My opinion is that those levels of FEC/CRC/ES rates are irrelevant.
The BQM packet losses of around 20 seconds duration are indicative of the PPP sessions dropping and then re-establishing.

I've a horrible feeling that a lot of packet captures on the WAN side and as much logging as possible on the PPP handling process on your router and your ISP doing the same is the only way forward, unless you can provoke this at will.

They really are nothing to write home about ... quite where this leaves you for a next step, I am unsure. I do however think your CP will insist on an SFI visit, and do believe this will give a ‘right when tested’ result.

Helpful - not.

No more drops since the last one at 3:02 but I am seeing a slowdown. My 50 sync line is downloading at around 30mbps on the test file and TBB file also instead of maxing out at 46mbps. Also the download on netmeter is very spikey instead of a solid block of data.

In reply to a post by Zarjaz:

I don’t know Tim .... it seems a very random/unusual fault.

I suppose, if pushed for a guess, now you have had a lift and shift done (that is what is implied by recent posts isn’t it ?) I would probably agree.

Will your service provider strip out and then rebuild your account on their home gateway ?

I had a lift and shift done at a site and it didn't improve matters. Another visit some time later and the engineer fixed it by moving to a port on a different line card in the cabinet.

In reply to a post by caffn8me:

In reply to a post by Zarjaz:

I don’t know Tim .... it seems a very random/unusual fault.

I suppose, if pushed for a guess, now you have had a lift and shift done (that is what is implied by recent posts isn’t it ?) I would probably agree.

Will your service provider strip out and then rebuild your account on their home gateway ?

I had a lift and shift done at a site and it didn't improve matters. Another visit some time later and the engineer fixed it by moving to a port on a different line card in the cabinet.

That's what I have been told has been done Sarah.

PPP dropped 23:28 and my speed is back to normal. Something seriously wrong with the Uno gateway/network.

Another drop under load at 3:42. This time it was short enough for streaming to continue and the download to resume.

Pretty picture

And here's the router log excerpt of the drop.

2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0xe5]
2020-09-10 03:40:59 [3] PPP: ppp1 LCP down
2020-09-10 03:40:59 [4] PPP: ppp1 LCP down
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0xe5]
2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0x1]
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0x1]
2020-09-10 03:41:02 [3] PPP: ppp1
2020-09-10 03:41:18 [6] PPP: ppp1 sent [PADI Host-Uniq(0x00000bc5)]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [LCP ConfReq id=0x1 <mru 1480> <magic 0xc0cb005>]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [LCP ConfReq id=0x29 <auth chap MD5> <magic 0x6bd5ee51>]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [LCP ConfAck id=0x29 <auth chap MD5> <magic 0x6bd5ee51>]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [LCP ConfAck id=0x1 <mru 1480> <magic 0xc0cb005>]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [LCP EchoReq id=0x0 magic=0xc0cb005]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [CHAP Challenge id=0x10 <c07f00025cc1c4a6f7c8f3f9dd48>, name = "nge001.new"]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [CHAP Response id=0x10 <b2e044e94794f1ea245d04187e6714c8>, name = "[email protected]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [LCP EchoRep id=0x0 magic=0x6bd5ee51]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [CHAP Success id=0x10 ""]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns2 0.0.0.0>]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [IPCP ConfReq id=0x1 <addr xx.xx.136.48>]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [IPCP ConfAck id=0x1 <addr xx.xx.136.48>]
2020-09-10 03:41:18 [6] PPP: ppp1 rcvd [IPV6CP ConfReq id=0x1 <addr fe80::76a2:e6ff:fe4f:e400>]
2020-09-10 03:41:18 [6] PPP: ppp1 sent [LCP ProtRej id=0x2 80 57 01 01 00 0e 01 0a 76 a2 e6 ff fe 4f e4 00]

Edited by Banger (Thu 10-Sep-20 03:53:48)

That looks like huge loss of ping responses. There does not appear to be any loss of PPP. Similarly, no way could streaming continue if the line "dropped".

I think you may be looking for the wrong thing. Asking the wrong question. Reporting the the wrong problem to your provider.

Edit: Looking further, assuming this happened not long before you posted it, your live BQM shows no huge problem, just an episode of dropped pings at the time, also 11:30pm and 7am. I've never heard of drop-netmeter, but which interface(s) is it monitoring?

Edit 2: I was also misunderstanding the "pretty picture". The red portions appear to be normal download periods? With a very low level of green uploads at the end.

Edited by RobertoS (Thu 10-Sep-20 10:43:42)

In reply to a post by RobertoS:

There does not appear to be any loss of PPP.

I see this log section:

2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0xe5]
2020-09-10 03:40:59 [3] PPP: ppp1 LCP down
2020-09-10 03:40:59 [4] PPP: ppp1 LCP down
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0xe5]
2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0x1]
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0x1]
2020-09-10 03:41:02 [3] PPP: ppp1

LCP (Link Control Protcol) being down usually means the connetion is down. The TermReq implies something remote (ISP end?) requested termination of the link. I don't know if the ID 0xe5 is a reason code, but Juniper has a reference here.

On a BT router log, I've seen 0x2 and 0x3 say "user request", but I can't seem to find 0xe5. I believe E5 in hex would be 229 in decimal, a significantly higher number than 2 or 3, so I wonder if it a vendor specific code from the remote end.

Edited by jchamier (Thu 10-Sep-20 11:01:01)

"Usually" being important in the context, particularly this one. AIUI LCP requires an initial PPP connection in order to get the link properly set up. That I presume is what the ppp1 is.

Did you see my final version, following a few edits? Tim's BQM shows dropped pings, but not much else in terms of significant problems.

In reply to a post by jchamier:

In reply to a post by RobertoS:

There does not appear to be any loss of PPP.

I see this log section:

2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0xe5]
2020-09-10 03:40:59 [3] PPP: ppp1 LCP down
2020-09-10 03:40:59 [4] PPP: ppp1 LCP down
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0xe5]
2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0x1]
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0x1]
2020-09-10 03:41:02 [3] PPP: ppp1

LCP (Link Control Protcol) being down usually means the connetion is down. The TermReq implies something remote (ISP end?) requested termination of the link. I don't know if the ID 0xe5 is a reason code, but Juniper has a reference here.

On a BT router log, I've seen 0x2 and 0x3 say "user request", but I can't seem to find 0xe5. I believe E5 in hex would be 229 in decimal, a significantly higher number than 2 or 3, so I wonder if it a vendor specific code from the remote end.

Uno session history used to show these reasons. Interesting that the TermReqd comes before the LCP down. Now they have hidden them and I bet 229 is port error which used to show up when the LCP dropped.

In reply to a post by jchamier:

In reply to a post by RobertoS:

There does not appear to be any loss of PPP.

I see this log section:

2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0xe5]
2020-09-10 03:40:59 [3] PPP: ppp1 LCP down
2020-09-10 03:40:59 [4] PPP: ppp1 LCP down
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0xe5]
2020-09-10 03:40:59 [6] PPP: ppp1 rcvd [LCP TermReq id=0x1]
2020-09-10 03:40:59 [6] PPP: ppp1 sent [LCP TermAck id=0x1]
2020-09-10 03:41:02 [3] PPP: ppp1

LCP (Link Control Protcol) being down usually means the connetion is down. The TermReq implies something remote (ISP end?) requested termination of the link. I don't know if the ID 0xe5 is a reason code, but Juniper has a reference here.

On a BT router log, I've seen 0x2 and 0x3 say "user request", but I can't seem to find 0xe5. I believe E5 in hex would be 229 in decimal, a significantly higher number than 2 or 3, so I wonder if it a vendor specific code from the remote end.

Further reading lead me to this https://www.juniper.net/documentation/en_US/junos/to... where 5 decimal is "session timeout".

In reply to a post by RobertoS:

That looks like huge loss of ping responses. There does not appear to be any loss of PPP. Similarly, no way could streaming continue if the line "dropped".

I think you may be looking for the wrong thing. Asking the wrong question. Reporting the the wrong problem to your provider.

Edit: Looking further, assuming this happened not long before you posted it, your live BQM shows no huge problem, just an episode of dropped pings at the time, also 11:30pm and 7am. I've never heard of drop-netmeter, but which interface(s) is it monitoring?

Edit 2: I was also misunderstanding the "pretty picture". The red portions appear to be normal download periods? With a very low level of green uploads at the end.

Netmeter monitors traffic on my PC which does the automated tests, it monitors the NIC on my PC. You are correct they are non spikey after a PPP drop and new session. The green is local LAN traffic of which cause I forget now but it is between Windows PCs.

In reply to a post by RobertoS:

"Usually" being important in the context, particularly this one. AIUI LCP requires an initial PPP connection in order to get the link properly set up. That I presume is what the ppp1 is.

ppp1 is the virtual (software) network card that the PPP client creates, and which is assigned the IP when connected. I remember this from dial up internet connections in the early 1990s where you dialled, and then created a ppp link. LCP is the protocol that actually _creates_ the ppp link, it is the "link control protocol".

Did you see my final version, following a few edits? Tim's BQM shows dropped pings, but not much else in terms of significant problems.

The BQM can't see this layer, once there is a drop (ISP end or user end) the TCP address is gone, so nothing for BQM to ping.

Got my ZyXel VMG-1312-B10D today and it works well with a 3 dongle. It was Zen branded so after I cleared the ROM I was able to upgrade the firmware to the latest. I'm not 'allowed' to put it on my line because OR and Uno are monitoring DSL and also I want my 3db SNR back.

Sod's law, but what speed is that giving?

That was my point about the BQM. It didn't drop, which suggests the main PPP session was still up. Although replacing it may have been in process?

I cant speedtest as I am out of data but it is only a 3g dongle so can only visit three.co.uk.

In reply to a post by RobertoS:

That was my point about the BQM. It didn't drop, which suggests the main PPP session was still up. Although replacing it may have been in process?

My router reconnects in 30 seconds, so you are not gonna see that on the BQM.

In reply to a post by Banger:

I cant speedtest as I am out of data but it is only a 3g dongle so can only visit three.co.uk.

What did you get it for, if you have already used up all the data allowance? And, with a non-exhausted data allowance, you can visit anywhere. Huh??

Its a backup dongle with replaceable SIM. If my line is down and I need a couple of hours I will top up, duh.

Worth trying an unlimited SIM in it, with a couple of weeks to cancel?

I suspect 3g will be pretty slow and I've never needed it this year. I haven't seen any 4g dongles only routers. I want my BB sorted first.

There are plenty of 4G dongles. Most mobile networks have been providing them for a long time. I have a 6 year old Vodafone one here. In 4G terms they are old (Cat 3).

You should be aware all networks have reduced capacity on 3G significantly.

Thanks for that JC you are a mine of info. I will look at 4g dongles.

You mean when you said "3" you meant 3G? Yikes! Send it back.

I thought you meant Three, and I'm fairly sure any dongle they provide will be 4G (LTE) at least and should by now be 5G-capable. Like all their other current kit.

See my sig for the older HomeFi (LTE) with the Huawei B311, and my new phone that does 4G+ as Three name it. (Phone will do 5G and so will the SIM once I find time to drive 10 miles away).

On my phone:

Aug 19 6pm - https://www.thinkbroadband.com/speedtest/15978570953...

Sept 4 1:45am - https://www.thinkbroadband.com/speedtest/15991803014...

Edited by RobertoS (Thu 10-Sep-20 23:51:39)

Yes 3g from Three had it years. I have a 4g dongle on the way. You're getting confused again old man lol. 6mbps up and down but ok for web.

Nope. I'm not confused. Merely not having a detailed history of what equipment you have from years ago readily available in my memory
🤠

Uno PPP session just dropped again after 1:30 minutes download (537mb) that is 3 echo requests of the TP-Link router. TP-Link has an echo request of 30 seconds. If the PPP server is set to drop at 3 echo requests that would explain it. But why every 4 hours and why does it succeed in between times?

Just had a DLM re-sync. Interleave from 4 DS to 8.

My theory is PPP echo packets are being lost and the server is sending a terminate request and dropping the PPP session under load. Why that is happening would need a network expert.

I maybe jumping the gun, but as of 23:14 11.09.20 it appears fixed. Dont ask me what has changed other than sessions stay up and PPP echo packets appear to be getting through.

When the interleave level jumped from 4 to 8, was the upstream at 4 and dropped to zero at the same time? That would be re-transmission on the upstream being turned off.

In reply to a post by RobertoS:

When the interleave level jumped from 4 to 8, was the upstream at 4 and dropped to zero at the same time? That would be re-transmission on the upstream being turned off.

AFAIK only the DS interleave changed from 4 to 8. US has always been 1 according to my stats program.

It's either interleaving change that has fixed it or TTB has changed their shaping profile.

In reply to a post by Banger:

It's either interleaving change that has fixed it or TTB has changed their shaping profile.

If your CP is Uno/Xilo then its they who are responsible for any traffic shaping, not the underlying wholesale provider (TalkTalk Business).

In reply to a post by Highland76:

In reply to a post by Banger:

It's either interleaving change that has fixed it or TTB has changed their shaping profile.

If your CP is Uno/Xilo then its they who are responsible for any traffic shaping, not the underlying wholesale provider (TalkTalk Business).

I see. Yes it is Uno. I read somewhere that shaping should be applied to prevent these sort of things on sync time. Is that right because Plusnet once had a problem with their shaping profile getting similar results?

and this is something that we don't do and have never done.

Matt

https://support.aa.net.uk/Traffic_shaping_options

BT do it at sync time on the BRAS. Dont TTB?

Changed router back to the ZyXel VMG-1312-B10A as it has higher sync and lower errors than the TP-Link WD9970, will monitor.

That's not what he meant by traffic shaping.
He was referring to throttling torrents and blocking specific protocols, which is what i would also refer to as traffic shaping.

What all ISP's do on xDSL with a variable sync rate is rate limit the downstream from the sync speed.
I wouldn't call this traffic shaping.

Edited by j0hn83 (Mon 14-Sep-20 17:47:41)

Well rate limiting is what I meant and I think it is fixed now as my downloads used to start with a blip at the beginning and now they are flat on netmeter graph.

3days, 12hrs, 6mins, 2secs

A good start, not one drop of PPP after router change with random 1gb download testing.

Certainly encouraging.

I note from that time period that 2 x 6 = 12, and 6 periods of 12 hours is 3 days.

Weird how spotting relationships between numbers, learned about 60 years ago, sticks.

Indeed, well spotted. I see the three Unlimited sim is now £11pm for 6 months. That is a great deal.

Yep. I got a friend onto it, and also "upgraded" my own from it's "out of contract" £20 that had risen to over £21 through two annual inflation increases.

Though my latest d/d is still the higher price. I shall wait till the next one before complaining.

corroded joint at some junction, all the line tests will pass and a TDR does not show it either ... you have to convince your friendly Openreach engineer to inspect each joint, *all* of them back to the cabinet. Including the one *in* the cabinet.

I had this on 2 lines at locations +200 miles apart. One line was 3km long with many joints, the other 800m long with 2 joints.

DSL is not dropping.

subject