This has been approached a few times on the community, i would take a look at the following threads to see if they can help:
Review the log files o fthe system in question and see where it is downloading it from, i woudl imagine that it is pulling from a peer that has limited bandwidth or is pulling from a package server with limited bandwidth. Lastly, i would check the bandwidth availability on the system, it may have very little or be performing other actions at the time. The links above should help get you close to an answer.
Thanks for the response. After looking at some logs on the core and clients I'm wondering if my Bandwidth Throttling issues aren't a result of something configured in our infrastructure.
I spoke with our router/switch guy and asked a bit about how ICMP was handled on our network. He explained to me that ICMP has a very low priority (from a QOS standpoint) on all our switches, as it should be. He also mentioned that since ICMP has a very low priority, if a large file is being downloaded to a machine on a specific switch port the download would take priority over any other traffic. If this is the case, ICMP would be put at the bottom of the priority list on the switch.
My question is this: If ICMP is the bandwidth detection protocol enabled on the agent and the agent is trying to download a large file, at the same time requesting ICMP bandwidth detection queries from the switch and other peers on the subnet/pref server/core server etc., wouldn't ICMP requests respond much slower during that time, potentially causing Dynamic Bandwidth Throttling to detect a slow connection and throttle the download way back?
I know it's a long question, but if you get what I'm saying my issue, and a few other people's issue, might be simply the switch thinks it's busy, which it is, and LANDesk receives a "busy" from the switch which makes it throttle back it's distribution.
If this is the case, do you turn off bandwidth throttling all together or just deal with potentially slow or sporadic downloads?
One additional question: Do most of us turn off dynamic bandwidth throttling in our agent configs and only turn it on in the Delivery Method? I currently have it enabled in my agent configs which might be where some of my inconsistent testing has come from, i.e. turned everything off in my delivery method but the connection is still throttled.
Thanks for your help if you can shed some light.
I will try to answer the network stuff the best i can. ;-)
In terms of ICMP, I don't believe it should be causing the issues you are seeing unless it is being blocked and that would lead to other issues. ICMP is setup that way in most environments from my knowledge. But I will leave it up to the other network/LD gurus that may have more technical chops on it?
In terms of teh agent config - I have always heard(from LD) to not check the enable dynamic bandwidth throttling in the agent as that will take precedence over anything. I only enable it in the delivery methods when needed that way it can be more granularly controlled. I would try changing that in the config send it out and redo the test.
Yeah, I figured ICMP having a low priority was pretty standard. I figured it was worth asking anyway. If it turned out ICMP having a low priority was what's causing our download throttling issues I could try out PDS or simply turn off Bandwidth Throttling all together. If anyone has any facts on how ICMP and priorities on switches (QOS) work together I'd still be very interested to hear what you have.
I'm getting ready to roll out new agents anyways so I'll be testing how our distributions function without any Bandwidth Throttling at all. I guess my gripe would be if Bandwidth Throttling has the potential of causing a distribution that should take 2 minutes take 5 hours, maybe LANDesk should remove the check box for the global Bandwidth Throttling toggle. I've had that on since 8.5 and never noticed much of a difference until we started rolling out larger and larger packages. I also didn't seem to notice much until later versions of LANDesk, like maybe 8.7+.
In this particular case I pushed the large Office package mentioned above to a user in the same building as the Core Server (also the package server), on a Gig network and the user wasn't logged into the box all day. I started the package at 8am and it finished up downloading sometime after 4pm when I left for the day. To me, something isn't right with that logic. Even if you have DBT turned on, shouldn't it detect that there is a whole bunch of available bandwidth and speed things up a bit? When I went and checked on it at 4pm it was downloading at about 30k/second.
When you say the office package, are you pushing it out as one file or many files? I did not ask before, but are you using UNC's, DFS or HTTP for the package download pt? The reason i ask, is that we have seen weird things like this for DFS share. Just to check, have you tried to do a straight copy the file to the system in question and see the results?
It's 2 files, one VBS that handles the unpack and sets a RUNONCE and one 660MB RAR'ed up EXE. Downloading directly from the package server via file copy is very fast, no issues there. Our package servers are set up as UNC shares.
OK, I think I figured out my issue. I did 2 things that dramatically increased my download performance:
1. Unchecked "Enable dynamic throttling" in my agent config and re-pushed to my test boxes. I don't think this is what helped the download but it's one thing I did.
2. Modified the PSP Delivery Method by changing the Download Timing for both peer and source from "1" to "0". I even left Dynamic Bandwidth Throttling enabled in the Delivery Method and the Minimum available bandwidth was still set to 50%.
When I restarted the task on my test boxes, the 660MB download took less than 1 minute where it took over 8 hours the other day. I tried the same package again while throttling the download to only 25% and it still went very, very fasy. Took about 2 minutes this time. Since we're deploying from Package Servers on the local subnets of each of our sites this works perfectly. I'd rather flood the network with downloads for 20 minutes or so than risk a reboot or loss of connection after several hours of throttled downloads. We also have over 500 laptops in our environment and they are hard to get a hold of. If I can slam this package down to them for the hour they are online at a site each week that's what I need to do. I don't want them pulling Office 2007 through our LDMG.
By default, the values in peer and source download in my delivery methods are all set to "1". If this is the cause of my issues, perhaps the default could be set to "0" in a previous release. I never even thought to modify the download timing options since the Bandwidth Throttling options are much more prevalent throughout the agent configs and Delivery Method wizards. Just my 2 cents.
Glad to hear, ultimately what steps you took to figure it out were exactly what the links were getting at and the best way to troubleshoot things like that.