On Tue, 1 Aug 2000, J.A. Bezemer wrote:
> On Mon, 31 Jul 2000, Mattias Wadenstein wrote:
> > On 31 Jul 2000, Philip Hands wrote:
> > > Mattias Wadenstein <[EMAIL PROTECTED]> writes:
> > >
> > > > We would also be happy to run a mirror for the potato ISOs provided there
> > > > is a someone we could rsync towards, since we have much bandwidth and not
> > > > that much CPU power we could probably rsync them a couple of times over
> > > > before the pseudo-image-kit would finish doing its stuff. ;)
> > >
> > > Er, no -- the pseudo-image-kit doesn't take much CPU -- it's just
> > > sticking FTP/HTTP files together.
> >
> > The server has 2 40MHz supersparcs. I've tried the pseudo-image-kit on
> > another of our servers, with 2 60MHz supersparcs, and it took much more
> > time than downloading the isos would have taken.
>
> Sparcs have a known issue with the `wc' command, see
> http://cdimage.debian.org/~costar/pseudo-image-kit/
> (at the bottom).
ftp-deb@churchill:~> wc --version
wc (GNU textutils) 2.0
I hope it was a problem with the solaric wc and not the sol/sparc version
of GNU wc. It takes no noticable time to 'wc -c' an cd image, so I'm
guessing that is the case.
> Also, if (many) other processes are running, things may slow down quite much.
> This is because make-pseudo-image is a shell script which calls many external
> programs, and each call gives priority to other running programs (even if the
> called program would terminate immediately).
Well, the machine behaves pretty good during load, and it doesn't have
much else to do really. It usually has a processor or two idle waiting for
something to do. It is just a matter of the processors and disks being
slow.
The rsync part takes a bunch of CPU power, probably the time for
calculating a bunch of checksums. And that rsync takes aobut 10 minutes
too.
Loadgraph:
http://www.acc.umu.se/technical/statistics/loadavg/view.html.en?name=churchill
I started the multigrab at 14 CET, which should be noticable. :)
Time: 12460.08u 24367.33s 11:49:09.45 -14.-3%
It did take some time. Probably 3/5th make-pseudo-image and 2/5th rsync,
or something like that.
> > We do have more potential bandwidth to network than disk..
>
> Hmm, in that case setting up a simple FTP/HTTP/rsync redir to e.g.
> ftp.sunet.se would be faster than using your own disks for the mirroring,
> wouldn't it? ;-)
Well, a couple of megs per second is no problem. And if you spread the
accesses out to many different disks and different controllers, you can
get a pretty good disk bandwidth. :)
But the pseudo-imake-kit reads from just one disk at a time and writes to
one other disk.
Also, ftp.sunet.se doesn't have the potato isos, otherwise I would just
have rsync:ed them from there, just as we do with the official ones.
I also made some modifications to the multigrab script (so that you can
run "multigrab */*.list"), and some other modifications here and there
(I don't remember if all was changing the shell to bash instead of /bin/sh
which is really slow on solaris, or if I made more modifications :/ ).
Oh, well. The modified pseudo-image-kit is in the
mirror/potato_test-cycle-3/pseudo-image-kit-2.0 directory, the actual
images are in the mirror/potato_test-cycle-3 dir.
That is:
http://ftp.se.debian.org/mirror/potato_test-cycle-3/
ftp://ftp.se.debian.org/mirror/potato_test-cycle-3/
ftp.se.debian.org::potato_test-cycle-3
/Mattias Wadenstein - writing way too long emails and staying up too
long. :)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
