Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

sgl_imaging_challenge_banner_globular_clusters_winners.thumb.jpg.13b743f39f721323cb5d76f07724c489.jpg

Sign in to follow this  
han59

Raspberry Pi 4 vs Pi 3 performance test

Recommended Posts

Maybe of interest,  a practical performance test between the Raspberry Pi 3 and Pi 4

Both  system where running  Raspbian Buster. The camera an ASI1600-MM Cool was connected using an USB 3.0 cable. The  imaging program was CCDCiel and  ASTAP was installed as the solver as described here.  PHD2 was installed for guiding but not used in this test.

1808781382_raspberryperformance.png.1431ed968ef0d585e2930e41b2052b26.png

The results show that the Pi 4 is in average twice as fast as the Pi 3. A lot of time is lost by downloading and saving the image. A class 10 memory card was installed.
The time lost is the time between the exposures for downloading the image via USB and saving it to the memory card.  So in the Pi 4  if you operate the ASI1600 camera in bin 2x2 mode there is 2.5 seconds lost between the exposures.  That's pretty good for deep sky imaging.

The solving time is the time required for plate solving the image.

Han

Edited by han59
  • Like 3

Share this post


Link to post
Share on other sites

That's very interesting Han. Thank you for doing this work.
Looking at the time lost between exposures, do you think the speed difference between USB2 and USB3 is a factor here?

On a Pi4 with a lot of memory there is the option to create a RAMDISK and save the image there. That will remove any time spent saving the image to the SD card.

Edited by pete_l

Share this post


Link to post
Share on other sites

The speed difference of the USB3.0 is significant.  I assume you could  also gain with a better memory card but the 2.5 seconds are fine for me.

The RAMDISK could be interesting. This a technology used in the past. But  CCDCiel has already the image in memory, if it could start a new thread and save the image in parallel while starting the new exposure this saving doesn't count anymore.  Maybe it is already done.  I could redo the test with only viewing the image and see how much time that takes. If it is shorter, that means time can be saved by starting a new separate thread. If so we could ask the CCDCiel author Patrick Chevally  to implement a new thread for saving the image.

But in any case these "lost times" are  already pretty good.

Han

Share this post


Link to post
Share on other sites

I did some experimenting. CCDCiel has a temporary and capture folder.  Created a ram disk and set the path's to the ram disk. No performance improvement. Dropped the question to Patrick, here.

Share this post


Link to post
Share on other sites
12 hours ago, pete_l said:

option to create a RAMDISK and save the image there

RPI Forum did tests on Zram and others and found very little gain by using such options - although my testing on a Zero(w) did show some improvement.

Share this post


Link to post
Share on other sites
13 hours ago, han59 said:

The time lost is the time between the exposures for downloading the image via USB and saving it to the memory card

Maybe using a SSD via the USB3 may improve saving times and possible Solving times. BUT at the moment you can't(lat time I looked) boot from USB on RPI4.

Still good to get comparison.

Note transfer 108mb fits image file from RPI3 to AMD64 takes under 10 secs over 100mb network - as a straight copy and paste. I am not sure but transfering data between Indi and a client maybe faster than Indigo even though they use the same protocol but Indi I believe use a different compression method

Share this post


Link to post
Share on other sites

Transport & saving of images while the next exposure is running will solve all delays except the transport time from camera to Raspberry Pi.

Patrick has already created the code for an experimental CCDCiel version which does multitasking. So starting the next exposure and saving the previous image goes in parallel. First test indicates the lost time between exposures will be half or less.

Note the above test results where for local ram-disk option. Transport via INDI localhost where 10% or 15% slower.

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.