A few months ago, I noticed that Nomad had become really slow almost to the point that I thought I had a serious problem with my home lab. It did not matter if it was a virtual machine or a physical machine. Downloading content from a distribution point using Nomad had become painfully slow (averaging 1 blk/s). However, downloading without using Nomad was completely normal. I could also copy files using SMB from the distribution point at normal speeds and also download using HTTP using the browser. By the way, this is a good troubleshooting step. Look in the CAS.log for the DP location for the package, it will look something like this:
Then copy and paste that URL in IE or Edge
Then try downloading a big file and see what kind of transfer speeds you are getting with what you expect:
Downloading a similar package using Nomad yielded the following painful 1 blk/s (typically it would be about 100x this value):
This system is on a gig network with a gig interface card but only using 584 Kbps?:
Looking a little closer at the Network Activity in the Resource Monitor I saw PeerDist running and remembered that I had enabled BranchCache in my lab to do some testing:
Sure enough, the BranchCache service was running:
After stopping (and disabling) the BranchCache service, there was a little hiccup in the Nomad log:
But shortly afterward, things were back to normal (getting about ~30 Mbps):
Still a bit conservative on the network but at least it was moving along again:
Nomad log back to normal getting around 100 blk/s:
In summary, I will definitely be letting 1E know about this issue. BranchCache is used for things other than ConfigMgr traffic in the Enterprise (i.e. SharePoint and other web applications). Also, BranchCache could even be used for ConfigMgr traffic that Nomad does not handle (like WSUS, Automatic Client Deployment, etc.), even for Nomad customers!
Originally posted on https://miketerrill.net/
Mike's Tech Blog 
Or maybe just use BranchCache on its own? 😉
For some reason, I knew you were going to say that.
This only effects downloads from the DP, Nomad peer copy performance is unaffected. 1E plan on releasing a fix soon. In the meantime, the solution is to disable BC on your DP
Simon Burbidge
Not a good work around if you have non-Nomad clients using BranchCache that pull from the same DP.
Agreed. As I say, we’re currently creating a fix that can be applied to the Nomad agent to resolve it. Having said that, the vast majority of our customers will not be relying on branchcache on their DPs, but for the few that do, the fix will be provided. What’s happening, after the Nomad election, http headers invoking Branchcache are being added to the HTTP Get request made by Nomad to the DP. Branchcache then goes about broadcasting for the content on the subnet before downloading from the DP causing the delay. We can modify the header to ensure the download from the DP happens without delay.
Simon Burbidge
It’s also important to mention that in the current release of Nomad (6.3) with it’s Dynamic Block Size feature, the download delay with branchcache diminishes massively. Since the delay is caused per block request. 6.3 is able increase the block size up to 16MB – depending on bandwidth available of course.