[Asterisk-Users] Asterisk 1.0.9 long term stability <--thread
hijack, why not reboot?
Paul
digium-list at 9ux.com
Thu Sep 15 13:06:44 MST 2005
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?
More information about the asterisk-users
mailing list