[Udpcast] Lots of Timeouts using udpcast

[Michael D. Setzer II]

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


-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8 -- QDPGP 2.61c
Comment: http://community.wow.net/grt/qdpgp.html

iQA/AwUBRAIAcyzGQcr/2AKZEQLP4gCg5DqgHN9zaECmWEDH/BBeHNr2rtgAoKXN
9kc3M9xNmnM/cJzzU1U1yTaH
=7Dib
-----END PGP SIGNATURE-----