[Udpcast] Lots of Timeouts using udpcast
Michael D. Setzer II
mikes at kuentos.guam.net
Mon Feb 27 06:24:34 CET 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
On 26 Feb 2006 at 20:48, Benjamin Moore wrote:
Date sent: Sun, 26 Feb 2006 20:48:43 -0800
From: Benjamin Moore <bmoore at tacticallanguage.com>
To: udpcast at 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.
> >>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. :-)
> Udpcast mailing list
> Udpcast at udpcast.linux.lu
Michael D. Setzer II - Computer Science Instructor
Guam Community College Computer Center
mailto:mikes at kuentos.guam.net
mailto:msetzerii at gmail.com
Guam - Where America's Day Begins
Number of Seti Units Returned: 19,471
Processing time: 32 years, 290 days, 12 hours, 58 minutes
(Total Hours: 287,489)
BOINC Seti at Home Total Credits 473413.537949
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8 -- QDPGP 2.61c
-----END PGP SIGNATURE-----
More information about the Udpcast