From: geremy condra on
On Fri, Jul 9, 2010 at 3:13 PM, Les Schaffer <schaffer(a)optonline.net> wrote:
> i have been asked to guarantee that a proposed Python application will run
> continuously under MS Windows for two months time. And i am looking to know
> what i don't know.

I normally use Linux for this sort of thing, so YMMV on the following advice.

> The app would read instrument data from a serial port, store the data in
> file, and display in matplotlib.  typical sampling times are about once per
> hour. our design would be to read the serial port once a second (long story,
> but it worked for ten days straight so far) and just store and display the
> values once an hour. so basically we'd have a long running for-loop. maybe
> running in a separate thread.

I'd keep the two timers, the process that actually checks and logs the data,
and any postprocessing code completely separate. I'd also use something
like the logging module to double up on where your data is stored- one on
the local machine, another physically separated in case you lose a hard
drive. It will also give you more information about where a failure might
have occurred if/when it does. I'd also handle output/display on a separate
machine.

> i have thought through the issues on our end:  we have to properly handle
> the serial port and make sure our GUI doesn't hang easily. we'd have to be
> sure we don't have any memory leaks in numpy or matplotlib and we're not
> storing data in memory stupidly. i've never looked into Windows serial port
> driver reliability over the long term. But we think if the serial port
> hangs, we can detect that and react accordingly.

I would launch this as a subprocess and log so that even if you miss a
measurement you still get what you need further on in the process.
Just make sure that you can detect it at the time and that you also
log an error when it occurs.

This also minimizes the amount of memory your application directly
handles and the susceptibility of your code to non-fatal problems with
the serial port.

> but none of this has anything to do with Python itself. i am sure python
> servers have been running reliably for long periods of time, but i've never
> had to deal with a two-month guarantee before.  is there something else i am
> missing here that i should be concerned about on the pure-Python side of
> things? something under the hood of the python interpreter that could be
> problematic when run for a long time?

Just ask all the what-ifs and you'll probably be ok.

Geremy Condra
From: Martin P. Hellwig on
On 07/09/10 20:13, Les Schaffer wrote:
> i have been asked to guarantee that a proposed Python application will
> run continuously under MS Windows for two months time. And i am looking
> to know what i don't know.
Get a good lawyer and put into the contract, the last thing you want is
a windows update that restarts the host and you are responsible because
you guaranteed that it would run continuously.

On the technical side; as Christian Heimes already pointed out, split
the programs. Specifically I would have 1 service for data gathering,
two separate watchdog services (that checks whether the other watchdog
is still running and the 'core' service).

The GUI should be an user side app and the services could be too,
however consider running the services under the appropriate system
account as in the past I have seen some strange things happening with
services under user account, especially if there are password policies.

I don't see from the interpreter point of view no reason why it couldn't
work, it is much more likely your host system will mess things up (even
if it wouldn't be windows).
<cut rest>
--
mph
From: John Nagle on
On 7/9/2010 12:13 PM, Les Schaffer wrote:
> i have been asked to guarantee that a proposed Python application will
> run continuously under MS Windows for two months time. And i am looking
> to know what i don't know.

What if Master Control in Redmond decides to reboot your machine
to install an update? They've been known to do that even when you
thought you had remote update turned off.

If you have to run Windows in a data acquistion application,
you should be running Windows Embedded. See

http://www.microsoft.com/windowsembedded

This is a version of Windows 7 which comes with a tool for
building customized boot images. Basically, you take out
everything except what your application needs.

Do you get Embedded Systems Journal? You should.

John Nagle
From: Emile van Sebille on
On 7/9/2010 12:13 PM Les Schaffer said...
> i have been asked to guarantee that a proposed Python application will
> run continuously under MS Windows for two months time.

Keep users off the machine, turn off automated updates, and point dns to
127.0.0.1. Oh, put it on a UPS. I've got a handful or two of these
automated systems in place and rarely have trouble. Add a watchdog
scheduled task process to restart the job and check disk space or memory
usage and push out a heartbeat.

I found Chris Liechti's serial module years ago and have used it
successfully since.

The only times that come to mind when I've problems on the python side
were related to memory usage and the system started thrashing. Adding
memory fixed it.

HTH,

Emile


> And i am looking
> to know what i don't know.
>
> The app would read instrument data from a serial port, store the data in
> file, and display in matplotlib. typical sampling times are about once
> per hour. our design would be to read the serial port once a second
> (long story, but it worked for ten days straight so far) and just store
> and display the values once an hour. so basically we'd have a long
> running for-loop. maybe running in a separate thread.
>
> i have thought through the issues on our end: we have to properly handle
> the serial port and make sure our GUI doesn't hang easily. we'd have to
> be sure we don't have any memory leaks in numpy or matplotlib and we're
> not storing data in memory stupidly. i've never looked into Windows
> serial port driver reliability over the long term. But we think if the
> serial port hangs, we can detect that and react accordingly.
>
> but none of this has anything to do with Python itself. i am sure python
> servers have been running reliably for long periods of time, but i've
> never had to deal with a two-month guarantee before. is there something
> else i am missing here that i should be concerned about on the
> pure-Python side of things? something under the hood of the python
> interpreter that could be problematic when run for a long time?
>
> or need we only concern ourselves with the nuts behind the wheel:that
> is, we the developers?
>
> thanks
>
> Les


From: Roy Smith on
In article <4c3774df$0$31278$607ed4bc(a)cv.net>,
Les Schaffer <schaffer(a)optonline.net> wrote:

> i have been asked to guarantee that a proposed Python application will
> run continuously under MS Windows for two months time. And i am looking
> to know what i don't know.

Heh. The OS won't stay up that long.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Hello
Next: the ball needs a kick...