On December 22, 2014, Levi Pearson wrote: [snip]
> Your kernel and > initial ram disk are typically downloaded this way, and it's going to > be *way* less efficient than reading from any drive. There probably wouldn't be a ramdisk, although I hadn't played with it enough to make that call for sure. My initial plan was just to have a monolithic kernel that gets loaded (would probably be about 1.5 - 2 MB in size), then it would mount the root via NFS (i.e. root=/dev/nfs nfsroot=192.168.4.2:/storage/nfs/ws ro) and proceed. I imagine that as long as the kernel supports the NIC driver internally, that would work. I could possibly speed the process by changing the kernel to more modular, and only building the NIC and NFS drivers into the kernel itself, leaving everything else as a module file to be loaded via NFS. That will chop off a little space, although not a whole heck of a lot. As to it being a server class board, I don't think that's the case, unless a Gigabyte X99 based board (exact model # escapes me at the moment and I don't have it handy to look) would qualify as "server class". And I am sure that Z97 based and similar boards don't qualify as server class. :) > Booting directly via iSCSI (assuming your network card supports this) > is likely to make *far* more efficient use of the network than tftp > booting till, so it's likely to feel a lot less delayed than a typical > network boot will, and those aren't even terribly painful, especially > if you don't reboot a lot. I'd love to learn more about iSCSI, as I've heard of it before. But haven't been in a position to dedicate much time to researching it. Perhaps soon. This project is not scheduled to happen for a couple of months yet, so I've got a bit of time. I'll check out that blogspot article that was mentioned. Either way, booting wasn't my primary concern. The primary speed concern was in actual loading of applications (like LibreOffice or Firefox or Thunderbird). As it stands now, the NICs's being used are the onboard NICs on the motherboards. If there's a compelling reason to use a separate NIC then I'll look into it. For now though, the goal is simply to get the best performance that I can get on the hardware I have. :) Thanks for all the tips! --- Dan On Wed, Dec 24, 2014 at 4:04 AM, Dan Egli <[email protected]> wrote: > On December 22, 2014, Nicholas Leippe wrote: > > > If your motherboard supports it, you could go full openbios--which > > > flashes your kernel directly into the bios for very fast boot times. > > > > That's actually going in the opposite direction of the goal of the > project, which was to minimize the number of places things had to be > changed in the event of software updates. Openbios is nice, don't get me > wrong. But I'd have to flash each machine, and then when a new kernel comes > out, I'd have to re-flash each machine. Thanks but no thanks. > > > --- Dan > > On Tue, Dec 23, 2014 at 4:56 PM, Chris <[email protected]> wrote: > >> On Mon, Dec 22, 2014 at 3:43 PM, Levi Pearson <[email protected]> >> wrote: >> >> > The tftp protocol, which is the "standard" method of network booting >> > Linux, is >> > horrifically slow. >> >> >> Here's one datapoint. >> >> Over gigabit ethernet, I typically see tftp downloads that run at a bit >> over seven megabytes per second. >> >> Yes, it's a lot slower than local disk and a lot slower than the network >> itself, but I wouldn't call it "horrific" if one is downloading only a few >> tens of megabytes over tftp. Other parts of the system startup are likely >> to have a greater impact on boot time than smallish tftp downloads over >> gigE. (Subjectively, tftp over 100 megabit ethernet is a lot more painful, >> though I haven't measured the actual corresponding download speed.) >> >> As the man said, YMMV, etc. >> >> /* >> PLUG: http://plug.org, #utah on irc.freenode.net >> Unsubscribe: http://plug.org/mailman/options/plug >> Don't fear the penguin. >> */ >> > > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
