On Tuesday, 11 April 2017 13:23:36 BST Patrick Wigmore wrote:
> On Tuesday, 11 April 2017, at 12:16:44 BST, Terry Coles wrote:
> > Thanks. Now I can focus on the overheating. We were trying to
> > avoid any holes in the case for ventilation.
>
> I don't want to jinx it, but you might find you
On Tuesday, 11 April 2017 13:00:29 BST Ralph Corderoy wrote:
> Do you know what's generating the heat? Infra-red thermometer or
> camera? Can anything be added that would conduct the heat from those to
> the case or the internal heatsink?
At this stage, I'm not completely certain that heat is
On Tuesday, 11 April 2017, at 12:16:44 BST, Terry Coles wrote:
> Thanks. Now I can focus on the overheating. We were trying to
> avoid any holes in the case for ventilation.
I don't want to jinx it, but you might find you have to drill
some drainage holes anyway. Water is a sly opponent! I'd
Hi Terry,
> We were trying to avoid any holes in the case for ventilation, so
> cooling depends on internal circulation of the air to move the heat
> from the hot-spots to a finned heatsink on the inside of the case.
Do you know what's generating the heat? Infra-red thermometer or
camera? Can
On Tuesday, 11 April 2017 11:40:05 BST Ralph Corderoy wrote:
> They take buffers and cache out of the equation. 785612 / 16204 = 48 so
> you can withstand growth at that rate for quite a few multiples of your
> monitoring period, if it's linear.
Thanks. Now I can focus on the overheating. We
Hi Terry,
> My interpretation of that is that free memory has declined (fairly
> rapidly), but the values for shared, buffers and cached have increased
> too. Presumably, that memory will be released by the OS when needed?
Buffers and cache, yes. These are the interesting lines from your two
On Monday, 3 April 2017 22:37:01 BST Ralph Corderoy wrote:
> > Would this be a standard subprocess.call() invocation or is there a
> > better way?
>
> The former seems fine AFAICS.
Thanks.
> > Would I need to create two global instances of /dev/null if I use it
> > twice in the same function?
>
Hi Terry,
> Would this be a standard subprocess.call() invocation or is there a
> better way?
The former seems fine AFAICS.
> Would I need to create two global instances of /dev/null if I use it
> twice in the same function?
No, the file descriptor of the open Python File for /dev/null that
On Monday, 3 April 2017 16:39:48 BST Ralph Corderoy wrote:
> > I suppose that I could set up another apscheduler event to do a reboot
> > at midnight.
>
> If they don't need to normally twiddle switches after it powers on to
> have it carry out the typically desired routines, then yes you could.
Hi Terry,
> I suppose that I could set up another apscheduler event to do a reboot
> at midnight.
If they don't need to normally twiddle switches after it powers on to
have it carry out the typically desired routines, then yes you could.
> > I doubt leaks would be sufficient to consume all that
On Monday, 3 April 2017 13:44:17 BST Ralph Corderoy wrote:
> I was thinking this Pi was being turned off each night, like the other
> one. I expect I've forgotten that it's always on.
We could tell them to turn it off; they used to have to do that for the old MP3
Player (a
portable stereo
Hi Terry,
I was thinking this Pi was being turned off each night, like the other
one. I expect I've forgotten that it's always on.
If the switches were set into position rather than spring-return to the
centre then one option would be to configure Raspbian to reboot
periodically, with your
On Sunday, 2 April 2017 15:49:54 BST Terry Coles wrote:
> That's a bit of a non-flyer too, because dstat doesn't appear to be
> available in the Raspbian repositories. Also, the software is running in
> the shell at boot up, so it would be difficult to view two things running.
> (Would screen do
On Sunday, 2 April 2017 14:13:02 BST Terry Coles wrote:
> > You could leave your program running in tandem with `dstat -cdngym
> > $((60*30))' that produces a line every half an hour and see if anything
> > obviously degrades over time.
>
> That wouldn't be very convenient to view, since the
On Sunday, 2 April 2017 14:05:42 BST Ralph Corderoy wrote:
> AIUI your program is doing this, with a few more bells and whistles.
Lots of bells, but no whistles.
> All these bits of code may have bugs where they leak memory in
> processing that endless stream and over time that leak will add up
Hi,
The question is in the Subject.
My Model Town program is designed to run continuously, but I'm not sure if it
will run out of memory eventually if the script continuously sends messages to
the shell.
I vaguely recall that there is a buffer for the content of STDOUT, but can't
find any
16 matches
Mail list logo
