Windows 10 updates bandwith limit
-
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?
-
to limit bandwidth for those domains with pfsense only way I can think of is by ASN but for all those domains far from ideal
-
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?
Yes, I have a slow aDSL WAN and Windows 10 seems to absorb all the bandwidth when downloading updates. I tried setting "Background Intelligent Transfer Service (BITS)" to limit the maximum network bandwidth for BITS background transfers, but it doesn't do it's job. So I need some form of QOS, but I have no experience with it. somehow reading through the treads here I can't seem to find a way to limit this transfer or to setup a form of traffic shaper that could work here.
When I use remote desktop it needs all available bandwidth to let me work from home. When not working I need a P2P connection through a VPN that uses about 350kB/s max and the divide whats left between a SONOS device and "browsing the internet.
Thanks for any help!
-
I think you better get a better connection if possible , with no layer 7 you can not identify windows updates
-
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.
