Hello,
I use udpcast for test. I make and image of /home with or without compression perfectly. But when I want to send image , if there is no compression it's Ok (some timeout notAnswered[0]...but finally it's ok) When I use lzop or gzip, I get an error sometimes on the sender, sometimes on the sender : I have a lot of Timeout notAnswered=[0} notReady=[0] nrAns=0 nrReady=0 nrPart=1 avg=8121 and so on...
Dropping client because of timeout lzop <stdin> checksum error... or invalid operand PREEMPT and crash server ! process udp-sender Stack ... Call Trace ... or Gzip stop Bad EIPvalue SIGSEGV .... And strange thing .. With no compression the speed is 80Mbps with lzop 20 Mbps with gzip 7Mbps
My CPU is an Athlon 2400+ (not so bad), I use kernel 2.6.8 on a Debian Sarge.
Any ideas ?
Thanks
Pierre
Hi Pierre,
On Tue, 2005-12-27 at 12:25 +0100, Pierre CANAL wrote:
Hello,
I use udpcast for test. I make and image of /home with or without compression perfectly. But when I want to send image , if there is no compression it's Ok (some timeout notAnswered[0]...but finally it's ok) When I use lzop or gzip, I get an error sometimes on the sender, sometimes on the sender : I have a lot of Timeout notAnswered=[0} notReady=[0] nrAns=0 nrReady=0 nrPart=1 avg=8121 and so on...
Dropping client because of timeout lzop <stdin> checksum error... or invalid operand PREEMPT and crash server ! process udp-sender Stack ... Call Trace ... or Gzip stop Bad EIPvalue SIGSEGV .... And strange thing .. With no compression the speed is 80Mbps with lzop 20 Mbps with gzip 7Mbps
i had the same problem and if i used a "server" to save the images and use udp-sender with lzop or gzip, i got allways a timeout and the copy fails. The performace with gzip was worst and with lzop much better, too.
My main problem is, that it is actually impossibile, to save images on a server and copy them on a machine. I am still searching for a solution. :-(
My CPU is an Athlon 2400+ (not so bad), I use kernel 2.6.8 on a Debian Sarge.
I used a Pentium IV 2,4 with 1 GB RAM in the server and fast S-ATA drives.
Regards Thomas Kuehling
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Not sure it will help, but G4L is designed to make compressed images to an ftp server, and these images can then be used with udpcast. It basically uses dd lzop or gzip and ncftp. Might be worthing seeing if it can create an image that could work for your setup.
On 27 Dec 2005 at 16:04, Thomas Kuehling wrote:
Subject: Re: [Udpcast] udpcast gzip and lzop From: Thomas Kuehling thomas.kuehling@mapsolute.com To: Pierre CANAL pierre.canal@gmail.com Organization: Mapsolute GmbH Date sent: Tue, 27 Dec 2005 16:04:26 +0100 Copies to: udpcast@udpcast.linux.lu Send reply to: thomas.kuehling@mapsolute.com mailto:udpcast-request@udpcast.linux.lu?subject=unsubscribe mailto:udpcast-request@udpcast.linux.lu?subject=subscribe
Hi Pierre,
On Tue, 2005-12-27 at 12:25 +0100, Pierre CANAL wrote:
Hello,
I use udpcast for test. I make and image of /home with or without compression perfectly. But when I want to send image , if there is no compression it's Ok (some timeout notAnswered[0]...but finally it's ok) When I use lzop or gzip, I get an error sometimes on the sender, sometimes on the sender : I have a lot of Timeout notAnswered=[0} notReady=[0] nrAns=0 nrReady=0 nrPart=1 avg=8121 and so on...
Dropping client because of timeout lzop <stdin> checksum error... or invalid operand PREEMPT and crash server ! process udp-sender Stack ... Call Trace ... or Gzip stop Bad EIPvalue SIGSEGV .... And strange thing .. With no compression the speed is 80Mbps with lzop 20 Mbps with gzip 7Mbps
i had the same problem and if i used a "server" to save the images and use udp-sender with lzop or gzip, i got allways a timeout and the copy fails. The performace with gzip was worst and with lzop much better, too.
My main problem is, that it is actually impossibile, to save images on a server and copy them on a machine. I am still searching for a solution. :-(
My CPU is an Athlon 2400+ (not so bad), I use kernel 2.6.8 on a Debian Sarge.
I used a Pentium IV 2,4 with 1 GB RAM in the server and fast S-ATA drives.
Regards Thomas Kuehling -- Mapsolute Gmbh - Techn. Administration - TK2325-RIPE Düsseldorfer Straße 40a - 65760 Eschborn/Frankfurt a.M. - Germany Phone: +49 6196 777 56 413 - Fax: +49 6196 777 56 100 E-Mail: thomas.kuehling@mapsolute.com - web: http://www.mapsolute.com
Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/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 +----------------------------------------------------------+
http://setiathome.berkeley.edu Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489)
Hello,
In udpcast it is normal to get some "timeout not answered" when the receiving buffer is full and the bottleneck is on the compression or write to disk. It just means the sender wanted to provide more data and the receiver couldn't handle it at that second.
However the other errors are more significant and cause real failure. I'd try another client machine and see if the same happens, or boot up a Linux rescue disk/CDROM of some sort and try a memory testing program to see if that part of the hardware is reliable when pushed for 30 minutes or more.
--Donald Teed
On Tue, 27 Dec 2005, Pierre CANAL wrote:
Hello,
I use udpcast for test. I make and image of /home with or without compression perfectly. But when I want to send image , if there is no compression it's Ok (some timeout notAnswered[0]...but finally it's ok) When I use lzop or gzip, I get an error sometimes on the sender, sometimes on the sender : I have a lot of Timeout notAnswered=[0} notReady=[0] nrAns=0 nrReady=0 nrPart=1 avg=8121 and so on...
Dropping client because of timeout lzop <stdin> checksum error... or invalid operand PREEMPT and crash server ! process udp-sender Stack ... Call Trace ... or Gzip stop Bad EIPvalue SIGSEGV .... And strange thing .. With no compression the speed is 80Mbps with lzop 20 Mbps with gzip 7Mbps
My CPU is an Athlon 2400+ (not so bad), I use kernel 2.6.8 on a Debian Sarge.
Any ideas ?
Thanks
Pierre
Hi,
On Tue, 2005-12-27 at 11:04 -0400, D Teed wrote:
Hello,
In udpcast it is normal to get some "timeout not answered" when the receiving buffer is full and the bottleneck is on the compression or write to disk. It just means the sender wanted to provide more data and the receiver couldn't handle it at that second.
i know, but at one point, i'll get only TimeOuts, the HDDs where i want to mirror to are working and then the i got an error. At the moment, i couldn't get more information, because the point of the abort is sporadic.
However the other errors are more significant and cause real failure. I'd try another client machine and see if the same happens, or boot up a Linux rescue disk/CDROM of some sort and try a memory testing program to see if that part of the hardware is reliable when pushed for 30 minutes or more.
If i could help you, message me please. I am back at office on the 2nd of January and try to rebuild the szenario.
--Donald Teed
On Tue, 27 Dec 2005, Pierre CANAL wrote:
Hello,
I use udpcast for test. I make and image of /home with or without compression perfectly. But when I want to send image , if there is no compression it's Ok (some timeout notAnswered[0]...but finally it's ok) When I use lzop or gzip, I get an error sometimes on the sender, sometimes on the sender : I have a lot of Timeout notAnswered=[0} notReady=[0] nrAns=0 nrReady=0 nrPart=1 avg=8121 and so on...
Dropping client because of timeout lzop <stdin> checksum error... or invalid operand PREEMPT and crash server ! process udp-sender Stack ... Call Trace ... or Gzip stop Bad EIPvalue SIGSEGV .... And strange thing .. With no compression the speed is 80Mbps with lzop 20 Mbps with gzip 7Mbps
My CPU is an Athlon 2400+ (not so bad), I use kernel 2.6.8 on a Debian Sarge.
Any ideas ?
Thanks
Pierre
Udpcast mailing list Udpcast@udpcast.linux.lu https://lll.lgl.lu/mailman/listinfo/udpcast
Could you just check that you aren't accidentally attempting to uncompress a same image twice (once on the sender (image server) and once on the receiver?). This will fail because at the first decompression, the data is not longer a compressed archive, and will no longer match a checksum. Usually, in the interest of bandwidth, decompression should be done on the workstations to be imaged (receivers), and not on the image server. That is, on the image server, you should not use a "-p lunzop" option or something similar.
Regards,
Alain
-
Alain Knaff -
D Teed -
Michael D. Setzer II -
Pierre CANAL -
Thomas Kuehling