Windows 10 updates bandwith limit
-
Really the only way to take control of the W10 updates is WSUS or SCM. (The P2P feature might help if those laptops are available on LAN simultaneously; also there's the metered connection hack.)
-
Assuming your DSL isn't ridiculously slow, like less than 2Mb/s, you could try enabling CoDel and traffic shape your download. Agnostically reducing bufferbloat has a natural side-effect of more evenly distributing bandwidth and keeping latency down, which keeps things feeling fast.
-
Thanks you guys for the reply's, but I am a real noob on the traffic shaper subject and as I have a real stable configuration and don't want to mess it up with a steep learning curve is there a video or some other stuff I can get familiar to all the possibilities/options to eventually create a good regulated aDSL WAN?
-
The data needs to transfer. What about the "hunger for bandwidth" are you trying to solve? It turns into a bandwidth hog and makes everything else slower? You want to keep your 95th percentile down? What?
Sorry why not turn off your windows 10 updates and use something like WSUS Offline to do the updates. You manually run it when you want to do updates.. I think MS might sill release updates every second Tuesday of every month, so that's a good time when to start linking of running WSUS Offline to get the updates.
-
Sorry why not turn off your windows 10 updates
Such option does not exist (beyond the metered connection hack).
-
I too am having difficulty with Windows 10 absolutely destroying my connection. It opens a number of different connections at once, and it's a bit like being DDOSed, but on the inside. Lord help you if two Windows 10 PCs try to update at once. We do repairs and refurbs and it kills us, to the point where the VOIP is unusable, even with traffic shaping rules in place.
Is there any way to limit this abuse on my network? I gather this should be possible using limiters, but I am unsure on what would be the best way to accomplish this.
-
Just update to CU and do proper settings in Update and Security (deferring, branch, active hours, "how updates are delivered" or even pause the updates).
Also setting metering connection can help you. -
A common reason for Window's Updates decimating a connection is because of low latency connections with little bandwidth, causing TCP to not honor congestion signals. There's not much you can do about this because of an unnatural relation between provisioned bandwidth and latency.
You could potentially artificially delay these packets using dummynet, assuming this is the issue. If the issue is just normal bandwidth saturation with lots of connections and high bufferbloat, then just enable CoDel.
-
@w0w:
Just update to CU and do proper settings in Update and Security (deferring, branch, active hours, "how updates are delivered" or even pause the updates).
Also setting metering connection can help you.Unfortunately I can't really avoid doing updates. Getting these computers updated is necessary as part of the setup as we need to ensure that there are no problems with updates before returning them to clients. If there's a Windows update that breaks audio for example, we need to know about it. Mostly residential work so I can't use WSUS sadly.
@Harvy66:A common reason for Window's Updates decimating a connection is because of low latency connections with little bandwidth, causing TCP to not honor congestion signals. There's not much you can do about this because of an unnatural relation between provisioned bandwidth and latency.
You could potentially artificially delay these packets using dummynet, assuming this is the issue. If the issue is just normal bandwidth saturation with lots of connections and high bufferbloat, then just enable CoDel.
Hmm. Is there any way to identify Windows Update traffic and dump it all in a queue of some sort that is only allowed a maximum of 5mbit/0.5mbit? I don't care if it takes a while to update, but killing the connection and causing high bufferbloat is a real nuisance. Also, codel, whilst nice and simple, won't cut the mustard either since I need HSFC so that my VOIP is optimised for low latency (which doesn't work due to the bufferbloat effects of Windows Update)
-
@w0w:
Just update to CU and do proper settings in Update and Security (deferring, branch, active hours, "how updates are delivered" or even pause the updates).
Also setting metering connection can help you.Unfortunately I can't really avoid doing updates. Getting these computers updated is necessary as part of the setup as we need to ensure that there are no problems with updates before returning them to clients. If there's a Windows update that breaks audio for example, we need to know about it. Mostly residential work so I can't use WSUS sadly.
@Harvy66:A common reason for Window's Updates decimating a connection is because of low latency connections with little bandwidth, causing TCP to not honor congestion signals. There's not much you can do about this because of an unnatural relation between provisioned bandwidth and latency.
You could potentially artificially delay these packets using dummynet, assuming this is the issue. If the issue is just normal bandwidth saturation with lots of connections and high bufferbloat, then just enable CoDel.
Hmm. Is there any way to identify Windows Update traffic and dump it all in a queue of some sort that is only allowed a maximum of 5mbit/0.5mbit? I don't care if it takes a while to update, but killing the connection and causing high bufferbloat is a real nuisance. Also, codel, whilst nice and simple, won't cut the mustard either since I need HSFC so that my VOIP is optimised for low latency (which doesn't work due to the bufferbloat effects of Windows Update)
You can use codel within HFSC by ticking the "Codel Active Queue" toggle on whichever queue(s) you want.
-
dump it all in a queue of some sort that is only allowed a maximum of 5mbit/0.5mbit? I don't care if it takes a while to update, but killing the connection and causing high bufferbloat is a real nuisance.
If the issue is low latency, reducing the bandwidth will not help. If the CDN is trying to send 20Mb/s at a 10Mb/s connection and refuses to slow down, no amount of shaping will make that any better. If this is the cause, you need to increase the latency.
The minimum bandwidth TCP will consume is (2*MTU)/RTT. Assuming a 12,000bit(1500byte) MTU and 10ms ping, the slowest rate TCP will send, assuming data to be sent, is 1.2Mbit/s. 5ms would be 2.4Mbit/s. This is per connection.
If you had a 1Mbit/s connection with a latency of 10ms, the sender would flood you with 1.2Mbit/s of data even though 17% of the packets are being lost.
-
dump it all in a queue of some sort that is only allowed a maximum of 5mbit/0.5mbit? I don't care if it takes a while to update, but killing the connection and causing high bufferbloat is a real nuisance.
If the issue is low latency, reducing the bandwidth will not help. If the CDN is trying to send 20Mb/s at a 10Mb/s connection and refuses to slow down, no amount of shaping will make that any better. If this is the cause, you need to increase the latency.
The minimum bandwidth TCP will consume is (2*MTU)/RTT. Assuming a 12,000bit(1500byte) MTU and 10ms ping, the slowest rate TCP will send, assuming data to be sent, is 1.2Mbit/s. 5ms would be 2.4Mbit/s. This is per connection.
If you had a 1Mbit/s connection with a latency of 10ms, the sender would flood you with 1.2Mbit/s of data even though 17% of the packets are being lost.
I think that's incorrect. All TCP algos slow down when congestion is encountered. AFAIK, it's part of the spec that TCP algos must slow when congestion is detected. There is no "refuses to slow down" with TCP.
-
Interesting. Didn't know about Codel within HFSC and the mechanics of TCP. Either way, this issue is partially solved for me - I found a regedit that will disable the TCP flooding madness and instead revert to a more traditional form of fetching Windows Updates which is far more controllable: https://forums.whirlpool.net.au/forum-replies.cfm?t=2530363&r=53760513#r53760513
That said, silly question - do you enable codel on the just the qInternet parent queue (not the interface) or do you enable it on each desired subqueue as well..? or only on queues that have a "max bandwidth" limit defined for the queue?
-
dump it all in a queue of some sort that is only allowed a maximum of 5mbit/0.5mbit? I don't care if it takes a while to update, but killing the connection and causing high bufferbloat is a real nuisance.
If the issue is low latency, reducing the bandwidth will not help. If the CDN is trying to send 20Mb/s at a 10Mb/s connection and refuses to slow down, no amount of shaping will make that any better. If this is the cause, you need to increase the latency.
The minimum bandwidth TCP will consume is (2*MTU)/RTT. Assuming a 12,000bit(1500byte) MTU and 10ms ping, the slowest rate TCP will send, assuming data to be sent, is 1.2Mbit/s. 5ms would be 2.4Mbit/s. This is per connection.
If you had a 1Mbit/s connection with a latency of 10ms, the sender would flood you with 1.2Mbit/s of data even though 17% of the packets are being lost.
I think that's incorrect. All TCP algos slow down when congestion is encountered. AFAIK, it's part of the spec that TCP algos must slow when congestion is detected. There is no "refuses to slow down" with TCP.
TCP defines "bandwidth" as the window size. Current implementations of TCP can't slow down to less than 2 segments in flight. That is where "(2*MTU)/RTT" comes from. It's possible some paced versions of TCP don't have this issue.
-
Windows update is on port 80 or 443
Pfsense can't tell the difference from that and a browser
I'd suggest setting up fairq shaper with codel check box enabled.
Set it on both lan and wan at 95% of your link speed.
This will prevent Windows updates from totally dominating your connection
-
I've done that. Even when going through the wizard I'll get somewhere between 80-200ms ping on my VOIP PBX when the link is saturated, which means voice calls can be very patchy.
-
Are you sure that your shaper works? The wizard creates standard rules and most of cases you must manually assign ports and queues in desired rules. Do you see any drops on Status - Queues page under heavy traffic?
Also I did not recommend you to avoid updates, but suggested to try change some settings, anyway it wont help you in this situation, sorry.
The best solution to your problem is to have some really good connection, something over 300Mbps down. If you will shape the updates traffic it is going to slow down and your productivity also goes down. If you don't care about delivery time and can wait some more hours then you must change the shaper model and make default queue with lowest priority and send all other traffic (VoIP, whatever else) to others queues with highest priorities, but it will work only when all parameters are set correctly, like bandwidth. You should see drops in your low-priority default queue, when everything is set correctly. Also, make sure that your pfSense hardware is powerful enough to do shaping.
Remember also that WU uses HTTP(S) and therefore anything else using HTTP(S) will be also laggy. There is nothing to do untill you have the complete microsoft server list.
The solution on windows side (may be complicated or not applicable to some windows versions):
https://answers.microsoft.com/en-us/windows/forum/windows_7-networking/windows-update-takes-all-my-bandwidth/e2edb296-5501-4843-ae33-eaac11e1adb1?page=2Setting the bandwidth allocation for Background Intelligent Transfer Service (BITS) using the group policy setting below would be the most appropriate way of throttling the Windows Update Service.
LCP > Computer Configuration > Administrative Templates > Network > Background Intelligent Transfer Service (BITS)> Limit the maximum network bandwidth for BITS background transfers
I’d suggest the following;
Limit background transfer rate (kbps) to : 10
From : 8AM
To : 6PM
At all other times : Use all available unused bandwidth
LCP > = just run gpedit.msc
and also look for "Limit the maximum network bandwidth for peer caching" -
Honestly, I've been fairly unimpressed with the shaping functionality in PFSense. I have floating rules that match devices and destination SIP addresses to the VOIP queue, but I'm really not too sure what is going on and whether my queues are effective or not. My pings on my workstation are much higher than my VOIP PBX I might add, and I tried using ntopng to analyse what is happening but it's not really telling me in a clear fashion what exactly is happening, whilst absolutely destroying my J1800 CPU (load average of around 2.5 with ntopng enabled - yes, I leave it disabled now). I know it is mostly to do with not knowing exactly what I'm doing, but as someone who has been working with networks for quite some time (10+ years), I don't think it should be this hard. Coming from Gargoyle, it's pretty overwhelming, and whilst I see the appeal in fine-tuning, even the wizard isn't getting me out of trouble.
I just switched back to Gargoyle on my old TP-Link 740N for the meantime on my ADSL link and shaping now works as expected. It also allows me to shape streams that exceed a certain session length (therefore allowing me to prioritise web browsing over HTTP downloads). I don't know why that particular functionality seems difficult or impossible in PFSense. I'll probably switch back once we have a better connection and more time to learn PFSense shaping wizardry (only have around 10/1 at the moment).
-
I thought pfSense's traffic shaping is easy to use and I had zero experience with networks when I first set it up. By "easy", I mean easy to use relative to the power it gives. I spent several days reading about shaping, but all of the tutorials were confusing. Eventually I just figured it out on my own after a few hours of playing.
-
dump it all in a queue of some sort that is only allowed a maximum of 5mbit/0.5mbit? I don't care if it takes a while to update, but killing the connection and causing high bufferbloat is a real nuisance.
If the issue is low latency, reducing the bandwidth will not help. If the CDN is trying to send 20Mb/s at a 10Mb/s connection and refuses to slow down, no amount of shaping will make that any better. If this is the cause, you need to increase the latency.
The minimum bandwidth TCP will consume is (2*MTU)/RTT. Assuming a 12,000bit(1500byte) MTU and 10ms ping, the slowest rate TCP will send, assuming data to be sent, is 1.2Mbit/s. 5ms would be 2.4Mbit/s. This is per connection.
If you had a 1Mbit/s connection with a latency of 10ms, the sender would flood you with 1.2Mbit/s of data even though 17% of the packets are being lost.
How TCP works, if packets start being dropped, and ack starts being missed, the sender is informed to slow down. Strictly speaking, they're not obligated to listen, but microsoft will
