New DS Settings - 300% Faster Imaging... - Page 2

LordofthePatch · 04-27-2005, 11:02 AM

Has anyone successfully tweaked these settings to improve speeds with PXE & multicasting? I only notice loss of performance when applying them.

LordofthePatch · 04-28-2005, 10:34 AM

I just modified our boot floppy to use the new settings, and my throughput rates average about 200 MB/min with spikes right above 300.

mcsemarko · 04-29-2005, 04:51 PM

I made these changes to the boot files and when I boot I get a NET0001: Error accessing NEMM.dos error.

Any ideas?

LordofthePatch · 04-29-2005, 04:58 PM

That is usually related to the correct device not being found for the driver that is included on the floppy. Look closely and you should see more error messages before it gets to that line.

holpak · 05-06-2005, 04:06 PM

was this thread just for downloading image speeds?? I'm uploading and image and notice no change just with using pxe...it still averages between 250-350mb.. is this a pretty normal speed with everyone?

Holly

Nick · 05-07-2005, 12:12 AM

That sounds about right Holly. I've seen faster but with those speeds, if they are stable, you should be uploading about 1 GB every 3 to 4 minutes.

JeremyDallas · 05-07-2005, 01:06 AM

Yes Holly, it's for downloading only. You're setting the windowsize on the client side to allow more data to flow through before each ACK is sent. Because IP is reliable, it sends an acknowledgement back to the sender each time it receives data to say "I got it" (ACK = Acknowledgement).

The same can be true on the server side. By increasing the RWIN and MTU, ACK's are fewer and there is less latency and less overall packets. The problem with this is that the TCP Window Size (RWIN - Receive Window) and MTU that you set should be directly related to the connection speed that you have. By changing this on the server side, if you have some computers that are on the local LAN and others on a WAN, you can cause severe issues with speeds on WAN computers by optimizing it for LAN (increasing the window size). This is because there is a greater chance that this entire packet will not make it through, which requires the packet to have to be sent again. All of the re-transmissions will make the overall speed much slower then the default. The windows default is usually the best.

Frame-Relay connections can truly suffer from high MTU and RWIN settings because of how most frames are setup. There is a base speed of X and a burst speed of Y. Any bandwidth that is over X can be dropped if another packet (or group of packets) need that bandwidth and they are within their X base speed.

Hopefully this is somewhat helpful in understanding why you are gaining speed one way and how you might be able to gain speed another way.

dclapp · 05-11-2005, 10:17 AM

I don't see where you listed any settings/information? Amy I missing something?

Quote:

Originally Posted by Jeremy_Dallas

Hey Guys,

I had been sitting on this information for about a week from Altiris and it was killing me not to be able to share it. Altiris just gave the go ahead, so here you go.

Nick · 05-11-2005, 10:34 AM

David,

Check the post right after Jeremy's first one. For some reason the information got removed from his post. I added it to mine and included a screenshot of the table listing the settings.

holpak · 05-12-2005, 11:54 AM

thanks guy for all the explanation.. i'm so glad this info was saved, with most of our images being around 2.5Gig it used to take about 23min to download sometimes only 20 but now it is only taking an average of 8 min. That's awesome. We finally got our admin's to fix our ports they were not set to auto.. and we also got a new server, i can't beleive how fast everything is now. It used to be that uploading and image took a day and a half, we would run at like 5mb/min... ughghg and our admin's thought this was normal??!! I kept pickin at them to do something about this finally they answerd my prayers.. 350-400mb is now our average.. upload.. i've seen it burst to 460 My life is so much easier now. Now i can easily make new images and play around with different settings all in the same day tons of times.

Anyhow...i'm so glad i found a forum to help me along... seeing how i wasjust thrown into these responsibilities.. now i want to see and learn all the cool things i can do with deployment server.

Holly

LordofthePatch · 05-12-2005, 12:30 PM

Quote:

Originally Posted by holpak

...seeing how i wasjust thrown into these responsibilities.. now i want to see and learn all the cool things i can do with deployment server.

I believe this is why this site was created. All of us, at one point or another, was thrown into Altiris. Not a whole lot of textbook knowledge here, rather as Nick once said, we have all attended the "School of Hard Knocks".

We don't feel right letting people struggle through obstacles someone else has already gone through. What a bunch of softies!!!

Kamino · 05-17-2005, 05:48 AM

Quote:

Originally Posted by clfrnacwby

All of us, at one point or another, was thrown into Altiris.

that completely sums up my situation, i.e;

Boss: YOU! learn about altiris!
Me: Um... alti-wha?

JAustgen · 06-13-2005, 02:36 PM

If you're like me and spent some time trying to figure out why the modifications you've made to the protocol.ini file with tcpwindowsize suddenly break your boot disk, I have the answer.

