Bitswap and Seamless Rate Adaption? (VDSL2)

[RL317]

I was wondering if any of the wizards among you might be able to shed some light on this, because my head is hurting a little

 

I swapped from BT to TalkTalk in September, and for the past few weeks I've been seeing a lot of packet loss on a broadband monitor. I swapped out my modem (used three different ones) and DSL cable, which initially seemed to fix the issue, but it would come back again. Right now I'm using a TP Link W9970 which is in combo mode since bridge mode apparently doesn't work with the R1 (it did on BT, and with the HG612 on TT), but in either mode there are many settings to play around with pertaining to VDSL2. I checked my BQM yesterday and it looked like this (hopefully the top of the graph is clear):

If you can't see it, the top of the graph is riddled with red dots. I was messing around in my W9970 GUI trying to understand the meaning of the names of settings that were foreign to me, and it seemed like bitswap is a setting that should be used on both VDSL and ADSL so I turned it on along with SRA. That big red spike coming down from the top of the graph is the modem disconnecting and reconnecting. If I now show you the latest monitor, you'll see that for almost 18 hours after reconnecting there was zero packet loss:

... but there was another red spike this morning - apparently a disconnection - and then a single dot showing packet loss since then. I checked my modem stats and the uptime hadn't changed, but bitswap and SRA were still enabled after I locked them in, and my upstream SNR margin has increased by over 20% (7.3 up to 8.8dB) from the usual. The downstream SNR margin hasn't changed from its usual 3.3 or 3.4dB (isn't this low? I get the bandwidth my line tops out at) and line attenuation hasn't moved since I first started using the W9970 months ago (I don't really know what this shows tbh):

I did look up SNR and it seems the higher the better, so does this mean either bitswap or SRA improve the stability of a line? I'm hoping that one pixel of packet loss since the second D/C is just a one off, because overall it looks much better. I'm just wondering if there's some trade off somewhere, much like how interleaving attempts to stabilise the line at the cost of performance. Most of the results from Google searches on SRA or bitswap are confusing and generally contradictory, with many claiming they apply to ADSL only. Yet many people post in depth modem stats on FTTC connections which show a bitswap stat/numerical value. Any ideas? 

 

This constant packet loss never happened for me on BT Infinity. It seems like things run a bit differently on TalkTalk over IPoE so it'd be great to know that enabling these settings didn't simply just coincide with packet loss being stopped in its tracks 🤔

[palla69]

Interesting topic!!!

I to am with TT. And have a similar line and speed to yours. The speeds that are showing upstream and downstream, do you actually get those speeds when you do a speedtest??? I caant seem to get near what mine says!!

Just interested to know 😁

[RL317]

8 minutes ago, palla69 said:

Interesting topic!!!

I to am with TT. And have a similar line and speed to yours. The speeds that are showing upstream and downstream, do you actually get those speeds when you do a speedtest??? I caant seem to get near what mine says!!

Just interested to know 😁

I haven't done a wired test for a good while (not since I switched and my max speeds were lower, since switching from 50/10 on BT) but on WiFi my download hovers around 68-71Mb and my upload is always spot on. 

 

I just find it weird that I can't get 80/20 because my cabinet is a stone's throw away. I mean, I could genuinely throw a stone from my kitchen window and hit it LOL. I guess the distance from the exchange is also a factor then? 

 

I also find it odd that it says the potential max on the upstream is 24Mb. I've never heard of anyone getting higher than 20 on VDSL? ¯\_(ツ)_/¯ 

[palla69]

I to can throw a stone and hit my cabinet!!!!   Most ive got via wifi is 50 down and 15ish up with a ping of around 15ms throught the R1. After reading your post I took a look at my tp link Archer vr900 settings and the bitswap and sra were both ticked.

I might try and do a wired speed test direct to the Tp link router.  👍

[RL317]

17 minutes ago, palla69 said:

I to can throw a stone and hit my cabinet!!!!   Most ive got via wifi is 50 down and 15ish up with a ping of around 15ms throught the R1. After reading your post I took a look at my tp link Archer vr900 settings and the bitswap and sra were both ticked.

I might try and do a wired speed test direct to the Tp link router.  👍

Interesting. You may even find disabling them works well for you. I read this the other day:

🤔

[RL317]

Update: along with the packet loss (which returned, albeit not as frequently) I noticed my connection is dropping out at least once daily, as shown here by the red spike:

I started a new plot because I'd swapped out my W9970 to the TalkTalk WiFi Hub and the IP changed. There wasn't any packet loss since starting that new one (except for the dot after the big spike around 5am), but there had been prior to swapping out the modem while using bitswap. 

 

I saw the dropout so I decided to try out the test socket behind the faceplate with an RJ11 cable plugged into a microfilter (the resync is the second red spike on the end there), and I used that downtime as an excuse to plug the HG612 back in since I prefer having a modem in bridge mode anyway. The minimum latency seems to have gone up despite removing a hop from the setup (only a couple of ms, but still) which doesn't seem like a good sign off the bat, but the main idea of this is to see if there are any further dropouts.

 

I've been looking around online and I've seen people suggest trying a new modem, trying the test socket, and checking their SNR. One person had a margin of 3dB and was requesting TalkTalk to somehow force it to 6dB to stabilise the line. Is that the problem here? Unlike most of the people who take to forums with complaints of daily disconnections, my speeds haven't dropped at all... they're still 70+/20.

 

Anyone got any ideas? @Zennon perhaps as you're on TalkTalk too if my memory isn't too rusty? I never saw all this packet loss or resync nonsense on BT (except for their Smart Hub's usual fortnightly reboot) and it's the same line! It's futile trying to game on this too because there are frequent lag spikes in excess of 500ms on "7ms" along with the packet loss. Line stats seem inaccurate on both the HG612 and TalkTalk Hub (some stats on both say 0dB for attenuation or SNR) so I'll post the latest ones off my W9970:

 

Current rate (Kbps): 20000 up, 71636 down 

Max rate (Kbps): 24782 up, 74550 down

SNR margin (dB) : 7.3 up, 3.3 down

Line attenuation (dB): 14.9 up, 6.7 down

Errors (Pkts): 0 up, 0 down

 

Is that SNR the problem? I've heard it said that low SNR margins are indicative of a noisy line, but I don't know if that's true because I see a lot of contradictory information out there. All I know is when I turned bitswap on my upstream SNR margin increased by over 20% (neither value has moved more than 0.1dB on its own before), while the downstream's didn't budge. I had no packet loss for 18 hours after that but then there was another disconnection and it returned LOL

 

My head hurts ¯\_(ツ)_/¯ my swapping modems every now and then isn't good but, to be fair, my modem up time after switching to TalkTalk was 29 days and the DSL uptime was never any more than 5-7 days anyway. 

[Zennon]

Talk talk are having a few issues at the moment.

This was my Ping Plotter a few weeks back.

My fix was to turn off my modem for over 20 minutes so DLM does not see it as a line drop.

Start the modem back up and re test.

In the end I had to do this twice, changing IP did the trick.

 

[RL317]

1 hour ago, Zennon said:

Talk talk are having a few issues at the moment.

This was my Ping Plotter a few weeks back.

My fix was to turn off my modem for over 20 minutes so DLM does not see it as a line drop.

Start the modem back up and re test.

In the end I had to do this twice, changing IP did the trick.

 

Yikes, what a mess. At least I'm not alone in the madness then 🙄

 

I had my modem off for 35 minutes last time and when I swapped it out for a different one, I deleted my BQM expecting it to see a new IP. It was the same for some reason. 

 

Am I thinking along the right lines by trying out the test socket? It's obviously an ISP issue but at least this way I can prove it's not the wiring past that point where it leaves their responsibility. 

 

I tried playing after getting the modem back up and running and it was fine for one game, before becoming a mess again. I just don't know what to do anymore. 

[BIG__DOG]

2 hours ago, lllRL said:

Update: along with the packet loss (which returned, albeit not as frequently) I noticed my connection is dropping out at least once daily, as shown here by the red spike:

I started a new plot because I'd swapped out my W9970 to the TalkTalk WiFi Hub and the IP changed. There wasn't any packet loss since starting that new one (except for the dot after the big spike around 5am), but there had been prior to swapping out the modem while using bitswap. 

 

I saw the dropout so I decided to try out the test socket behind the faceplate with an RJ11 cable plugged into a microfilter (the resync is the second red spike on the end there), and I used that downtime as an excuse to plug the HG612 back in since I prefer having a modem in bridge mode anyway. The minimum latency seems to have gone up despite removing a hop from the setup (only a couple of ms, but still) which doesn't seem like a good sign off the bat, but the main idea of this is to see if there are any further dropouts.

 

I've been looking around online and I've seen people suggest trying a new modem, trying the test socket, and checking their SNR. One person had a margin of 3dB and was requesting TalkTalk to somehow force it to 6dB to stabilise the line. Is that the problem here? Unlike most of the people who take to forums with complaints of daily disconnections, my speeds haven't dropped at all... they're still 70+/20.

 

Anyone got any ideas? @Zennon perhaps as you're on TalkTalk too if my memory isn't too rusty? I never saw all this packet loss or resync nonsense on BT (except for their Smart Hub's usual fortnightly reboot) and it's the same line! It's futile trying to game on this too because there are frequent lag spikes in excess of 500ms on "7ms" along with the packet loss. Line stats seem inaccurate on both the HG612 and TalkTalk Hub (some stats on both say 0dB for attenuation or SNR) so I'll post the latest ones off my W9970:

 

Current rate (Kbps): 20000 up, 71636 down 

Max rate (Kbps): 24782 up, 74550 down

SNR margin (dB) : 7.3 up, 3.3 down

Line attenuation (dB): 14.9 up, 6.7 down

Errors (Pkts): 0 up, 0 down

 

Is that SNR the problem? I've heard it said that low SNR margins are indicative of a noisy line, but I don't know if that's true because I see a lot of contradictory information out there. All I know is when I turned bitswap on my upstream SNR margin increased by over 20% (neither value has moved more than 0.1dB on its own before), while the downstream's didn't budge. I had no packet loss for 18 hours after that but then there was another disconnection and it returned LOL

 

My head hurts ¯\_(ツ)_/¯ my swapping modems every now and then isn't good but, to be fair, my modem up time after switching to TalkTalk was 29 days and the DSL uptime was never any more than 5-7 days anyway. 

Billion modems and asus dsl modem/routers such as the DSL-AC68U allow you to adjust bitswapping and SNR settings. I had a dabble fiddling about with it when I was on BT. 6db is the ideal position but it has to be a very good quality line.

[Zennon]

10 minutes ago, lllRL said:

Yikes, what a mess. At least I'm not alone in the madness then 🙄

 

I had my modem off for 35 minutes last time and when I swapped it out for a different one, I deleted my BQM expecting it to see a new IP. It was the same for some reason. 

 

Am I thinking along the right lines by trying out the test socket? It's obviously an ISP issue but at least this way I can prove it's not the wiring past that point where it leaves their responsibility. 

 

I tried playing after getting the modem back up and running and it was fine for one game, before becoming a mess again. I just don't know what to do anymore. 

As you can see from my ping plotter the issue starts at their network hop.

Use PP to diagnose.

I would turn off again for over 20 minutes and see how it goes like I did.

I have no issues now pings with no spikes and no PL.

They wanted to send out an engineer, yeah right.

[RL317]

20 hours ago, BIG__DOG said:

Billion modems and asus dsl modem/routers such as the DSL-AC68U allow you to adjust bitswapping and SNR settings. I had a dabble fiddling about with it when I was on BT. 6db is the ideal position but it has to be a very good quality line.

I read somewhere that low SNR is fine as long as the line is exceptional. I'm not sure that can apply to me, but I am very close to the cabinet and get almost exactly what my line tops out at. But that begs the question - why can't I get 80 down if the cab is a stone's throw away? Is that simply down to the distance to the exchange? 

 

I found it interesting that enabling bitswap on the W9970 increased the SNR on the upstream but nothing really changed in the way of performance. If high SNR margins are better I guess it makes sense that I get the full 20 up but not 80 down. That said, I've also skimmed across forum posts and articles saying that the Openreach network was rolling out "3dB connections", whatever that means. 

[RL317]

21 hours ago, Zennon said:

As you can see from my ping plotter the issue starts at their network hop.

Use PP to diagnose.

I would turn off again for over 20 minutes and see how it goes like I did.

I have no issues now pings with no spikes and no PL.

They wanted to send out an engineer, yeah right.

I ran PingPlotter last night and I wasn't getting any packet loss to twitter (well there was some on an intermediate hop set to not reply to ICMP), but then all of a sudden I was getting up to 75% loss on the first hop. I swapped cables (for a brand new one that I was literally taking out of the packet) and it was the same. So I opened the command prompt to ping Twitter and a -t ping for 5 minutes showed no loss. Very confused now... 

 

I just opened up thinkbroadband and apparently there was either a huge spike of packet loss or another drop out just now. I'm using the HG612 again so I can't even check the network vs device uptime right now, unless there's a way to access its GUI through the R1. Having said that, the only packet loss I've had for 24 hours was while streaming TV with QoS "off" (set to when high prio detected at 70%), and the mess at around 10pm was me tweaking QoS using PingPlotter because I thought "why not" with the laptop already out, and because I never remembered to test its anti-bufferbloat capabilities after upgrading to DumaOS (side note: DumaOS QoS seems better than even the preemptive algorithm on old FW). All has been calm since I stopped using the net at around 2am:

When the house is quiet and I don't need to be online next, I'll turn the modem off and leave it off for half an hour or so. Last night while I was wired up with the laptop I double checked its settings, made sure QoS/firewall/unnecessary ATM and PTM settings were off and dropped 802.1p from 2 back to 0 since I don't use IPTV, so I can't think of any reason to reboot it again. Then when it pulls another IP (hopefully) I'll set up a new plot and just observe. 

[Zennon]

Default SNRM is 6db

They are using 3db also now if your line has low noise and does not bite much into any of the 6db.

Two reasons to have a higher SNRM your line has noise and the DLM will set you to 9db if you still have noise issues it will set it to 12db etc you will have the associated loss of bandwidth per SNRM jump.

The other reason is you are close to the cabinet and you are syncing at the max rate and you could in effect have more bandwidth so you get an overhead of SNRM instead so you may have 12db if you are next to the cab.

[RL317]

3 minutes ago, Zennon said:

Default SNRM is 6db

They are using 3db also now if your line has low noise and does not bite much into any of the 6db.

Two reasons to have a higher SNRM your line has noise and the DLM will set you to 9db if you still have noise issues it will set it to 12db etc you will have the associated loss of bandwidth per SNRM jump.

The other reason is you are close to the cabinet and you are syncing at the max rate and you could in effect have more bandwidth so you get an overhead of SNRM instead so you may have 12db if you are next to the cab.

Oh gotcha. Is that why my modem stats say my line's max rate on the upstream is 24Mb, for example? I've never ever ever heard of anyone on VDSL2 getting more than 20Mb.

 

The downstream is odd though. If it's "low noise" (hence the 3dB) and I'm next to the cab, surely I could expect the full 80Mb or thereabouts. 

 

I guess an increase of 20%+ on upstream SNRM using bitswap is a sign I shouldn't use it then.

[Zennon]

3 minutes ago, lllRL said:

Oh gotcha. Is that why my modem stats say my line's max rate on the upstream is 24Mb, for example? I've never ever ever heard of anyone on VDSL2 getting more than 20Mb.

 

The downstream is odd though. If it's "low noise" (hence the 3dB) and I'm next to the cab, surely I could expect the full 80Mb or thereabouts. 

 

I guess an increase of 20%+ on upstream SNRM using bitswap is a sign I shouldn't use it then.

BT max throughput 75Mb

Talk Talk max throughput 76Mb

Sync is always higher than throughput, you do not need to use bitswap.

[kinel]

I just wanted to mention  i thnk atm you are using the older firmware

When i was monitoring my line like you are .  when i had enable deep packet processing  ticked it was causing big ping spikes on my line

I am also a talktalk user

 

[RL317]

12 hours ago, kinel said:

I just wanted to mention  i thnk atm you are using the older firmware

When i was monitoring my line like you are .  when i had enable deep packet processing  ticked it was causing big ping spikes on my line

I am also a talktalk user

 

Old firmware on the TP Link or R1? I've got the latest version of both mate, including DumaOS. There's no deep packet setting in sight

[kinel]

Sorry i meant old netdumari  fw

[RL317]

Sorry I'm a bit confused... no amount of coffee could shake off the cobwebs on my brain today lol. Were you asking if I was using the old Netduma firmware with the TP Link? I actually tried both but when I made this thread I was back on DumaOS. Before upgrading I unticked all of the miscellaneous settings on 1.03.6j, but I don't think deep packet was enabled anyway. 

 

Could be a coincidence but what really seemed to fix that packet loss was swapping the modem again and changing the 802.1p WAN setting on the HG612. Apparently for TalkTalk you should use anywhere from 0 to 2, but I tried 3 and had zero packet loss for 48 hours until I tried another setting. 

 

But none of those settings seemed to help the constant lag I've got in my games, even in custom games vs bots, so I just reset the HG612 back to factory defaults and gave up. 

 

In fact today I noticed the same lag in custom games (compared to local games which are offline), so I connected to my phone's 4G hotspot and tried a custom game with that. According to DSLReports or speed tests I get something like 50ms minimum to London (6ms when wired through the HG612) but my hitmarkers were registering faster and not disappearing. I give up lol

[kinel]

To iirl  Sorry i was just mentioning what worked for me when i was using the older netdumar1 fw in the past 

All i did was untick deep packet processing and the big ping spikes went away

 

Sorry to jump on your thread but i wanted to ask zennon a ?On what they posted here 

 

 

 

On 12/5/2018 at 3:39 PM, Zennon said:

Talk talk are having a few issues at the moment.

 

zennon you mentioned this was from a few weeks ago when you was having problems

Was the problem in hop 2 100% packet loss  or the problem was in the graph below itwith the big ping spikes

 

 

 

 

[RL317]

1 hour ago, kinel said:

To iirl  Sorry i was just mentioning what worked for me when i was using the older netdumar1 fw in the past 

All i did was untick deep packet processing and the big ping spikes went away

 

Sorry to jump on your thread but i wanted to ask zennon a ?On what they posted here 

 

 

 

 

Ahh okay gotcha 👍 when I was on the old firmware I played around with deep packet processing but it never seemed to do much. Then again I saw a lot of weird things that didn't make sense, like reactive causing packet loss lol

 

The problem on that PingPlotter screenshot is everything from hop 3 onwards. Hop 2 showing up to 100% packet loss is normal, at least as far as I can tell from my time on both TalkTalk and BT. The loss starting at hop 3 is what carries on down to the final hop, hence the red bars on the bottom half of the page. 

[Zennon]

1 hour ago, kinel said:

Sorry to jump on your thread but i wanted to ask zennon a ?On what they posted here

It was hop 3 on TT network where the issue started.

Hop 2 is my modem which is not responding to pings.

[RL317]

4 hours ago, Zennon said:

It was hop 3 on TT network where the issue started.

Hop 2 is my modem which is not responding to pings.

Oh hop 2 is the modem? I always thought it was something on their end (the ISP) that just didn't place a high priority on ICMP replies. I've noticed if you run a modem in bridge mode and then a router, you get just one of them appearing on PingPlotter and the first hop is marked by stars on the Netduma diagnostic test trace route, whereas if you have a combo behind the R1 you see the first hop with like 0.5ms latency. 

 

Veering off on a slight tangent, do you know why latency can be so low to the modem on the Netduma diagnostic test but if I connect a laptop to the R1 and run a PingPlotter test my first hop latencies are a bit all over the place? I've been running tests with brand new short cables and regardless of the R1 port I use, I never get the typical latency inside the LAN of <1ms... it's usually an average of 3 or 4ms, with spikes into the double digits and a minimum of 2.5ms. Something wrong with my R1 ports?

 

Like I say the Netduma diagnostic is obviously only testing to the router and relaying the results to the device the test is running on, rather than going through the device (ie a laptop or phone) itself, but the latency to the WAN port is always very steady at 0.4-0.6ms. If I'm using the R1 with a modem only behind it I get the R1 alone at the top of any PingPlotter test, but it's not a stable <1ms or <0.5ms like you see on yours. It's always spiking up to the double digits like my Virgin Superhub used to whenever I pinged the router alone 🙄

Edit: I don't have any PingPlotter screenshots handy to illustrate what I mean, but I do have this one which I sent to my phone a while back. What the hell are those "inverse" spikes all about? 0.0ms minimum? 1ms minimum to an IP based in Scotland? Very weird stuff. 

 

[kinel]

79 .79.79.79   for me was a dns servers

Ive also had 79.79.79.80 as me secondary dns server

As i used to put those dns servers into my router and ps4

[RL317]

17 hours ago, kinel said:

79 .79.79.79   for me was a dns servers

Ive also had 79.79.79.80 as me secondary dns server

As i used to put those dns servers into my router and ps4

Yeah it's TalkTalk DNS. I just picked a random IP to ping but it was very weird indeed. If I ping the other one (79.79.79.80) it averages like 5ms. I get 6ms minimum to London less than 50 miles away, but TalkTalk DNS is based 400 miles away lol