moving to sisuite-devel... On Thu, Jan 09, 2003 at 12:15:32PM -0800, Skouson, Gary B wrote: > > > On Thu, Jan 09, 2003 at 08:56:05AM -0800, Skouson, Gary B wrote: > > > I used a package called udpcast with a few modifications. > > > > have you looked at netcast? it's available on freshmeat. > > i didn't look very closely at udpcast, but we started looking towards > > netcast because the maintainer was interested in working with us, > > and it *just worked*. > > > > if all other thing are equal, maybe we can do some quick reliability/ > > speed tests of the tools themselves. > > I hadn't looked at netcast. It looks similar to udpcast. In addition to > doing synchronous and async transfers. It allows for bandwidth limiting the > server to avoid overruns. It also allows transmitting of redundant data > similar to RAID, which helps with limiting the retransmits, but there seems > to be a lot of overhead if it's turned up too high. > > I've done only a limited amount of testing and I've been able to transfer at > 500Mbps, but I tuned it down to 200Mbps to avoid some retransmits. Even at > that, it only takes 30sec to transfer the image. > > > > > > I made a couple of modifications to the SI initrd image. I > > changed the > > > busybox config to include cut. I wanted to use that so > > that I could deal > > > with two NIC's. I didn't include the tar and gzip/gunzip > > stuff but copied > > > in the real tar and gzip/gunzip because the busybox tar > > didn't like long > > > names. > > > > makes sense. the transport tool will most definitely need to > > be in the > > ramdisk - but could we just put tar/gzip in the boel_binaries tarball? > > we have no real space limitation there. > > also - did the installs appear to be bottlenecked by net or gunzip? > > > I should have thought of that. That would have been quicker than rebuilding > the initrd every time I ran into problems. > > > > I modified the rcS script to do the multicast receive to > > transfer the needed > > > files to the tmpfs (on our systems this is plenty large for > > the data we need > > > for install.) > > > > including the image tarball? > Yup, including the image tarball. > > > i think what we'd discussed before is keeping the flat-file > > style image, > > and tarring/untarring on the fly. since we're doing a 1:many > > transfer, > > the overhead here should be negligible, and still allow the ability > > to use rsync via updateclient. > > > > I couldn't tar and transmit the file at the same speed. I ended with more > than 3x data to transfer and it'd take up more memory space in the ramdisk > if I was limited there. It's probably not a big deal though (only another > minute to the install). I left the flat-file tree there, I just did a > tar.gz of the flat-file tree prior to doing the multicast install, so the > rsync would still work. All of the normal SI stuff should still work. > > > > >From there I changed the rest of the rsync commands both > > in rcS and in the > > > node.sh script to grab files from the /downloads directory > > rather than from > > > the imageserver. > > > > k. > > > > > To make things easy to transfer I made a tar.gz file of the > > > /images/imagename directory and transferred that in the multicast. > > > > > > It isn't too closely integrated into SystemImager at the > > moment, I didn't > > > make any changes to the perl libraries used by the normal > > commands. If you > > > want, I'm happy to send you my scripts, they probably need > > some cleaning up > > > though. > > > > yes - that'd be great. > > you mind if we move this thread to systemimager-devel? > > Sure. Where's systemimager-devel? > > ----- > Gary Skouson >
-- [EMAIL PROTECTED] ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Sisuite-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/sisuite-devel
