Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


lllRL last won the day on September 20

lllRL had the most liked content!

About lllRL

  • Rank
    Forum Legend
  • Birthday November 14

Profile Information

  • Gender
  • Location
  • Interests
    Hi :) https://www.youtube.com/c/RL1411

Recent Profile Visitors

4,152 profile views
  1. It was actually was one of your posts here that I found a while back which got me interested in tweaking and fine tuning it to my liking I just never really knew what to do with the old firmware's hyper lane since it wasn't really clear what did what if you didn't choose "both" for direction. Since traffic prioritisation gives us more control, it's only logical that we find the most vital port/s for our games and throw them in there Unfortunately until we get the ability to see the ports in use for our games, as we could with the old network monitor, we'd have to resort to guesswork or bridging our connections through PCs to run a Wireshark capture. At least if you play on Steam it'd be a little simpler lol
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Thanks for bumping or I never would have seen this. This is a great idea. It took me forever to find out the network monitor showed ports in use, but once I discovered that I used it to put the hyper lane to good use. If you don't like the idea of a preset which includes a range of thousands of ports, you can use it to create useful advanced/manual rules. I don't really know for sure what choosing a one way rule (for example UDP 3074 destination) really did on the old firmware (is that like setting source to 1-65535?) but CoD and Battlefield games, for example, don't send and receive game data over just one port - you send from a fixed single port, but the receiving server port will always vary. For example in CoD the player will be designated 3074, while the server port would range between 30000 and 50000: The new traffic prioritisation feature on DumaOS is great but you can't set it up properly if you don't know which ports you're trying to download traffic from lol I've tried rules like destination 3074 source 30000-50000 but it doesn't seem to work; you either get a very small amount of traffic being prioritised before the "light" goes off in game, or you get both upload and download packets being prioritised which, frankly, should be impossible if the destination is your console (download). I've gone back to old firmware (1.03.6) myself while I do some more testing and monitoring of ports in game, because my connections in any game on low pings have been nothing short of disgusting.
  8. What would the update be addressing? I'm intrigued... I haven't played BO4 since early November because it's a mess and my connection's a mess anyway.
  9. Set your sliders to 4.20% down 13.37% up. Then stab a hole in your ethernet cable for some spicy packet loss hax ( อกยฐ อœส– อกยฐ)
  10. Interesting. You may even find disabling them works well for you. I read this the other day: ๐Ÿค”
  11. 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? ยฏ\_(ใƒ„)_/ยฏ
  12. 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 ๐Ÿค”
  13. lllRL

    My home setup

    The mention of coax suggests he's on cable, so he won't be using PPPoE. @Swgohlegend have you entered 300 down and up here? Make sure goodput is enabled and IPv6 is disabled under WAN and LAN, then click reset distribution under bandwidth allocation and "never" next to QoS. Then run a wired speed test and see if that gets you more than 60/180~. If not the additional cable you're using to add the R1 into the setup may be an issue, so try swapping that out for another and test again
  14. This'll definitely be the lazy method (can you guess why I thought of it? ๐Ÿ˜) as you can just set and forget. However, considering the unique nature of your setup and the serious fluctuations you'd be wise to consider a "day" of testing. Well, more like an evening as peak time for usage on your network will be the best time to test and discover a reliable minimum set of numbers. 10/10Mb would be absolutely fine. If you're not 100% confident the line will maintain more than 15Mb all of the time then this will give you a bit of leg room - a buffer to keep you away from the max you're achieving at worst when it drops. Plus 10/10 would be more than enough for gaming anyway. Actually I've been playing around with similar numbers myself lately with bandwidth allocation rather than the "global" QoS sliders and I've found that streaming TV seems to run just fine with lower amounts of bandwidth available for it to use, so you shouldn't need to cut it too close with Netflix while gaming. Perhaps another test you could try is capping the overall to around 4-7Mb (on the downstream anyway) and testing Netflix to see if the most demanding of content runs without issue. When you're confident you've found a number that works without an issue, you can add on a couple of megabits to factor in gaming and then you can set up your "safe minimum" and give it a proper test in game ๐Ÿ‘ The only thing to worry about at this point is finding the absolute low end of what you can expect when it's fluctuating. If you see <15 but >10 at worst then you're gonna be just fine! In fact, even if you were getting a constant 15Mb with no dips below, I'd suggest telling the R1 that you're paying for 15/15 and then just set the sliders to 70% for that buffer which'd give you a stable 10Mb anyway. You want the cap to be just below any drops so that you won't get any iffy moments while playing a game if the overall drops below what you've set. Being conservative is definitely better than being optimistic in this scenario lol Edit: maybe you won't need to test Netflix at all. I just found this: "According to Netflix, the Internet speed you'll need for downloads is as follows: For any streaming at all, you'll need a minimum of 0.5 megabits per second (Mbps), but Netflix recommends 1.5 Mbps. For DVD quality, you will need 3.0 Mbps. For HD quality, you will need 5.0 Mbps." This is good. If you never drop below 10Mb then you're going to have more than enough to play with while keeping the wife happy with the best quality streaming ๐Ÿ˜‚ I'd still suggest doing some evening speed tests to be on the safe side, but I think you could get away with telling the R1 you get 10/10, then dropping the sliders to 65-85% and allocating 5Mb to whichever device is using Netflix. Honestly you could get away with even distribution and leaving share excess enabled, but you may want to play around with those to fine tune your setup. You would more than likely be able to get away with 90% sliders as that's an entire megabit shaved off as a buffer, but again you may find the need to fine tune using those sliders/bandwidth allocation or disabling share excess for consistent distribution. Hopefully your evening speed tests will provide good news and show no dips below 10Mb whatsoever ๐Ÿ˜„
  15. Highly doubtful it was an update as it was like that for five hours. I set it back to 100% and now I'm using my Amazon Fire TV (streaming a movie which topped out at around 25Mb at any one point) the max spikes are under 30ms, with the average not exceeding 10ms, so it's looking normal again. Not really sure what to make of this though: I've seen the bottom graph peak at 70Mb down while the top one will hit around 10Mb at most. Why is there a discrepancy between the two? I've been sat staring at this page for a few minutes and while the bottom one will fluctuate accurately the top one hasn't budged past 3Mb lol