Good to hear it was resolved. When you said that it aborted at random points, I thought hardware could be involved, and compression would push the heat, etc more than straight data flow.

Be careful comparing the data transfer rate. That doesn't measure how fast you are writing the info to disk, and in the end, that is the only thing that matters in the performance of udpcast. Time the job with a clock/watch and compare the times.

In my experience, udpcast is just as fast than an FTP based solution when comparing the same image and hardware on all ends.

lzop uncompression will perform much better than gzip on older CPUs and possibly on other platforms like Sun sparc. Otherwise gzip is fine for something like a P4 generation target client.

At our institution, using gzip, we write 40GB to P4-M notebooks in 34 minutes, regardless how much non-zeroed data there is to write (e.g. Windows only, or Windows + Linux partition = same time to write), and regardless how many notebooks we image in a session.

--Donald Teed

On Wed, 28 Dec 2005, Pierre CANAL wrote:

Hi,

Now It's Ok !!! It was the memory ! I change slot's memory I test during 4 hours and no problem. I make new images et restore it with no fail ! But 80 Mbps with no compression 25 Mbips with 3/1 lzop compression 17 Mbips with 3.6/1 compression It's faster without compression !!!

I hope, I'll find a multicast ftp to increase the speed in case of quasi empty partition...

Thank a lot

Pierre