Can anyone give me advice on what will acheive the fastest boot time? My options are the LinuxBIOS coupled with a DOC root or with root configured on hda1 (IDE). I boot into X and I'll need standard modules loaded. I'd like to fit the entire install on a DOC but only IF I'll get a faster load/boot. Would a combination be faster or just DOC ? Much thanks in advance to anyone that can provide advice... -Chris Bergeron
On Sun, 29 Sep 2002, Christopher Bergeron wrote:
Can anyone give me advice on what will acheive the fastest boot time? My options are the LinuxBIOS coupled with a DOC root or with root configured on hda1 (IDE). I boot into X and I'll need standard modules loaded. I'd like to fit the entire install on a DOC but only IF I'll get a faster load/boot.
you can't fit X onto the DoC you can buy today. Fasted boot I've seen is with the kernel in DoC, then mount /dev/hda1 as /. ron
Sunday, September 29, 2002, 5:26:37 PM, you wrote: RGM> On Sun, 29 Sep 2002, Christopher Bergeron wrote:
Can anyone give me advice on what will acheive the fastest boot time? My options are the LinuxBIOS coupled with a DOC root or with root configured on hda1 (IDE). I boot into X and I'll need standard modules loaded. I'd like to fit the entire install on a DOC but only IF I'll get a faster load/boot.
RGM> Fasted boot I've seen is with the kernel in DoC, then mount /dev/hda1 as RGM> /. So DoC _IS_ faster than IDE? If this is the case, why should it be that mounting it with /dev/hda1 as root would make for a faster boot? By my logic, I would think that having /boot and /root on a DoC would make it faster. Am I missing something? Thanks, Chris
On Sun, 29 Sep 2002, Christopher Bergeron wrote:
So DoC _IS_ faster than IDE? If this is the case, why should it be that mounting it with /dev/hda1 as root would make for a faster boot? By my logic, I would think that having /boot and /root on a DoC would make it faster.
It is not faster. But it is faster to load a kernel from linux while the slow IDE spins up. Then once the kernel is in there it can go to IDE. ron
On Sun, 29 Sep 2002, Ronald G Minnich wrote:
It is not faster. But it is faster to load a kernel from linux while the ^^^^^ DoC slow IDE spins up. Then once the kernel is in there it can go to IDE.
ron
So DoC _IS_ faster than IDE? If this is the case, why should it be that mounting it with /dev/hda1 as root would make for a faster boot? By my logic, I would think that having /boot and /root on a DoC would make it faster.
DoC _IS_NOT_ faster than IDE. IDE HD has the problem it need to spin up before taking any command while DoC does not. This spin up time delays you booting speed. On the other hand, once spun up IDE HD is much faster than DoC.
Ollie
I've been loading the Linux kernel from CompactFlash (CF) (raw image) in /dev/hdc1, and then mount the root disk in /dev/hda1, and this is pretty fast. I shortened the delays in the IDE routine since the CF doesn't need spin up time. We really need an "intelligent" routine to find when an IDE device is ready rather than a pure time delay. -Steve
Hello from Gregg C Levine Steve? How so? How did you physically connect the CF card to your IDE bus? I know a number of adapters exist to enable that feature, and I know that the 2.4 series contains the MTD (Memory Technology Drivers) functions directly, but after that, I'm lost. Gregg C Levine drwho8@worldnet.att.net "Oh my!" The Second Doctor's nearly favorite phrase. ----- Original Message ----- From: "Steve M. Gehlbach" <steve@nexpath.com> To: <linuxbios@clustermatic.org> Sent: Monday, September 30, 2002 1:09 AM Subject: RE: Re[2]: DOC vs. IDE
So DoC _IS_ faster than IDE? If this is the case, why should it be that mounting it with /dev/hda1 as root would make for a faster boot? By my logic, I would think that having /boot and /root on a DoC would make it faster.
DoC _IS_NOT_ faster than IDE. IDE HD has the problem it need to spin up before taking any command while DoC does not. This spin up time delays you booting speed. On the other hand, once spun up IDE HD is much faster than DoC.
Ollie
I've been loading the Linux kernel from CompactFlash (CF) (raw image) in /dev/hdc1, and then mount the root disk in /dev/hda1, and this is pretty fast. I shortened the delays in the IDE routine since the CF doesn't need spin up time. We really need an "intelligent" routine to find when an IDE device is ready rather than a pure time delay.
-Steve
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
Hello from Gregg C Levine Steve? How so? How did you physically connect the CF card to your IDE bus? I know a number of adapters exist to enable that feature, and I know that the 2.4 series contains the MTD (Memory Technology Drivers) functions directly, but after that, I'm lost.
CF is electrically IDE compatible, but not physically. It requires an adaptor, but the adaptor is completely passive except for the power connector. I bought mine from from this site a while ago: http://www.pcengines.com/cflash.htm. Otherwise, you use CF just like a regular HDD, no special drivers required. CF is less than 1/2 the price of DOC, so I have never really understood why DOC became popular. -Steve
On Mon, 2002-09-30 at 13:50, Steve M. Gehlbach wrote:
Hello from Gregg C Levine Steve? How so? How did you physically connect the CF card to your IDE bus? I know a number of adapters exist to enable that feature, and I know that the 2.4 series contains the MTD (Memory Technology Drivers) functions directly, but after that, I'm lost.
CF is electrically IDE compatible, but not physically. It requires an adaptor, but the adaptor is completely passive except for the power connector. I bought mine from from this site a while ago: http://www.pcengines.com/cflash.htm. Otherwise, you use CF just like a regular HDD, no special drivers required.
CF is less than 1/2 the price of DOC, so I have never really understood why DOC became popular.
Most wear-leveling algorithm in CF or DOM are rather stupid (if they do have) which result in unreliable parts. The algorithm in DOC's NFTL is a little bit better. Ollie
On Sun, 29 Sep 2002, Steve M. Gehlbach wrote:
CF is less than 1/2 the price of DOC, so I have never really understood why DOC became popular.
because the doc chip was a transparent replacement for the BIOS chip. That's the only reason. OUr 1024-node cluster uses CF in the primary IDE slot. ron
There are rumors that CF aren't reliable as DOC, is that true ? ----- Original Message ----- From: "Ronald G Minnich" <rminnich@lanl.gov> To: "Steve M. Gehlbach" <steve@nexpath.com> Cc: <linuxbios@clustermatic.org> Sent: Tuesday, October 01, 2002 3:47 AM Subject: RE: Re[2]: DOC vs. IDE
On Sun, 29 Sep 2002, Steve M. Gehlbach wrote:
CF is less than 1/2 the price of DOC, so I have never really understood why DOC became popular.
because the doc chip was a transparent replacement for the BIOS chip. That's the only reason.
OUr 1024-node cluster uses CF in the primary IDE slot.
ron
_______________________________________________ Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
"Steve M. Gehlbach" <steve@nexpath.com> writes:
So DoC _IS_ faster than IDE? If this is the case, why should it be that mounting it with /dev/hda1 as root would make for a faster boot? By my logic, I would think that having /boot and /root on a DoC would make it faster.
DoC _IS_NOT_ faster than IDE. IDE HD has the problem it need to spin up before taking any command while DoC does not. This spin up time delays you booting speed. On the other hand, once spun up IDE HD is much faster than DoC.
Ollie
I've been loading the Linux kernel from CompactFlash (CF) (raw image) in /dev/hdc1, and then mount the root disk in /dev/hda1, and this is pretty fast. I shortened the delays in the IDE routine since the CF doesn't need spin up time. We really need an "intelligent" routine to find when an IDE device is ready rather than a pure time delay.
Check the current code in the etherboot source tree. We wait for the BSY bit to clear before sending commands and it works fine. Ollie has reported that on some host controllers this doesn't work but I haven't seen that behavior in practice. Anyway feel free to send patches... Eric
Is the linuxbios code GPL? Does the GPL allow for inclusion into other operating systems? The reason I'm asking is because I'm very concerned that some other OS maker (ahem: MSFT) may take this codebase and try to create a MSFT version. Is this possible or am I worrying needlessly? I kow MSFT steals code (BSD tcp/ip stack comes to mind) and I'm wondering what provisions are out there to protect this amazing project. And while I'm at it, kudos to all the developers! -Chris
On Monday 30 September 2002 1:08 pm, Christopher Bergeron wrote:
Is the linuxbios code GPL?
Yes. It says so in the file COPYING distributed with the source code. Also see http://sourceforge.net/projects/freebios
Does the GPL allow for inclusion into other operating systems?
Yes, but only under the condition that any code which results is also freely released under the GPL. The GPL is quite clear about this really: 1. Commercial organisations *can* take Open Source Software, build it into products, and sell them for money. 2. Anyone who makes changes to GPL code and distributes the result (ie it's not for purely private use) *must* make the modified source available under the terms of the GPL (ie anyone else can take it and do what they want with it...) 3. It is allowed to take GPL code, build separate proprietary software which is *not* based upon the code, and is *not* derived from it, and distribute the two together without making the proprietary source available. However in this case you have to be very careful that the two really are separate, and that it cannot be said that the proprietary part is based on the GPL part. 4. There is a modified version of the GPL for library files to allow people to create proprietary Closed Source code which links to Open Source libraries, however the specific libraries must be realeased upon this version (called the LGPL) for this to apply. However, all that said, I'm not aware of any instance where the GPL has been tested in court (or even "out of court" as they say) against a company accused of taking GPL code and developing closed source products from it. If M$ is not bothered about defying the US Government, it's hard to think of anyone they are bothered about..... Antony. -- 90% of network problems are routing problems. 9 of the remaining 10% are routing problems in the other direction. The remaining 1% might be something else, but check the routing anyway.
However, all that said, I'm not aware of any instance where the GPL has been tested in court (or even "out of court" as they say) against a company accused of taking GPL code and developing closed source products from it.
Read "Enforcing The GPL" I and II at <http://emoglen.law.columbia.edu/>. Apparently the GPL has been tested out of court several times, and Moglen claims it has never been tested *in* court precisely because it is so watertight. GPL has the nicely recursive feature of being considerably less restrictive that the normal license agreements from which the rest of the software industry makes its money, so if anyone managed to get GPL challenged, all such licenses would be suspect. As the only group likely to be so motivated is precisely that same software industry, this won't be happening any time soon. :)
On Mon, Sep 30, 2002 at 01:40:19PM +0100, Antony Stone wrote:
On Monday 30 September 2002 1:08 pm, Christopher Bergeron wrote:
Is the linuxbios code GPL?
Yes. It says so in the file COPYING distributed with the source code. [..snip..]
However, all that said, I'm not aware of any instance where the GPL has been tested in court (or even "out of court" as they say) against a company accused of taking GPL code and developing closed source products from it.
Try XVID vs Sigma Designs, http://xvid.org/ and http://www.sigmadesigns.com/ //Peter
However, all that said, I'm not aware of any instance where the GPL has been tested in court (or even "out of court" as they say) against a company accused of taking GPL code and developing closed source products from it.
Read "Enforcing The GPL" I and II at <http://emoglen.law.columbia.edu/>. Apparently the GPL has been tested out of court several times, and Moglen claims it has never been tested *in* court precisely because it is so watertight. GPL has the nicely recursive feature of being considerably less restrictive that the normal license agreements from which the rest of the software industry makes its money, so if anyone managed to get GPL challenged, all such licenses would be suspect. As the only group likely to be so motivated is precisely that same software industry, this won't be happening any time soon. :)
linuxbios is gpl. The reason is that the original code base (freebios) is GPL; DOE encourages GPL projects; and the chipset vendors really wanted it to be GPL. I don't really care if MSFT uses it or not. ron
On Mon, 2002-09-30 at 07:00, Christopher Bergeron wrote:
Sunday, September 29, 2002, 5:26:37 PM, you wrote:
RGM> On Sun, 29 Sep 2002, Christopher Bergeron wrote:
Can anyone give me advice on what will acheive the fastest boot time? My options are the LinuxBIOS coupled with a DOC root or with root configured on hda1 (IDE). I boot into X and I'll need standard modules loaded. I'd like to fit the entire install on a DOC but only IF I'll get a faster load/boot.
RGM> Fasted boot I've seen is with the kernel in DoC, then mount /dev/hda1 as RGM> /.
So DoC _IS_ faster than IDE? If this is the case, why should it be that mounting it with /dev/hda1 as root would make for a faster boot? By my logic, I would think that having /boot and /root on a DoC would make it faster.
DoC _IS_NOT_ faster than IDE. IDE HD has the problem it need to spin up before taking any command while DoC does not. This spin up time delays you booting speed. On the other hand, once spun up IDE HD is much faster than DoC. Ollie
you can't fit X onto the DoC you can buy today. Fasted boot I've seen is with the kernel in DoC, then mount /dev/hda1 as /. ron Even an X like Qt embedded? My Zaurus only has 32Mb on it, and it boots into X in about 4 seconds. While I don't expect _that_ speedy of a boot, I would think I could achieve significantly less than 35(ish) seconds it takes now. Also, did you factor in the IDE spinup boot delay of having an IDE /. directory? If the DOC+IDE is faster, do you mean throughput wise or time wise? I'm referring to an earlier message that you replied to Todd Johnson and his boot times (message below). It seemed as if the 2 emails conflict in what they're saying, so I just wanted to ask for a little clarification (not doubting you, just a little unclear on the principle). Essentially what I'm wondering is if a small footprint X could be booted into via DOC and if it would be faster than DOC+IDE (considering the IDE spinup delay). Your thoughts? Ronald G Minnich wrote:
On Sun, 29 Sep 2002, Christopher Bergeron wrote:
Can anyone give me advice on what will acheive the fastest boot time? My options are the LinuxBIOS coupled with a DOC root or with root configured on hda1 (IDE). I boot into X and I'll need standard modules loaded. I'd like to fit the entire install on a DOC but only IF I'll get a faster load/boot.
you can't fit X onto the DoC you can buy today.
Fasted boot I've seen is with the kernel in DoC, then mount /dev/hda1 as /.
ron
On Fri, 4 Oct 2002, Todd E. Johnson wrote:
BTW, it seems that there is no booting action (Based on the Serial
output) until the HDD spins up. Is this a result of me keeping my root file system on the HDD?
you can't do anything until the HDD spins up, and yes it's because you've god file system on the HDD. There's not much to be done for this. ron
participants (11)
-
Antony Stone -
Christopher Bergeron -
CMZ -
ebiederman＠lnxi.com -
Gregg C Levine -
ollie lho -
Peter Lister -
Peter Stuge -
prl-linuxbios＠sychron.com -
Ronald G Minnich -
Steve M. Gehlbach