Interesting? I've always used the default lzop compression and
have not noticed the difference with it. In the past doing a regular
image with gzip would take twice as long as lzop and would give a
10% better decrease in size. So, I go for speed and less CPU
load. In test lzop would put 30% load on systems, but gzip would
put 90%. Will have to see if the nosync makes a difference with
lzop compression.
On 30 Nov 2011 at 11:30, Raul Sanchez wrote:
Subject: Re: [Udpcast] udp-receiver and gzip SLOW
From: Raul Sanchez <raul(a)um.es>
To: "Michael D. Setzer II"
<mikes(a)kuentos.guam.net>
Copies to: udpcast(a)udpcast.linux.lu
Date sent: Wed, 30 Nov 2011 11:30:30 +0100
Hi:
I have been testing this days g4l and other options and I think that
the difference between old udpcast and new udpcast is that --nosync
was a default option ( with -p 'gzip -dc') and now it is not.
If I force --nosync it works ok with new kernels, so it is possible
that the were at the kernel.
I'm cloning machine now at 80Mb/s. For me, it's ok
thank you for all
El sáb, 26-11-2011 a las 09:40 +1000, Michael D. Setzer II escribió:
I maintain the g4l disk imaging project that
includes udpcast as >
options, and on some occassions it has kernel support for
> hardware
that the website does yet support. > > The latest version I have is >
the
sourceforge site has the latest release version. > Generally, I
use the lzop compression as default, since it is about > twice as fast
as gzip, but does make a 10% larger image. > > I haven't done a lot
using PXE with the g4l, but have just copied > one of the kernel files
and the ramdisk.lzma file and set it up using > PXE or Grub or
Grub4DOS. > > If you do try it, I would like to know if the hardware
is seen and > works with the g4l.. > > Good Luck. > > > On 25 Nov 2011
at 11:41, Raul Sanchez wrote: > > From: Raul Sanchez
<raul(a)um.es> > To: udpcast(a)udpcast.linux.lu > Date sent:
Fri, 25 Nov 2011 11:41:58 +0100 > Subject: [Udpcast]
udp-receiver and gzip SLOW > > > Hello: > > > > I'm using
udpcast for
years and any problem has occurs to me. > > > > Now we have bought new
pcs and i wan't to use pxe + udpcast to clone > > them. I have 2
differents types of network card and the others pieces > > of the pcs
are the same. The only different is the network chip > > (AR8131 and
AR8151) > > > > I have my image un gzip mode and... I have made this
tests > > > > 1. cast'o matcic kernel 2009 november. Works fine in
AR8131. kernel > > module (atl1c doesn't work with AR8151).
(udp-receiver --file /dev/sda > > -p 'gzip -dc') 2. Cast'o matic.
Kernel 2.6.39.3. Works VERY SLOW using > > gzip in AR8131 and AR8151.
(udp-receiver --file /dev/sda -p 'gzip > > -dc'). But works quick with
udp-receiver --file /dev/sda without gzip > > 3. Boot with ubuntu
11.10 live cd. apt-get install udpcast. > > udp-receiver --file
/dev/sda -p 'gzip -dc' works fine so... 4. Install > > makeImage in
ubuntu 11.10. make initrd with modules and ... pxe + > > initrd
(11.10) + kernel 3.0.0-12 (and 13 too). same kernel and modules > >
than Ubuntu 11.10.udp-receiver --file /dev/sda -p 'gzip -dc' very slow
> again. udp-receiver --file /dev/sda works
fine 5. Same than 4, but
> compiling busybox 1.18.5 and 1.19.xx and same result. Slow with
gzip >
> 6. ubuntu kernel + makeinitramfs + copy same libraries + copy
busybox > > (ubuntu 11.10) + copy udpcast (ubuntu 11.10 apt install) +
copy gzip > > (ubuntu 11.10). Same result. Slow with gzip 7. I have
probe with > > diverse versions of udp-receiver and udp-sender and the
same result > > (slow with gzip) 8. If you probe that cases with
--nosync in > > udp-receiver and gzip it works but when it have spent
about 10 Gb, > > computer reboots > > > > So ... when you use old
kernel and modules and network card is > > supported it works fine. >
> > New kernels and modules fails with gzip
compression. > > > > I
have found that with 'ps' in pxe boots
you can see several instances >
of udp-receiver but in live cd you only see one.
It can be by the
way > > ps show information. And I have boot appending
maxcpus=1
option to the > > kernel and the result has been the same. > > > > In
all cases network cards is working at 100Mbps > > > > It seems that
livecd after make the 'pivotroot' start any service or > >
"anything"
that increases hard drive performance. > > > > > > It will be nice any
idea. > > > > Thank you very much > > > > Regards > > >
> > > > > > >
> > >
_______________________________________________ > > Udpcast
mailing list >
> Udpcast(a)udpcast.linux.lu > >
https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast > > >
+----------------------------------------------------------+ >
Michael D. Setzer II - Computer Science Instructor > Guam
Community College Computer Center >
mailto:mikes@kuentos.guam.net >
mailto:msetzerii@gmail.com >
http://www.guam.net/home/mikes > Guam
- Where America's Day Begins > G4L Disk
Imaging Project maintainer >
http://sourceforge.net/projects/g4l/ >
+----------------------------------------------------------+ > >
http://setiathome.berkeley.edu (Original) > Number of Seti Units
Returned: 19,471 > Processing time: 32 years, 290 days, 12 hours, 58
minutes > (Total Hours: 287,489) > > BOINC@HOME CREDITS > SETI
11466027.143632 | EINSTEIN 6907565.249851 > ROSETTA
3963112.556472 | ABC 9455189.531355 >
+----------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor
Guam Community College Computer Center
mailto:mikes@kuentos.guam.net
mailto:msetzerii@gmail.com
Guam - Where America's Day Begins
G4L Disk Imaging Project maintainer
(Original)
Number of Seti Units Returned: 19,471
Processing time: 32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)
BOINC@HOME CREDITS
SETI 11487929.167679 | EINSTEIN 6929848.069851
ROSETTA 3980434.323509 | ABC 9528205.020544