Small boot-time improvement

[Galen Henderson]

Hello all. Just wanted to pass on something I found that shaved a few
seconds off of my boot times. There is a utility that runs after DHCP
that is supposed to assign a 169, address if DHCP fails. This utility
has a timeout feature that waits for dhcp. It is found in the /mptn/bin
folder in the file mptstart.cmd. Just comment out the line that starts
llaecs.exe.

It's only a few seconds, but I guess in a modern world, every second
counts :)

[Doug Bissett]

On Mon, 22 Mar 2010 00:24:22 UTC, Galen Henderson

Post by Galen Henderson
Hello all. Just wanted to pass on something I found that shaved a few
seconds off of my boot times. There is a utility that runs after DHCP
that is supposed to assign a 169, address if DHCP fails. This utility
has a timeout feature that waits for dhcp. It is found in the /mptn/bin
folder in the file mptstart.cmd. Just comment out the line that starts
llaecs.exe.
It's only a few seconds, but I guess in a modern world, every second
counts :)

That program can also wait forever, under some circumstances. It is
supposed to be fixed for eCS 2.0 GA, but I haven't seen the fix.

I find that it appears to hang during boot, often at NETBIND.EXE, but
it isn't NETBIND.EXE that is doing it. It is LLAeCS.exe, which is
started in \MPTN\BIN\MPTSTART.CMD in eCS 2.0 Silver edition, or in
\MPTN\BIN\SETUP.CMD in earlier versions. The best way to handle that
(and cut down on the boot time) is to REM it in the CMD file, make an
icon for it, and put it into the STARTUP folder.

One problem is that if you ever run the Select Interfaces for Sharing
program (it is run automatically after you configure PEER networking,
and possibly at other times), it will unREM the command in the CMD
file for you (it will probably hang at the next boot if you have that
problem).

Why not just REM it? Well, if you use a mixed WiFi and wired NIC
combination, you will find that the "unused" interface will be left
with an address of 0.0.0.0 which will cause many delays if you try to
use PEER networking (and possibly other things). I have also been
told, that it does something useful in a single NIC system too (I
wasn't told what). Of course, the dummy address can also cause the odd
problem, but that is not as bad as having delays because of the
0.0.0.0 address on the unused interface. With a little imagination,
you can work around the problems in other ways, but it seems that
LLAeCS.EXE is to be a pert of eCS, so I think it is best to "get used
to it".

Just my $.02

[Galen Henderson]

Hi again, Doug.

Post by Doug Bissett
On Mon, 22 Mar 2010 00:24:22 UTC, Galen Henderson
That program can also wait forever, under some circumstances. It is
supposed to be fixed for eCS 2.0 GA, but I haven't seen the fix.
I find that it appears to hang during boot, often at NETBIND.EXE, but
it isn't NETBIND.EXE that is doing it. It is LLAeCS.exe, which is
started in \MPTN\BIN\MPTSTART.CMD in eCS 2.0 Silver edition, or in
\MPTN\BIN\SETUP.CMD in earlier versions. The best way to handle that
(and cut down on the boot time) is to REM it in the CMD file, make an
icon for it, and put it into the STARTUP folder.
One problem is that if you ever run the Select Interfaces for Sharing
program (it is run automatically after you configure PEER networking,
and possibly at other times), it will unREM the command in the CMD
file for you (it will probably hang at the next boot if you have that
problem).
Why not just REM it? Well, if you use a mixed WiFi and wired NIC
combination, you will find that the "unused" interface will be left
with an address of 0.0.0.0 which will cause many delays if you try to
use PEER networking (and possibly other things). I have also been
told, that it does something useful in a single NIC system too (I
wasn't told what). Of course, the dummy address can also cause the odd
problem, but that is not as bad as having delays because of the
0.0.0.0 address on the unused interface. With a little imagination,
you can work around the problems in other ways, but it seems that
LLAeCS.EXE is to be a pert of eCS, so I think it is best to "get used
to it".
Just my $.02

Thanks for the additional info. When I was doing wireless, I think I
went in to the TCP/IP java applet and disabled the interface that XWLAN
was using since it configures it independently of the boot lan code (at
least that is the way I remember it... Been a while though). And since
I am using EVFS for mapping drives and Herwig's port of Samba for
sharing, I do not have the tcpbeui protocol loading since I am not
using peer as provided by IBM.

[Jonathan de Boyne Pollard]

Post by Galen Henderson
Hello all. Just wanted to pass on something I found that shaved a few
seconds off of my boot times. There is a utility that runs after DHCP
that is supposed to assign a 169, address if DHCP fails. This utility
has a timeout feature that waits for dhcp. It is found in the
/mptn/bin folder in the file mptstart.cmd. Just comment out the line
that starts llaecs.exe.

Or do what I do, and invoke all of these things in parallel with the
rest of the boot process. On my system, INIT runs everything specified
in a run-file in the %_BOOT%:\Config\System\Init\AsyncRun\ directory
asynchronously. So I have a NetBind.RUN file in that directory that
invokes the command interpreter to run NETBIND, MPTSTART, and TCPSTART;
and none of that mucking about in CONFIG.SYS at all. As an added bonus,
the run file pipes the output of the three into the input of a CYCLOG,
so that it's logged, rather than thrown away.

Tailor to your favourite way of invoking programs asynchronously at boot
time, or lobby to have INIT released to the world. (-: