From tomc at bio.umass.edu Thu Apr 3 21:15:40 2008 From: tomc at bio.umass.edu (Tom Carpenter) Date: Thu, 03 Apr 2008 15:15:40 -0400 Subject: [Udpcast] Include ntfsresize into initrd In-Reply-To: <479EE2F8.9070907@knaff.lu> References: <479DCC76.771F.00ED.0@sdb.k12.wi.us> <479EE2F8.9070907@knaff.lu> Message-ID: <47F52CDC.7010705@bio.umass.edu> Didn't see any error message details from Jeff or any indication that he found a solution, so, I'm just guessing my info is relevant. I do the same thing as Jeff with ntfsclone (compiled ntfsprogs v2.0.0 with '--enable-really-static' and use cast-o-matic to include ntfsclone, ld-linux.so.2, and libc.so.6). Basically, there's no "/etc/mtab" included/ created in the cast-o-matic PXE image, causing ntfsclone complain when try to save image file: # ntfsclone --save-image --overwrite /test.img /dev/sda ERROR(2): Failed to check '/dev/sda' mount state: No such file or directory I just included "touch /etc/mtab" in the "Commands to be executed before udpcast menu:" and then ntfsclone works. Tom Alain Knaff wrote: > Jeff Michels wrote: >> Hello, >> >> I would like to include ntfsresize into an initrd >> created by cast-o-matic. I compiled ntfsresize >> statically and uploaded the application to be included >> in the initrd. I'm pretty sure this is a busybox issue. >> ntfsresize appears in the initrd but I cannot execute it. > > Do you get any error message? Or what exactly happens if >> you try to execute it? > >> I am not very familiar with busybox so any help would be >> appreciated. Thank you in advance. >> >> >> Jeff Michels >> Technology Support Specialist >> The School District of Beloit > > Btw, please watch your line length. Usually, in e-mails people keep > their lines shorter than 80 characters (except if there is a good > reason, such as quoting code, log file entries, etc.), this makes it > easier for everybody to read it without scrolling. > > Thanks, > > Alain > _______________________________________________ > Udpcast mailing list > Udpcast at udpcast.linux.lu > https://lll.lgl.lu/mailman/listinfo/udpcast > From tomc at bio.umass.edu Mon Apr 7 20:13:17 2008 From: tomc at bio.umass.edu (Tom Carpenter) Date: Mon, 07 Apr 2008 18:13:17 -0000 Subject: [Udpcast] udpcast receiver options Message-ID: <47FA6419.1000101@bio.umass.edu> If I access a virtual console on the cast-o-matic PXE images I've generated, --rcvbuf is listed as a commandline option for udp-sender. The manpage for udp-sender suggests setting, "Try playing with the settings in /proc/sys/net/core/rmem_default and /proc/sys/net/core/rmem_max, i.e. setting them to a higher value" Does udp-receiver's "--rcvbuf" option modify rmem_default and/or rmem_max or some other value? -Tom C. From alain at knaff.lu Thu Apr 10 01:11:20 2008 From: alain at knaff.lu (Alain Knaff) Date: Wed, 09 Apr 2008 23:11:20 -0000 Subject: [Udpcast] udpcast receiver options In-Reply-To: <47FA6419.1000101@bio.umass.edu> References: <47FA6419.1000101@bio.umass.edu> Message-ID: <47FD4CDC.5060300@knaff.lu> Tom Carpenter wrote: > If I access a virtual console on the cast-o-matic PXE images > I've generated, --rcvbuf is listed as a commandline option > for udp-sender. The manpage for udp-sender suggests setting, > > "Try playing with the settings in /proc/sys/net/core/rmem_default > and /proc/sys/net/core/rmem_max, i.e. setting them to a higher > value" > > Does udp-receiver's "--rcvbuf" option modify rmem_default and/or > rmem_max or some other value? > > -Tom C. No, the --rcvbuf options only sets the buffer for that particular socket. rmem_max must be set separately (which is already done by the udpc_dialog program, i.e. the menu system) Regards, Alain From matthias.ehmann at uni-bayreuth.de Sat Apr 19 15:10:16 2008 From: matthias.ehmann at uni-bayreuth.de (Matthias Ehmann) Date: Sat, 19 Apr 2008 13:10:16 -0000 Subject: [Udpcast] Kernel 2.6.24 Message-ID: <4809EE86.60707@uni-bayreuth.de> I need support for intel e1000e network adapters finally introduced with kernel 2.6.24. So I compiled a 2.6.24.4 kernel for udpcast. I created a initrd for PXE boot. Kernel and initrd are loaded and the computers start to boot but they always hang after a while throwing the message init: can't open "/dev/null": no such file or directory The problem also occurs on my VMware testing machine. I used the 2.6.23.12 kernel configuration from the udpcast homepage with the suggested changes for the new parts of the kernel. My current workarround is a back-port of e1000e support from 2.6.24.4 to 2.6.23.12. But I would prefer to use kernel 2.4.24 Is there anybody out there with a running 2.6.24 based udpcast? Best regards Matthias From matthias.ehmann at uni-bayreuth.de Sat Apr 19 17:38:02 2008 From: matthias.ehmann at uni-bayreuth.de (Matthias Ehmann) Date: Sat, 19 Apr 2008 15:38:02 -0000 Subject: [Udpcast] Kernel 2.6.24 In-Reply-To: <480A85AE.9573.63583F9@mikes.kuentos.guam.net> References: <4809EE86.60707@uni-bayreuth.de> <480A85AE.9573.63583F9@mikes.kuentos.guam.net> Message-ID: <480A1127.8090908@uni-bayreuth.de> Michael D. Setzer II schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Just a quick question. When you did the build, were you logged in as root? > Many of the special files only work with root. I've had some people make the > mistake of building with an id other than root. > Thanks for your reply. No this is not the problem. This was not the first kernel I built. ;-) Kernel 2.6.23 works successful under the same preconditions. But as already mentioned I had to back port the e1000e driver. I will have a look at the ISO you mentioned. Could you send the .config file for the 2.6.25 kernel? > > I've built many kernels on my g4l cd image, and include udp-sender and > udp-reciever on the cd image, but have only setup the g4l to be use the > reciever. You could see it those kernels would work. I haven't setup a PXE > with g4l, but others have. > > Latest version with even the 2.6.25 kernel is available at: > ftp://amd64gcc.dyndns.org/g4l-v0.25alpha10.iso > > > From matthias.ehmann at uni-bayreuth.de Sat Apr 19 22:17:28 2008 From: matthias.ehmann at uni-bayreuth.de (Matthias Ehmann) Date: Sat, 19 Apr 2008 20:17:28 -0000 Subject: [Udpcast] Kernel 2.6.24 In-Reply-To: <480A1127.8090908@uni-bayreuth.de> References: <4809EE86.60707@uni-bayreuth.de> <480A85AE.9573.63583F9@mikes.kuentos.guam.net> <480A1127.8090908@uni-bayreuth.de> Message-ID: <480A52AC.3060605@uni-bayreuth.de> Compiling 2.6.25 and buliding initrd works perfectly for PXE boot with udpcast. Matthias Ehmann schrieb: > Michael D. Setzer II schrieb: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Just a quick question. When you did the build, were you logged in as root? >> Many of the special files only work with root. I've had some people make the >> mistake of building with an id other than root. >> >> > Thanks for your reply. > > No this is not the problem. This was not the first kernel I built. ;-) > Kernel 2.6.23 works successful under the same preconditions. But as > already mentioned I had to back port the e1000e driver. > > I will have a look at the ISO you mentioned. Could you send the .config > file for the 2.6.25 kernel? > > >> I've built many kernels on my g4l cd image, and include udp-sender and >> udp-reciever on the cd image, but have only setup the g4l to be use the >> reciever. You could see it those kernels would work. I haven't setup a PXE >> with g4l, but others have. >> >> Latest version with even the 2.6.25 kernel is available at: >> ftp://amd64gcc.dyndns.org/g4l-v0.25alpha10.iso >> >> >> >> > > _______________________________________________ > Udpcast mailing list > Udpcast at udpcast.linux.lu > https://lll.lgl.lu/mailman/listinfo/udpcast > > -- Dr. Matthias Ehmann Didaktik der Informatik Lehrstuhl für Mathematik und ihre Didaktik Universität Bayreuth 95440 Bayreuth Tel +49 921 55 7657 Fax + 49 921 55 7655 From dpopov at pharmanet.ru Mon Apr 21 14:04:53 2008 From: dpopov at pharmanet.ru (Dmitry Popov) Date: Mon, 21 Apr 2008 12:04:53 -0000 Subject: [Udpcast] Sender's timeout for waiting for receivers Message-ID: Hi everyone, Please confirm my guess (or explain how to implement it). I need a "sender-timeout", a period of time while sender waits for receivers to connect, and if none are connected - sender exits without transmission. The only way to implement this is shell/perl/... script, which starts udp-sender with --min-receivers option and monitors its stderr. If no "Starting transfer" is found during specified period of time - it kills udp-sender process. Regards, Dmitry From rjones at redhat.com Mon Apr 21 18:50:27 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Mon, 21 Apr 2008 16:50:27 -0000 Subject: [Udpcast] udpcast for Fedora Message-ID: <20080421164527.GB14504@amd.home.annexia.org> I just put in a Fedora Review Request for udpcast, which is the first step towards getting udpcast included as a standard package in Fedora. If udpcast users could review and test this package and post their experiences (good or bad) to this bug it would be helpful: https://bugzilla.redhat.com/show_bug.cgi?id=443449 Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From pitt.leidner at gmx.net Mon Apr 21 21:16:51 2008 From: pitt.leidner at gmx.net (Pitt Leidner) Date: Mon, 21 Apr 2008 19:16:51 -0000 Subject: [Udpcast] [solved] Problem with cloned MACs In-Reply-To: <200802131738.16901.pitt.leidner@gmx.net> References: <200802131738.16901.pitt.leidner@gmx.net> Message-ID: <200804212113.43094.pitt.leidner@gmx.net> Hi, Am Mittwoch, 13. Februar 2008 schrieb Pitt Leidner: > > Using the multicast to clone a HDD to several Clients, the clients take > the MAC of the onboard NIC (NVidia nForce). After that, the original > MAC is gone and I'm not able to restore this. > > This fact has been a little difficult to find. Cause I thought, the MAC > ist Part of the NIC, not of the HDD, which has been cloned. So how does > it come? > The answer in short: UDP-Cast wasn't resonsible for that! It has been an behavior of the the harddiskprotection "HDD Sheriff" witch protects the bios also. So a cloned target system will have a cloned Bios.Backup of the source also. This rewrites then the "changed" mac of the nic of the target after rebooting. I've received an MAC-writing tool from the Nic-producer- with that the strange error could be located quickly. I'm sorry for that. But still thankfull, becaus of your guidance, which gave me some ideas to the problem... ;-) -- yours sincerely Pitt From rjones at redhat.com Thu Apr 24 15:56:06 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 24 Apr 2008 13:56:06 -0000 Subject: [Udpcast] Scaling udpcast Message-ID: <20080424135339.GA12385@amd.home.annexia.org> I'm looking at using udpcast to broadcast large disk images (10+ GB) to a very large network of machines (1,000-10,000 receivers) over a mostly switched, partially segmented gig-ethernet network. Needless to say, the network of machines is all production-critical and I cannot get access to perform real testing. However testing it on my home network I can see some potential problems: - If _any_ receiver is misbehaving or unreachable then this stops all transmissions. Is there a way to get udpcast to drop troublesome receivers in this situation (other than unicast)? - Has anyone used the --ttl option to multicast over routers? Does it work (the manpage is unclear)? Does it need special routers? - Any other scaling tips? Should I try to go for the full set of machines at once or break up the broadcast into groups of machines? If anyone has used udpcast on such large networks, can you share any experiences. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top From meekohi at cs.virginia.edu Thu Apr 24 17:06:17 2008 From: meekohi at cs.virginia.edu (Michael Holroyd) Date: Thu, 24 Apr 2008 15:06:17 -0000 Subject: [Udpcast] Scaling udpcast In-Reply-To: <20080424135339.GA12385@amd.home.annexia.org> References: <20080424135339.GA12385@amd.home.annexia.org> Message-ID: <4810A1DB.4080702@cs.virginia.edu> Hi Rich, I tried to solve a problem much smaller than yours but still had incredible difficulty. I was moving 10GB datasets out to 64 receivers over a flat switched network using multicast. Unfortunately, for reasons I never tracked down, files of this size would always get corrupted along the way even though all the receivers had received all packets (i.e. the md5sum would be different across all the different machines). Eventually I ended up using small bittorrent clients instead of udpcast since it checks the hash of each block. This also makes the process take about twice as long, but better to get correct data slow than corrupt data fast! Hope you have better luck, -Michael Richard W.M. Jones wrote: > I'm looking at using udpcast to broadcast large disk images (10+ GB) > to a very large network of machines (1,000-10,000 receivers) over a > mostly switched, partially segmented gig-ethernet network. > > Needless to say, the network of machines is all production-critical > and I cannot get access to perform real testing. However testing it > on my home network I can see some potential problems: > > - If _any_ receiver is misbehaving or unreachable then this stops > all transmissions. Is there a way to get udpcast to drop > troublesome receivers in this situation (other than unicast)? > > - Has anyone used the --ttl option to multicast over routers? > Does it work (the manpage is unclear)? Does it need special > routers? > > - Any other scaling tips? Should I try to go for the full set of > machines at once or break up the broadcast into groups of machines? > > If anyone has used udpcast on such large networks, can you share any > experiences. > > Rich. > > From rjones at redhat.com Thu Apr 24 20:51:18 2008 From: rjones at redhat.com (Richard W.M. Jones) Date: Thu, 24 Apr 2008 18:51:18 -0000 Subject: [Udpcast] Scaling udpcast In-Reply-To: <4810A1DB.4080702@cs.virginia.edu> References: <20080424135339.GA12385@amd.home.annexia.org> <4810A1DB.4080702@cs.virginia.edu> Message-ID: <20080424184845.GA14491@amd.home.annexia.org> On Thu, Apr 24, 2008 at 11:06:03AM -0400, Michael Holroyd wrote: > I tried to solve a problem much smaller than yours but still had > incredible difficulty. I was moving 10GB datasets out to 64 receivers over > a flat switched network using multicast. Unfortunately, for reasons I never > tracked down, files of this size would always get corrupted along the way > even though all the receivers had received all packets (i.e. the md5sum > would be different across all the different machines). I haven't seen this problem (my tests are too small-scale probably) but I notice that the protocol doesn't do any sort of error detection for the dataBlocks. So we're relying on UDP's 16 bit checksum and maybe ethernet's CRC32. Both types of checksum are known to be very weak, and ethernet checksumming is even sometimes turned off. Shouldn't be too hard to add a more robust checksum to the packets. Is anyone interested in a patch? I might have a go at one later. Rich. PS. My cheap-ish consumer switch slows down from gigabit-ethernet to 10 Mbps as soon as I ask it to do multicast or broadcast. Is this normal? -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v From mikes at kuentos.guam.net Thu Apr 24 22:41:53 2008 From: mikes at kuentos.guam.net (Michael D. Setzer II) Date: Thu, 24 Apr 2008 20:41:53 -0000 Subject: [Udpcast] Scaling udpcast In-Reply-To: <4810A1DB.4080702@cs.virginia.edu> References: <20080424135339.GA12385@amd.home.annexia.org>, <4810A1DB.4080702@cs.virginia.edu> Message-ID: <48117D3F.6120.1608702@mikes.kuentos.guam.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24 Apr 2008 at 11:06, Michael Holroyd wrote: Date sent: Thu, 24 Apr 2008 11:06:03 -0400 From: Michael Holroyd To: "Richard W.M. Jones" Copies to: udpcast at udpcast.linux.lu Subject: Re: [Udpcast] Scaling udpcast > Hi Rich, > I tried to solve a problem much smaller than yours but still had > incredible difficulty. I was moving 10GB datasets out to 64 receivers > over a flat switched network using multicast. Unfortunately, for reasons > I never tracked down, files of this size would always get corrupted > along the way even though all the receivers had received all packets > (i.e. the md5sum would be different across all the different machines). > Eventually I ended up using small bittorrent clients instead of udpcast > since it checks the hash of each block. This also makes the process take > about twice as long, but better to get correct data slow than corrupt > data fast! > I had a similar problem recently on a much smaller scale. I was testing udpcast with a classroom to sent a just under 7GB ntfsclone image file to varios machines. I had one sender and 4 receivers and it worked fine twice. Then I tried with 8 receivers, and it failed. No error messages, and did it twice, with same error. Not sure what is the cause? I am planning on doing some more testing, and it might be a problem with SELINUX and ports. To get it to work, I had to open port 9000 and 9001 on the sender with udp, and port 9000 on the receiver with udp on the receiver. Perhaps receiver also needs 9001? The files on all the receivers seems to be that same size. Before this, I was using a script to down the file via ftp using ncftp. On the successful runs, it would udpcast the files to the linux partition, and then run the scipt to restore the new XP partition. The script woulld then show the file as being the same, and skip the download, and go straight to the retore. On the error batch, it started downloading the file via ftp, since they were not the same. I've used udpcast to image 19 machines from one sender with no errors usign udpcast images, and have noticed any errors, and have systems run the disk test on boot with no errors. So, don't know if it is a size problem, or ports, or kernel option, or option or something else? I'll try some more things, and try to see what is different between a good file and a bad one, and see if it was always the same. > Hope you have better luck, > -Michael > > Richard W.M. Jones wrote: > > I'm looking at using udpcast to broadcast large disk images (10+ GB) > > to a very large network of machines (1,000-10,000 receivers) over a > > mostly switched, partially segmented gig-ethernet network. > > > > Needless to say, the network of machines is all production-critical > > and I cannot get access to perform real testing. However testing it > > on my home network I can see some potential problems: > > > > - If _any_ receiver is misbehaving or unreachable then this stops > > all transmissions. Is there a way to get udpcast to drop > > troublesome receivers in this situation (other than unicast)? > > > > - Has anyone used the --ttl option to multicast over routers? > > Does it work (the manpage is unclear)? Does it need special > > routers? > > > > - Any other scaling tips? Should I try to go for the full set of > > machines at once or break up the broadcast into groups of machines? > > > > If anyone has used udpcast on such large networks, can you share any > > experiences. > > > > Rich. > > > > > > _______________________________________________ > 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 (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) BOINC at HOME CREDITS SETI 5,269,727.070797 | EINSTEIN 1,573,038.609732 | ROSETTA 480,077.992597 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 -- QDPGP 2.61c Comment: http://community.wow.net/grt/qdpgp.html iQA/AwUBSBBkASzGQcr/2AKZEQJoIACePSes1P2lrNvSDnuEaOFL2azBZ+YAoIR4 G3sccClKCiQw8ru/GZ4/lz15 =t3KH -----END PGP SIGNATURE----- From meekohi at cs.virginia.edu Thu Apr 24 23:15:22 2008 From: meekohi at cs.virginia.edu (Michael Holroyd) Date: Thu, 24 Apr 2008 21:15:22 -0000 Subject: [Udpcast] Scaling udpcast In-Reply-To: <20080424184845.GA14491@amd.home.annexia.org> References: <20080424135339.GA12385@amd.home.annexia.org> <4810A1DB.4080702@cs.virginia.edu> <20080424184845.GA14491@amd.home.annexia.org> Message-ID: <4810F83D.9050201@cs.virginia.edu> Hi Rich, I'd be very interested in a patch. I might have worked on one myself (I'd already edited the source to turn off the absurd stdout spam), but unfortunately my sender is a windows box and I wasn't in the mood to battle compiling udpcast for windows. The behavior I saw was that 50-55 of my recievers would have the same md5sum, but it was still the *wrong* md5sum. The outliers could very plausibly be due to checksums being unreliable, and perhaps there was some bit-flipping that occurred before the first router sent everything out on multicast. Let me know how it goes if you decide to try it out, -Michael Richard W.M. Jones wrote: > On Thu, Apr 24, 2008 at 11:06:03AM -0400, Michael Holroyd wrote: > >> I tried to solve a problem much smaller than yours but still had >> incredible difficulty. I was moving 10GB datasets out to 64 receivers over >> a flat switched network using multicast. Unfortunately, for reasons I never >> tracked down, files of this size would always get corrupted along the way >> even though all the receivers had received all packets (i.e. the md5sum >> would be different across all the different machines). >> > > I haven't seen this problem (my tests are too small-scale probably) > but I notice that the protocol doesn't do any sort of error detection > for the dataBlocks. So we're relying on UDP's 16 bit checksum and > maybe ethernet's CRC32. Both types of checksum are known to be very > weak, and ethernet checksumming is even sometimes turned off. > > Shouldn't be too hard to add a more robust checksum to the packets. > Is anyone interested in a patch? I might have a go at one later. > > Rich. > > PS. My cheap-ish consumer switch slows down from gigabit-ethernet to > 10 Mbps as soon as I ask it to do multicast or broadcast. Is this > normal? > > From mikes at kuentos.guam.net Thu Apr 24 23:24:10 2008 From: mikes at kuentos.guam.net (Michael D. Setzer II) Date: Thu, 24 Apr 2008 21:24:10 -0000 Subject: [Udpcast] Scaling udpcast In-Reply-To: <4810F83D.9050201@cs.virginia.edu> References: <20080424135339.GA12385@amd.home.annexia.org>, <20080424184845.GA14491@amd.home.annexia.org>, <4810F83D.9050201@cs.virginia.edu> Message-ID: <48118730.20383.1875B7C@mikes.kuentos.guam.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just a quick addition to my earlier message. I just did a retest of doing the imaging after opening both port 9000 and 9001 on both senders and receivers. Sent the image to 19 receivers, and this time, it went thru with no errors, and the files were the correct size? So, at least in this case, it would appear that port 9001 is playing a part in this. On 24 Apr 2008 at 17:14, Michael Holroyd wrote: Date sent: Thu, 24 Apr 2008 17:14:37 -0400 From: Michael Holroyd To: "Richard W.M. Jones" Copies to: udpcast at udpcast.linux.lu Subject: Re: [Udpcast] Scaling udpcast > Hi Rich, > I'd be very interested in a patch. I might have worked on one myself > (I'd already edited the source to turn off the absurd stdout spam), but > unfortunately my sender is a windows box and I wasn't in the mood to > battle compiling udpcast for windows. The behavior I saw was that 50-55 > of my recievers would have the same md5sum, but it was still the *wrong* > md5sum. The outliers could very plausibly be due to checksums being > unreliable, and perhaps there was some bit-flipping that occurred before > the first router sent everything out on multicast. > Let me know how it goes if you decide to try it out, > -Michael > > Richard W.M. Jones wrote: > > On Thu, Apr 24, 2008 at 11:06:03AM -0400, Michael Holroyd wrote: > > > >> I tried to solve a problem much smaller than yours but still had > >> incredible difficulty. I was moving 10GB datasets out to 64 receivers over > >> a flat switched network using multicast. Unfortunately, for reasons I never > >> tracked down, files of this size would always get corrupted along the way > >> even though all the receivers had received all packets (i.e. the md5sum > >> would be different across all the different machines). > >> > > > > I haven't seen this problem (my tests are too small-scale probably) > > but I notice that the protocol doesn't do any sort of error detection > > for the dataBlocks. So we're relying on UDP's 16 bit checksum and > > maybe ethernet's CRC32. Both types of checksum are known to be very > > weak, and ethernet checksumming is even sometimes turned off. > > > > Shouldn't be too hard to add a more robust checksum to the packets. > > Is anyone interested in a patch? I might have a go at one later. > > > > Rich. > > > > PS. My cheap-ish consumer switch slows down from gigabit-ethernet to > > 10 Mbps as soon as I ask it to do multicast or broadcast. Is this > > normal? > > > > > > _______________________________________________ > 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 (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) BOINC at HOME CREDITS SETI 5,269,727.070797 | EINSTEIN 1,573,038.609732 | ROSETTA 480,077.992597 -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 -- QDPGP 2.61c Comment: http://community.wow.net/grt/qdpgp.html iQA/AwUBSBBt8SzGQcr/2AKZEQIRUQCfYMFU8tBUgEu8EUr+/6YLQVUtlLkAnjVv J6wbq6W2BfJk8zQOobciCaEX =u158 -----END PGP SIGNATURE-----