Comments about stability #1468
Comments about stability #1468
Conversation
|
It should be noted that this is correct. However there is another way to work through this, but it is much more involved. The suggested method here works on the idea of max serial clock. Any stalls in the memory bus are problematic. The suggestion here is to use worst case analysis to prove issues. There is another prediction from worst case analysis, which is to intentionally use worst case from memory bus to prove stability. The result of this is a lower serial clock. The issue with the first worst case analysis is capacity of the cache is critical. The stalls are less problematic and therefore this is faster. However once the cache is too small the memory stalls begin to appear. To works around this you can lower the serial clock which will force compromises in refresh, size and quality. This will still allow for decent sized displays. There is one small problem with this second worst case analysis approach. That is the refresh rate may spike. However this is solved by configuration using the OE signal timing. If one looks closer they will discover that this is secretly the PWM period which is also the refresh rate. It should be noted that larger displays are subject to fan out limits, however that is getting off topic. Another slightly off topic point relating to refresh rate is S-PWM which is potentially capable of allow automatic scaling. This is probably only suitable for the second worst case analysis approach. Non-hardware PWM panels generally speaking do not need S-PWM so there is another automatic scaling approach which can be used for both methods without S-PWM. Careful inspection of run time should allow this, but it may be more work than its worth. My application in theory actually could work with this code base. However I did identify a few issues which would require some structural changes. At this time I am planning to move forward with another approach. Note there are solutions to the memory bus however none are applicable to the Raspberry Pi(s) at this time. |
|
bluelasers Joined GitHub on March 8, 2022. No other code written, no other project, no contributions. |
|
I would recommend limiting the number of CPUs given to the OS. Currently three are recommended. Limiting this to one, could provide a path to mitigation. |
|
I recommend assuming bluelasers is still David Tacher and to safely ignore him. |
Played around with it and figured this would help others.