billkarsh / SpikeGLX

SpikeGLX recording system GUI [Neuropixels NI]
Other
83 stars 29 forks source link

Stuttering graphics #3

Closed brykko closed 6 years ago

brykko commented 6 years ago

Hi Bill,

I just upgraded my SpikeGLX release from v20170901 to v20171101, and in the new version I've noticed that the graphics refresh rate is very slow and irregular under certain conditions. I After adjusting various settings, I realized it that the stuttering only happens when I used a common average referencing span of ~10 channels or more. I never saw this happen in v20170901, even though I commonly used a reference span of up to 30 channels. I checked the PC's resource usage and there was plenty of CPU and RAM headroom. I'm running Windows 10 and using the opt. 3 phase 3A probes (no NI-DAQ).

Do you have any ideas what the issue might be? Thanks in advance, Rich

billkarsh commented 6 years ago

Hi Rich,

Your observations surprised me because nothing has changed in the code between the versions w.r.t graphing or distribution of workload among threads. I’ve now retested the two versions side by side on a Win7 laptop and side by side again on a Win10 laptop. I do not see any difference in graphing performance relative to each other. Nevertheless, you are correct that graphing can stutter under high workloads…

Graphing performance depends upon workload within SpikeGLX: {Display of one or two streams, # channels per page, which filters are enabled, whether shank viewers are active, excessive window resizing activity, audio activity} and upon the background activity of any other applications. I find that the BinMax filter option imposes the greatest tax.

Perhaps you overlooked something like a filter setting. As new versions of SpikeGLX are released I often change the feature set or the types of parameters that are saved and all of that is in the ‘config’ subfolder. It is bad practice to copy a config folder from one SpikeGLX folder to another because there could be fatal incompatibilities…but for the purpose of this test with these versions that’s what I did. I ran 0901 and then copied the configs to 1101 so everything would be set up the same.

You might try this manner of testing to be double sure that 20171101 graphing is slower compared to the last version. When done testing, trash the config folders and new appropriate ones will be made for you. Let me know.

Bill

From: Rich Gardner [mailto:notifications@github.com] Sent: Wednesday, March 14, 2018 11:35 AM To: billkarsh/SpikeGLX SpikeGLX@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [billkarsh/SpikeGLX] Stuttering graphics (#3)

Hi Bill,

I just upgraded my SpikeGLX release from v20170901 to v20171101, and in the new version I've noticed that the graphics refresh rate is very slow and irregular under certain conditions. I After adjusting various settings, I realized it that the stuttering only happens when I used a common average referencing span of ~10 channels or more. I never saw this happen in v20170901, even though I commonly used a reference span of up to 30 channels. I checked the PC's resource usage and there was plenty of CPU and RAM headroom. I'm running Windows 10 and using the opt. 3 phase 3A probes (no NI-DAQ).

Do you have any ideas what the issue might be? Thanks in advance, Rich

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/billkarsh/SpikeGLX/issues/3, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AGxB0LITI7UDoFjcivsqa0co86kPhRggks5teTi5gaJpZM4SqqSY.

brykko commented 6 years ago

Hi Bill, Thanks for your advice – I will try your suggestions when I next do a recording in a couple of days and will let you know the outcome. I suspect that the culprit is probably the "BinMax" filter that you mentioned. I don't normally use this option, but from a screenshot I took while experiencing the slow graphing in 20171101 I can see that this option was indeed selected. I'll let you know. Thanks, Rich

brykko commented 6 years ago

Hi Bill – I can confirm it was indeed the "BinMax" filter that was causing the slow graphing performance. Thanks a lot for helping me track down the cause!

billkarsh commented 6 years ago

Fixed. Closing issue.