Conference irocz::terminal_servers

Sorry, I have not monitored this notesfile in some time... 

re .16: The 2� minute time is one the US Air Force has dictated to Lockheed
Martin Corporation (LMC) and it represents part of the mean repair and downtime
allowed for the radar system. Since most of these sites are remote (like at the
top of Alaska, Canada and Iceland), the power is not always the "cleanest". With
very few sites actually manned, the AF is accessing the systems remotely through
the DECserver -- as the radar starts up with messages or errors, this
information is lost while the 90M boots. 

We actually went back to LMC with the change, and they got a concession from the
USAF, but at a cost to LMC. It looks like LMC got squeezed for $306K for this
change...

re .18: We looked at the MOP load, but with the redundancy required, we cannot
guaranty that one (of the two) 2100As would be available to server the MOP
request, so this idea was scrapped. 

But, coming back to the original issue, we got back into hot water again with
the increased time (now almost 6 minutes) with the V2.0 firmware, but I'll post
the note about that after I close this one.

RE: .19

Sounds like they really need the 2 MB Flash RAM...  Sigh.

Regards,

Dave

For this type of application, I'm surprised a UPS (Uninterruptable Power
Supply, usually battery backup power) isn't part of the picture.  Since
the DS90M draws so little power, a relatively small UPS could provide
enough power to keep the DS90M up and running through some pretty long
power outages.

> re .18: We looked at the MOP load, but with the redundancy required, we cannot
> guaranty that one (of the two) 2100As would be available to server the MOP
> request, so this idea was scrapped. 

Instead of VMS and MOP to reload the DECserver, what about a cheap PC or
two running the Access Server Loader?  Surely the PCs could be set up to
boot within 2� minutes....

Jim

P.S.  Are you still interested in having the uncompressed image included
on the distribution CD?

>P.S.  Are you still interested in having the uncompressed image included
>on the distribution CD?

Well I would, in our test environment we keep rebooting these things so
often that the delay can be annoying.

Regards,

Oswald

re: .19, larger Flash option:

That is a very attractive alternative. I just spoke with Jon Lewandowski and
this is one of the options he mentioned and would investigate. As you mentioned
Dave, the code will always get bigger (I'm a SW engineer and speak from past
history on that ;^)

re: .21, UPS, PC load of FW, uncompressed image:

Jim, yes we have a big rackmount 3.1KVA UPS from Deltec in the rack already.
This unit is large enough to run 
	- (2) AS2100A's, 
	- a VME rack with 6 interface boards, 
	- the 90M terminal server, 
	- a serial line switch box for 13 lines, 
	- discrete I/O and 
	- (2) intelligent power controllers for remote AC power cycling 
	  capability
for about 30 minutes. The UPS also provides comprehensive line filtering for 
when radar is running off a generator (which is not exactly the cleanest source
of power). 

Unfortunately, the contract spec states the boot time from cold start power-up.
The issue they are seeing is that the AS2100 displays all the diagnostic
information from the built in test when it boots, so all of this information is
lost while the 90M is booting. They need this information to know what the 
error is so that they can load the correct equipment on the helicopter for 
repair/installation at the remote site. 

In terms of using a PC, that's a great suggestion, but there would be no way 
we could fit the PC into the rack, nor are we allowed to put a PC into any 
of the other cabinets (there is only so much room in the shelters). I was not
aware we could serve images from a PC, so I will keep that in mind for other
opportunities. Thanks for the info. 

For the uncompressed image, I do not think that we will be able to use the 
option where we load the firmware from a server. But, I would have to believe 
that there are plenty of others who would be able to use this image. I would 
highly suggest providing this image as an option, since from what I heard here,
this would not be terribly difficult to do. 

I know that this is a complex issue, but I really appreciate all of the help
and suggestions -- keep them coming!

Thanks,

   Chris

>The issue they are seeing is that the AS2100 displays all the diagnostic
>information from the built in test when it boots, so all of this information is
>lost while the 90M is booting.

Does the AS2100 display this information when it starts booting or when it
actually completes booting?  If it's the latter, the only solution (without
the 2MB Flash) I can see is to get the DS90M to boot faster than the AS2100.

If you can modify the AS2100's startup procedure to get the network up and
running quickly, and the uncompressed load image is made available, it may
be perfectly reasonable to expect the DS90M to be up and running by the time
the AS2100 dumps out the diag info.

Jim

Hi ,
	My 90M next to me takes seconds to either complete a load from
FLASH or bootp/tftp what takes me I guess 5 minutes (as I have not timed it)
is while it init's itself.
	Can any one explain why 90M's take so long to get past flashing
the top and bottom 4 light alternaly during init phase?


	Cheers
		mark :)
[Posted by WWW Notes gateway]

RE: .25

>	Can any one explain why 90M's take so long to get past flashing
> the top and bottom 4 light alternaly during init phase?

Yes.  It takes that long to decompress the compressed version of the load
image.  The flashing LEDs is an indication of decompression in progress.

Regards,

Dave

>P.S.  Are you still interested in having the uncompressed image included
>on the distribution CD?

I've switched to the 90M from the 90TL; we load from Infoservers so they load
in a flash.

But the 90M slllllllllllllllllllooooooooooooooooooooooooooowwwwwwwwwwwwllllllly
decompresses.

re: .24:

Jim, 

The systems provide this information during the hardware restart by the console
firmware. We have the 2100A console connected to the DS90M so that when the
system boots, all of the console messages are available to be viewed remotely.
The firmware tests memory, CPU, bridges and various options and this information
is needed for the system's fault detection and isolation strategy. There are no
network drivers running on the system since we have not yet booted OVMS. OVMS
may provide additional information, but it is usually not as specific as the
console-provided info. 

If the 90M is still booting while the 2100A boots, then this console information
is lost. Lockheed Martin has a restart requirement for the whole radar and the
boot of the 2100As/90M/driver loads/etc is only a part of the total starting
tasks for the mission.