I have been using the original Logic for quite a while (been very happy), and recently, I switched laptops, and it did not work at all (Windows 10 with a Lenovo Thinkpad X1 carbon, i5-8250U). I am getting the error message Read Timeout, as described here: Error Message: ReadTimeout - Saleae Support
Essentially, it does not go beyond 4MS/s.
Now, I did try a few things, like switching USB ports, upping power management policies, trying betas of 1.x and 2.x, etc., and while I first suspected issues with the USB controller, I now tend to think the problem is related to scheduling/power management. I noticed, if I artificially keep Windows running in a high-power state (i.e. at max CPU frequency, and some other hacks), it does work flawlessly at 24MS/s. Now, I took a look at the Saleae application, and I can see that there are a few threads spinning up upon tracing, but what is strange is that the threads seem to have the base priority. I am not sure if you guys are doing something fancy to keep the worker threads responsive, but at least from what I can see here there are running at base priority with a small dynamic bump.
Just in case you have not done this, you should raise the worker thread priority, perhaps even to time-critical. As you need to quickly respond to data (even if 24MB/s seems nothing to a modern PC), you may want to try to “warm-up” the worker thread by running a small busy loop for a few ms, to kick it out of the idle state.
If you need a guinea pig, I would be willing to try a few things.
@greuelm Thanks so much for sharing this suggestion. I might have to share this with the team as we could provide this as a solution on our ReadTimeout support article that you shared.
Specifically for the original Logic (as I’m sure you may be aware from the support article), the internal hardware memory buffer is much smaller compared to what we offer in the newer products today (Logic 8, Logic Pro 8, Logic Pro 16). You could be on to something with raising the priority.
I’m not sure if setting to “time critical” priority is the best solution though (we haven’t done testing on this yet, so we can’t confirm). My initial thought is that this could lock up your PC if it consumes a significant portion of it’s CPU/Memory available bandwidth.
I’m not sure if setting to “time critical” priority is the best solution though
Yes, you can starve the whole system to death when you run a busy loop at that priority with just one CPU core installed. I agree, you probably should not use time-critical, I seem to remember you even need elevated privileges to do so. Lowering the priority of the decoder threads might help too.
Sorry for the trouble with this, and thanks for the investigation! The power state is a really good find, we’ll take a closer look to see if there is a way to work cooperatively with the OS there.
For reference, in the 1.x software, on Windows, we do set the USB read thread to THREAD_PRIORITY_ABOVE_NORMAL.
In the 2.x software, on Windows, we set the USB read thread to THREAD_PRIORITY_HIGHEST, using the SetThreadPriority Win32 API.
Now that I think about it, I’ve never validated that with an external tool. What tool are you using to examine the thread priorities?
Btw the last few releases of the Logic 2.x software should be naming the USB thread “USB Device” using the SetThreadDescription Win32 API, which hopefully will make it easier to find.
The only thing the thread does is keep 10 very large WinUSB transfers queued. The thread doesn’t do much.
Could you send screenshots of the CPU power policy before and after you edited it? I’ve never looked into it before, but Microsoft might have developer documentation that describes how it affects application performance.