Deployment Solution

Hello,

We are (and have been) experiencing decreased imaging speeds for some time now. I am no 100% sure the problem lies w/in Altiris, but have noted the axengine.exe CPU usage gets up near 80-90% when multiple computers are being imaged (rdeploy).  When one computer is imaging it is around 6%. I never noticed the CPU usage before, but we never had slow imaging speeds before. We could image up to 60 computers at once without significant loss in speed. Using PXE UNDI usually. Nothing in our Altiris setup (to my knowledge) has changed. WinPE transfers image much faster, but loading it takes pretty long.

Someone said we are running with too many clients on the server; around 6000. I backed up the DB, deleted it down to 3000, and noticed no improvement. I did this only to satisfy those who were questioning this; I never believed it.

It also experiences slowness when jobs copying files down to computers are run. Speed also decreases with number of concurrent connections.

Can someone point me in the right direction? I sense it is an system issue, but have not gotten much traction with that idea.

Suggestions? I feel I'm letting down our team by not fixing this quickly. Everything till works, but slowly when we are operating on many computers at once.

Server: IBM Blade, Windows Server 2003, Altiris DS 6.9 SP4, 3 Gb RAM, Image files are on same server, pxe running on this server

SQL: on separate server. We upgraded recently, but problem was occuring prior to upgrade

Are you multicast imaging 30 systems, or unicasting them?  60 via multicast will be no prob on the DS, but if you unicast that many, the DS will go nuts.

Thomas,

We are unicasting. UNDI does not support multicasting. As we migrate to WinPE, I imagine we'll do multicasting. Funny thing is, we were able to do these kinds of numbers unicasting before w/ decent speed.  Also, whenever I multicast a computer lab (education) one would sometimes fall off creating legwork and other headaches. I started testing multicasting as soon as we noticed the problem, and its reliability is bad enough to try to avoid at this time. WinPE will probably solve a lot of our problems

Thanks for you suggestion. I may work to see if we can accelerate WinPE and implement multicasting.

Don't get me wrong, what you see is what you see, and I'm not there.

However, imaging 30 systems with UNDI on a single DS is a performance killer.  The Engine has to distribute packets in 30 different streams all at the same time, keeping track of all 30 streams of packets that are never in synch.  That's a LOT of work!

If you multicast 30 systems, the engine only has to keep track of a single data stream.  True, the speed overall slows as it slows down to keep with the lowest common denominator, but overall, at least the engine only has to track a single data stream.  You could use 10 seperate 30system multicasts and have less work for the 30 unicasts.  You'd image 300 systems with 1/3 the work on the engine.

So, what you're seeing now is actually what I'd expect to see, if that makes sense.  I would expect to see slow imaging in DOS, and with UNDI drivers.  Remember, UNDI drivers aren't usualy even rev 1.0, so there's no performance tuning in those or anything.  They either work or don't.

Just wait to see what you get in WinPE with Multicast.  If the WinPE download is too slow, you can try Linux, but drivers are harder to come by.  Speed though in WinPE is amazingly fast.

GL!

PS>  Multicast failures do happen.  The "lowest common denominator" issue has a limitation to it.  Here's how it works, and I should let you know that there's less failure in WinPE than DOS with this due to greater memory access - you'll see.

You have a single multicast master that is streaming data from the DS to it's hard drive, and into RAM.  These packets all get spun up into ram, assembled into the correct order, and dumped to the drive.  They also get sent on to the multicast clients.

If a client falls behind, it pings the master for the packets it's missing.  The master doesn't just supply missing packets, it backs up and starts FROM the missing packet.  This is what slows the multicast down as it gets larger and larger.  Latency is a huge issue here.

If the master however doesn't HAVE the packet, it kicks the client from the stream, essentially saying "dude - too late - you're out!".  It doesn't go back to the DS to request the packet again, it simply moves forward.

Thus, failure in WinPE is less than in DOS, because of greater RAM access.  :D

Thomas,

Thanks for you reply. I'll continue to work on PE and Multicasting. It is the grail I seek, but if I can't get it to work consistently for our team, they'll accept slower speeds over dependability. We frequently image computer labs from remote locations. If one fails, we would have to go there and lay on hands possibly.

One problem I have with our PE is it does not seem to be using the PCIDetect when I select multiple drivers. I looked in the boot config, and did not see a copy of the pcidetect.exe (I think that's the filename) anywhere. 

Thanks loads for the multicast explanation. I've understood its workings in general, but did not know why some got kicked off part way through the imaging process. More work ahead, but hopefully with good results.