Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overclocking and Flickering (Reply) #551

Open
beikimajid opened this issue Mar 8, 2018 · 4 comments
Open

Overclocking and Flickering (Reply) #551

beikimajid opened this issue Mar 8, 2018 · 4 comments

Comments

@beikimajid
Copy link

beikimajid commented Mar 8, 2018

Hi
according to : #41

I test raspbian with last RT_Kernel but I did not see the difference .
With it I see some flicker. (p5 smd & 3 Rows & 6 Cols & passive PCB & 3 parallel).

I even test these conditions:
remove overclock setting
add overclock setting
remove isolcpus=3 in RT-Kernel
add isolcpus=3 in RT-Kernel

Are you sure that RT_Kernel is answer to have not flicker?

@hzeller
Copy link
Owner

hzeller commented Mar 8, 2018

RT kernel can improve flickering, but of course not eliminate it if we hit a hardware limit. So far the question is still open if it can create a much better experience than the regular kernel, so these experiments are needed.

Never do overclocking and always use isolcpus independent of the kernel.

You did not describe details to help people reproduce your findings: what compile-time parameters you choose when you compiled the kernel, or if it is a stock kernel, which exact distribution ? What kernel parameters did you choose at boot time (such as NO_HZ) ?

What did you do to induce the flicker? Usually flicker can only be seen these days if you run something in another shell.

@russdx
Copy link

russdx commented Mar 16, 2018

I will be trying a RT kernel soon to try and get 100% flicker free experience.

Is it as simple as just running RPI-RGB on a RT kernel with isolcpus=3 or does the RPI-RGB process need to be setup in a way it takes advantage of the RT kernel? ie it says it needs to be real time and do not every interrupt it.

Regards
Russell

hzeller added a commit that referenced this issue Mar 17, 2018
masking faint flickers.

Addresses flicker observations mentioned in #556 #551 #276 #495 #483 #478 #467
@hzeller
Copy link
Owner

hzeller commented Mar 17, 2018

Check out the new compile-time option in FIXED_FRAME_MICROSECONDS in lib/Makefile. It will allow to time-buffer glitches created by the rest of the system.

@HummingBuddha
Copy link

HummingBuddha commented Jul 4, 2018

Hello hzeller
I am using a 64x64 32s P2.5 module. I have too much of flicker. I tried "FIXED_FRAME_MICROSECONDS in lib/Makefile" but of no use. Is there any ways to improve the scan rate programatically? In other scan issues you have mentioned not to use 64x64 32S modules as they are slow but I have no other go I am working on a 64x64 P2.5, so pls let me know if there are any solutions for the flickers.
And is there any way to compress and accommodate larger image files into the UDP size?
And pls help me out in understanding how the UDP size is being calculated and at what size it would override the UDP max value as I got an override at 171x128 for a video wherein it was able to display at 170x128.

Thanks

hzeller added a commit that referenced this issue Mar 18, 2020
… on loaded system.

This used to be a compile-time option FIXED_FRAME_MICROSECONDS but
it is very useful to tweak at runtime.

Issues #276 #458 #467 #478 #483 #495 #551 #556 #571 #626 #651 #710
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants