Andrew Kohlsmith wrote:
On Thursday 15 September 2005 11:38, Paul wrote:
They designed it to be shut down. I guess that means it doesn't just
roll over like a dead cow.
Actually dead cows aren't back-heavy. They typically just keep whatever
position they were in when they took their last breath, much like the telco
crosspoint switches. :-)
In order to argue that point I would have to do some rather inhumane
research :-D
You wouldn't design a crane controller so that it releases the load on
reboot and then tries to return the cable to the pre-reboot position.
The same principle applies here. If it's mission-critical, you might
have to spend more on the hardware. A good example would be crosspoint
I agree -- You need to spend more time on both hardware and software. For me,
a phone system is like a file server or network switch -- it is *not* meant
to be rebooted. If it needs to be periodically power-cycled then address the
problem, don't simply put a cron script in.
I did hardware and software design for some devices that were usually
placed in very remote areas(underwater, mountains, arctic are a few). We
used a very low power clock device that would boot the cpu up. We did
whatever needed to be done, set the clock registers for the next wakeup
and shut down again. There were other ways to approach the problem, but
this approach made coding easier, used less power and allowed us to get
more functionality without increasing rom or ram size. If you only
How did it save you ROM/RAM? I can see it saving having to put fancy power
controller code and hardware in... Is that what you meant?
The short answer is that the coding was more linear. Boot, run a state
observer, setup the clock chip for next alarm and write an I/O bit that
kills the power bus feeding the CPU area of the board. When data was
being unloaded through the serial port, I skipped the final write and
looped back to the top of the state observer.
needed to take one simple measurement and store it to the ram, you could
do a boot/run/shutoff every second and still achieve some additional
battery runtime.
Agreed but again -- you designed for this specific purpose. Asterisk isn't
meant to boot up, answer the phone, process the call and shut down again
until the next ring. (This would be an interesting approach to power savings
though if your system boot time was fast enough and call volumes varied
enough to make it worthwhile.)
I have seen windows systems that boot up and crash. Would this be a good
start?
_______________________________________________
--Bandwidth and Colocation sponsored by Easynews.com --
Asterisk-Users mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
