[Udpcast] Lots of Timeouts using udpcast

Benjamin Moore bmoore at tacticallanguage.com
Mon Feb 27 06:36:06 CET 2006

Quoting "Michael D. Setzer II" <mikes at kuentos.guam.net>:

> 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.

I thought it defaulted to full... I'll poke around.  It looks like there's a
problem with my images. :-(  I'm getting the dreaded BSOD when I 
restart saying
there's a problem with the hard drive...  grrr.

> 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.

It's actually configurable.  I had it write all zeros instead of random data.

Thanks for the help,


> 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.
>> >>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 at udpcast.linux.lu
>> https://lll.lgl.lu/mailman/listinfo/udpcast
> +----------------------------------------------------------+
>  Michael D. Setzer II -  Computer Science Instructor
>  Guam Community College  Computer Center
>  mailto:mikes at kuentos.guam.net
>  mailto:msetzerii at 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 at Home Total Credits 473413.537949
> Version: PGP 6.5.8 -- QDPGP 2.61c
> Comment: http://community.wow.net/grt/qdpgp.html
> 0KnMee3jZAPpFNVSW5z9v1D5
> =31VA

More information about the Udpcast mailing list