0

I have two raspberrys p4 4gb ram ( same model ).

I instaled rasp os in a sd 32gb and in there it was instaled opencv dlib and other things to run a object detection.

after that i cloned my sd to other raspberry.

im my first sd it running in 3 fps and in my cloned sd its running 6fps.

i checked it twice its every thing tha same code and installed packages.

any one can help me to identify what causes this slowness?

im running a pyimagesearch object tracking code.

7
  • swap the two raspberrys ... unplug all the cables and the SD cards and swap the raspberrys only ... if the behavior does not follow the raspberrys, then swap the SD cards next
    – jsotola
    Commented Jan 9, 2021 at 18:19
  • i tryed it. one raspberry is slower than other . i swaped sds Commented Jan 9, 2021 at 18:25
  • the slowness keeps in the same raspberry Commented Jan 9, 2021 at 18:26
  • Are they in identical cases? With identical cooling? Is it possible that you are throttling or overclocking? You don't mention cameras, but are they identical, Are the images the same size? Are you taking identical images? Are the power supplies identical (including the cable)? Commented Jan 9, 2021 at 18:45
  • yes identical cooling and same camera ( intelbras ip camera ) no throttling or over. i got the SD from one raspberry and tested into another. Commented Jan 9, 2021 at 18:59

1 Answer 1

2

Identification of the root cause for this anomaly may be limited to those who have access to two things:

  1. Chip-level and gate-level hardware documentation

  2. Firmware documentation & access to the firmware sources

I won't say it's impossible for clever people to discover the root cause of this anomaly with the vcgencmd tools provided, but I will say that they are at considerable disadvantage to those with access - i.e. those with access to the closed sources.

While you couldn't classify it as the root cause of the anomaly you've seen (if it is in fact an anomaly), it strikes me as very likely that the RPi's closed-loop thermal management system is at the end of the causal chain. The closed-loop thermal management system takes various (?) temperature readings from the system, and ultimately (through firmware codes) adjusts the CPU's clock frequency. In other words, as the chip(s) heat up, the clock frequency goes down.

At the end of the day, we must recognize that the RPi is not an "open system", and there are some things we can't know about it. There are some things that we can try, but our efforts should be recognized for what they are: Not absolute answers, but a chance to "pull back the curtain".

You might begin by calling on the vcgencmd get_throttled command. There is some "official" documentation here, and there are some "how-to" articles that may provide additional insight. You could write a small script & run it periodically under cron or systemd on both systems & compare the results.

You might also peruse /var/log/messages for messages re throttling. This has the advantage of not placing any additional load on the system which could influence the results. I don't know that there is any documentation available to "decipher" these messages... I've always imagined /var/log/messages rather like the digital rain screens in "The Matrix" - rows of gibberish without documentation.

As a more physical experiment - to see if the RPi's closed-loop thermal management system could be isolated as a variable in the causal chain - you could chill & fan the RPi's such that there was no throttling at all - at least none reported. Then run your test as you've outlined in your question.

We'll look forward to learning of your results :)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.