Michael D. Setzer II wrote:
Some questions about the setup. Is it one or two machines that is giving the timeouts? I have a lab of 20 machines, one was causing this problem. If I imaged all the others together there would be very few timeouts compared to thiis one. Turned out to be the hard drive in that machine, which was the same brand as all the others. In swapping the hard drive to another machine the problem moved from the one machien to the other. Ran diagnostics on the drive,and it reports no errors, but it doesn't seem to be able to keep up with writing the sections of the drive that are blank, so the compressed informaiton is coming in faster than the machine can write it to the disk. I've seen that these drives can only do about 45MB after the buffer gets full.
2 Machines if I'm reading the error message correctly... I don't quite understand what the error is trying to tell me. I'll try imaging them individually and see if the problem goes away. You're theory about the drive writing sounds plausible. I'll experiment, since I'm going to be doing this off and on for the next 6-12 months.
Also, what IP addresses are you using on the systems. I had a problem, whereas the College MIS has 3 Class C blocks all the the same physical network with a standard Class C subnet mask (Don't ask why??), and if I used dhcp it would only work with machines on the same class C. I ended up making an ipmac.txt file for the udpcast, and had it assign 10.0.7.x numbers to my machines (Lab D-7).
192.168.15.* But I'm doing my imaging completely off the external network. All that's on the network is the server and the machines that I'm imaging and they're all plugged into our HP 24 port switch.
Also, you could try a cross-over cable and directly connect two machines, and see if it differs from going thru the switch..
I'll give this a try as well, if I have time. If it is one of the machines... yuck... but if I'm interpretting the error correctly it is having a problem with both of them isn't it?
Another issue that you might want to look at, are you clearing the unused space on the drive before doing the transfer. I have a program that I use with my G4L project (at least the last four releases) and udpcast. ftp://fedoragcc.dyndns.org/blank6.exe Is a little C program (source code at the same site with .cpp), and it works for FAT and NTFS partitions. I just copy the file to the machine, and from the command prompt you blank6 c (c being the drive to clear). It just creates 2GB files full of nulls until the disk is full, and deletes them when done. This will speed up the compress and greatly reduce the time to transmitt the data. When I image my lab machines, I can get about 20+ MB/sec considering the uncompressed size of the 80GB drives.
I used Erasor. But I'm using g4l for all the setup. It's a great utility BTW.
Don't know if that help, or just confused things more. Just yesterday, I imaged the other 19 machines in my lab with 80GB drive in about 50 minutes with a hub.
One other thing that you might want to look at is the --max-bitrate= option. I've found that if I set it to 90M it reduces these timeouts for the 18 machines, and 80M will sometimes have none. With the problem machine, it usually takes 60M or lower to stop the errors.
I'll give this a try when I have more of them hooked up. I'm still waiting for Dell to deliver 12 machines.
Thanks for the help. (I'll be back at work trying this out soon. :-)
Ben
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Two quick additions. You want to check the duplex status. I think if you are using a switch, it should be set to full, and I think the default is half.
Second, I looked at Erasor, and it seems to be a security erasor, and did see from the page I looked at what pattern is left when it finishes. blank6 makes the space all null. If the pattern is a single byte, it should probable compress about the same, but it wirtes random patterns on the last run, it could make things worst.
On 26 Feb 2006 at 20:48, Benjamin Moore wrote:
Date sent: Sun, 26 Feb 2006 20:48:43 -0800 From: Benjamin Moore bmoore@tacticallanguage.com To: udpcast@udpcast.linux.lu Subject: Re: [Udpcast] Lots of Timeouts using udpcast
Michael D. Setzer II wrote:
Some questions about the setup. Is it one or two machines that is giving the timeouts? I have a lab of 20 machines, one was causing this problem. If I imaged all the others together there would be very few timeouts compared to thiis one. Turned out to be the hard drive in that machine, which was the same brand as all the others. In swapping the hard drive to another machine the problem moved from the one machien to the other. Ran diagnostics on the drive,and it reports no errors, but it doesn't seem to be able to keep up with writing the sections of the drive that are blank, so the compressed informaiton is coming in faster than the machine can write it to the disk. I've seen that these drives can only do about 45MB after the buffer gets full.
2 Machines if I'm reading the error message correctly... I don't quite understand what the error is trying to tell me. I'll try imaging them individually and see if the problem goes away. You're theory about the drive writing sounds plausible. I'll experiment, since I'm going to be doing this off and on for the next 6-12 months.
Also, what IP addresses are you using on the systems. I had a problem, whereas the College MIS has 3 Class C blocks all the the same physical network with a standard Class C subnet mask (Don't ask why??), and if I used dhcp it would only work with machines on the same class C. I ended up making an ipmac.txt file for the udpcast, and had it assign 10.0.7.x numbers to my machines (Lab D-7).
192.168.15.* But I'm doing my imaging completely off the external network. All that's on the network is the server and the machines that I'm imaging and they're all plugged into our HP 24 port switch.
Also, you could try a cross-over cable and directly connect two machines, and see if it differs from going thru the switch..
I'll give this a try as well, if I have time. If it is one of the machines... yuck... but if I'm interpretting the error correctly it is having a problem with both of them isn't it?
Another issue that you might want to look at, are you clearing the unused space on the drive before doing the transfer. I have a program that I use with my G4L project (at least the last four releases) and udpcast. ftp://fedoragcc.dyndns.org/blank6.exe Is a little C program (source code at the same site with .cpp), and it works for FAT and NTFS partitions. I just copy the file to the machine, and from the command prompt you blank6 c (c being the drive to clear). It just creates 2GB files full of nulls until the disk is full, and deletes them when done. This will speed up the compress and greatly reduce the time to transmitt the data. When I image my lab machines, I can get about 20+ MB/sec considering the uncompressed size of the 80GB drives.
I used Erasor. But I'm using g4l for all the setup. It's a great utility BTW.
Don't know if that help, or just confused things more. Just yesterday, I imaged the other 19 machines in my lab with 80GB drive in about 50 minutes with a hub.
One other thing that you might want to look at is the --max-bitrate= option. I've found that if I set it to 90M it reduces these timeouts for the 18 machines, and 80M will sometimes have none. With the problem machine, it usually takes 60M or lower to stop the errors.
I'll give this a try when I have more of them hooked up. I'm still waiting for Dell to deliver 12 machines.
Thanks for the help. (I'll be back at work trying this out soon. :-)
Ben
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)
BOINC Seti@Home Total Credits 473413.537949