Finding Raspbian iterative loop unreliable - how to report?

Question

I have developed multiple YouTube Raspberry PI clock projects since 2014 and all of them require iterative loops checking for the time (seconds) to change to update a digital, binary or roman numeral displays. With the latest Python 3.5.3 and Raspbian (NOPS 2.8.2) operating system, the iterative loop is no longer reliable. The same problem occurs on PI Zero-WIFI, 3B, and A+ platforms, but not PC.

I wrote a simple iterative program (listed below) that checks for the change in time (seconds), counts the number of loop iterations between seconds, and watches for intervals when there have been no iterations. No iterations indicate that Python is getting ready to completely hang and the mouse will become unreliable, later it will quit driving the HDMI display. I collected data the first time a zero-iteration count was detected between seconds. I average number of iterations and seconds of proper operation on each platform is as follows:

PLATFORM -- AVERAGE ITERATIONS/SECOND -- AVERAGE SECONDS TO FAILURE -- SAMPLES
MODEL A+ --           4,995           --          27,569            --   10
ZERO WIFI--           8,384           --          94,288            --   10
MODEL 3B --          47,199           --         208,571            --   10 
PC (I5)  --       1,000,000           --   DID NOT FAIL IN 12 DAYS  --    1

I tried using different power supplies, avoiding use of an external USB hub, and disconnecting WIFI from A+ without making any difference. Insured all platforms were using the current Raspbian downloaded from the website on 11/07/2018. No overclocking options were added.

I have pictures of the screen and unit being used at the time of failure.

# OPSYS-BUG# 11/02/18 Jim Roberts
# Import system subroutines.
from time import sleep         
import time

# CONSTANTS
lastsec=''                      # LAST SECOND PROCESSED
ct=1                            # LOOP COUNTS BETWEEN LCD REFRESH
ctot=0
cnbr=0
csec=0
mx=10
try:                            # ESTABLISH ERROR HANDLING FOR CTRL+C
    while mx>0:
        s=int(time.localtime().tm_sec)          # SECONDS
        if s != lastsec:
            lastsec=s    
            h=time.localtime().tm_hour          # HOURS
            m=time.localtime().tm_min           # MINUTES
            out=str(h+100)[1:3]+':'+str(m+100)[1:3]+':'+str(s+100)[1:3]  
            ctc=str(ct)         
            if ct < 10000:
                ctc = " " + ctc
            csec=csec+1    
            print(ctc + "   " + out+"   "+str(csec)+"   "+str(csec/(60*60*24)))
            cnbr=cnbr+1
            ctot=ctot+ct
            if ct==0:           # ERROR OCCURING - STOP AFTER MX OCCURENCES
                mx=mx-1     
                print("LOOPS- ", ctot, "COUNTS- ", cnbr, "AVG- ", ctot/cnbr)
                print("CYCLES             SINCE--START")       
                print("PER-SEC HH:MM:SS   SECS    DAYS") 
            ct=0
        else:
            ct=ct+1                 # BUMP LOOP CYCLE BETWEEN LCD REFRESHES
except KeyboardInterrupt:        
    GPIO.cleanup()                  # IF CTRL+C ENTERED, CLEAN UP AND EXIT

Answer 1

As there is no delay / sleep in the code, you are hitting the CPU & the underlying Linux systems pretty hard - I'd imagine that at some point some housekeeping is being triggered and I've seen SD Card writes tie up a Pi for a second or two.

Can you put a sleep(0.01) at the bottom of your while loop - this will reduce accuracy / response time by a 100th of a second but you can tune it accordingly.

Doing this reduces the CPU load on my iMac from ~95% to 1%.

I'm offering this as a pragmatic solution to test - the underlying details of what exactly is going on seems a bit academic - a loop to check the time for the next second to update a clock display running at a rate of 100 per second seems appropriate.