Don't include commas in the tcpwindowsize=

It's amazing how well it works when you don't do that.

Nick · 06-13-2005, 02:40 PM

Original post with the picture was edited to protect the innocent.

mattontiptoes · 06-20-2005, 11:12 AM

Where's the info ?

LordofthePatch · 06-20-2005, 11:48 AM

Go to the first page of this thread and take a look at the second post (by Nick, of course

) there is an embedded screenshot.

scott_in_mesa · 07-05-2005, 06:10 PM

Also look forward to DS 6.5 due out later this year. This version will be creating a temporary linux partition on the clients and promises to REALLY speed things up.

Scott

bday · 07-14-2005, 02:56 PM

I hate to be picky where these gains are already incredible, but has anybody ever gotten Altiris imaging to be as fast as Symantec Ghost is? I am a bit spoiled with Ghost taking 2-3 minutes to dump a 2GB image from the server to a machine and about 5-6 to upload an image to the server.

It just took me 18 minutes to upload an image with Altiris with the same laptop I uploaded an image in about 4 minutes earlier today with Symantec Ghost. Is it safe to assume that using the universal network driver is the catch here? Does anyone want to walk a newbie through using identifiying and using the correct driver during PXE?

bday · 07-14-2005, 04:16 PM

I just ran a test...

Sending an image to a Dell Latitude D600

Altiris: ~130MB / Minute with peaks in 150MB range
Symantec: ~725MB / Minute with peaks in 900 MB range

Our Symantec bootdisk is using the Broadcom driver and Altiris PXE is using the universal Intel driver.

JAustgen · 07-14-2005, 06:09 PM

Yeah, Altiris has never been as fast as Ghost. Even using NIC-specific drivers you aren't going to approach the speeds that Ghost can do. 6.5 should fix that, but it's a couple of months off, yet.

Nick · 07-14-2005, 09:14 PM

I forget exactly how Ghost reads the hard drive when it's capturing the image but I know that rdeploy does a file by file. This attributes to the slower speeds with rdeploy but, from what I've heard, gives a lower risk of corrupted data.

That being said, I have used Ghost quite a bit in the past and I can't remember a time it gave me corrupt data.

If you really want the speed of Ghost you can use it instead of rdeploy. You just lose the extra functionality that rdeploy offers. There are several organizations that use Ghost with Deployment Server.

theone97 · 09-07-2005, 05:38 PM

Greetings,

I tested all the available settings listed in the chart and all of the settings except for one yielded really slow performance:

For every tcpwindowsize value I got approximately anywhere between 3MB/min to 11MB/min. This is the case for 11,600 and 10,150 and 8,700, etc...

The only value that yielded above 11MB/min was a value of 4,350. 4,350 yielded a speed of about 95MB/min for upload.

Now, be aware that these speeds are for uploading only - copying a 1.7GB image to the server. These speeds are not for downloading - I have not tested that yet.

I have also turned off TCP Checksum Tx and Rx offloads on the server NIC as recommended by a help file from Altiris.

The speeds that people have listed on this thread - are they for downloading only? What about uploading speeds? If anyone could specify their upload speed or at least let me know if an upload speed of 95MB/min is decent I would really appreciate it.

Thanks,
Steve

PS: the client is connected directly to the same switch as the server is - there are no routers in this situation.

lscott · 09-09-2005, 12:12 AM

when I use anything above 5800, i get a 'tiny rfc' error. any ideas why?

the error is something like this (I'm not at work right now):

TCP access failure by Tiny RFC. Tiny RFC 1.0 not loaded.

James.B · 09-15-2005, 12:10 PM

Quote:

Originally Posted by Nick

I forget exactly how Ghost reads the hard drive when it's capturing the image but I know that rdeploy does a file by file. This attributes to the slower speeds with rdeploy but, from what I've heard, gives a lower risk of corrupted data.

That being said, I have used Ghost quite a bit in the past and I can't remember a time it gave me corrupt data.

If you really want the speed of Ghost you can use it instead of rdeploy. You just lose the extra functionality that rdeploy offers. There are several organizations that use Ghost with Deployment Server.

When we used to use ghost i rarely saw an image come down corrupted but we had about a 30% corruption rate when backing up. We never see that with altiris.

By the way our speed record using altiris is 1400mb/min

this was of course on a gig network

MikeMalsed · 01-30-2006, 05:05 PM

So thankful I found this place!!

I run all the labs, classrooms, and lecterns at a college here in Claremont - academic programs end up taking a LOT of space. . .argh. . .so our images tend to be big. . .and usually took ~20 minutes to drop.

Just made the three changes (10150, 2, 0) and image took just over 10 minutes. . .SOOO nice.

Has anyone tried this with multicasting yet? I do quite a bit of that and will let y'all know what I find.