Subject: Re: Status of SCSI SYS_INST?
To: Jason Thorpe <thorpej@nas.nasa.gov>
From: Michael Joosten <joost@c-lab.de>
List: port-hp300
Date: 12/11/1996 04:19:29
Oops, I messed the Cc: header...
> On Wed, 11 Dec 1996 02:55:57 +0100 (MET) 
>  Michael Joosten <joost@c-lab.de> wrote:
> 
>  > OK, I tested it in the last hours with a 400t (68030, L-board), a Maxtor
>  > LXT-200s, Emulex MD21 + 180 MB ESDI, uScience ?? 660MB, Seagate
>  > Barracuda 32550 and an MO drive. A nice mixture of 8 years disk
>  > technology.... Besides the problems I first had (broken SCSI cable,
>  > argh), every thing seems to work fine with SLOWSCSI. But - I'm wondering
>  > if it will be even slower during dumping miniroot (NFS with 512 blocks,
>  > yuck !). BTW, if there is a rbootd on the net, my configuration
>  > immediately loads the net SYS_?? instead the one from the disk. Feature
>  > or bug (er, misconfig )?? 
> 
> It will no doubt make it a little slower, but probably not by much...
> 

Well, I'm not sure what DELAY(x) means, for the kernel this seems to be
microseconds, but the standalone stuff is different. BTW again,
#define DELAY(n)        { register int N = cpuspeed * (n); while (--N > 0); }

what happens if gcc gets this with optimizer on ???

> BTW, if you want to improve the performance of that code, by all means,
> feel free :-)  I wanted to get it working... I'll leave optimization as
> an excercise for the reader^W^Wpeople with more time than I have. :-)
>
Same for me... I'd guess DELAY(1000) means something like a few milliseconds
after each complete SCSI command, so it's not that slower - the tiny NFS
packets are the worst offender...

> 
> Regarding network booting over disk booting... that's how the HP ROMs are
> written... there's not anything I can do about that... you'll just
> have to configure rbootd to not answer requests for that host.
> 
OK, it's not like a Sun where you can set your boot path in an NVRAM. BTW,
anything herad about the Utility Chip 8-))) Not that I now have much (hah, if
any) time for it now...

Thanks, Michael