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
>