Since the update to 2.2.13 I have not been able to record with 7 channels at 100 MS/s. I need to drop a channel or drop the MS/s for it to work for long periods.
Since I need atleast 7 channels and 100ms/s, I had to drop back to 2.2.12 to be able to record.
Hm, Thanks for reporting this. We’ll need to do some side by side comparisons over here to figure out what happened.
Could you send me a few bits of detail:
- What are you recording? a small sample file would be helpful. Digital performance is affected by transitions per second and the presence of analyzers, and the amount of protocol data present in the capture per second.
- What is your computer’s make and model?
- Which saleae device are you using?
- What other capture settings are you using? (looping, trigger, fixed time, glitch filter)
- What OS are you using, and how much memory is installed in the computer?
What specifically is happening that’s not working? Is the capture ending before you need it to? If so, which error message are you seeing when that happens?
We’ve spent the last few weeks working on performance, so if we accidentally stepped it back a bit, we’d like to know.
Thanks again for reporting this, and I’m looking forward to getting to the bottom of this!
Probably unrelated, but I’ve noticed HLA bubbles stay behind after everything else in the trace window is cleared after start sampling is clicked. The HLA bubbles are cleared just before recording starts.
As a sampling data point: 50MHz digital across 10 channels. 3 Analog channels at 50MHz. No changes in 5 digital channels. 4 channels (2 x I2C) with 1ms if I2C (400kHz clock) activity every 100ms. 1 digital channel with effectively a 18kHz clock. 2 x Async serial, 3 x I2C and 3 x HLA (on I2C) analyzers. Sampled for 32s before giving up with “We could not keep up. Please reduce the sample rate and try again.”. Intel I7-4770 @ 3.4GHz with 32GB ram.
- I am recording 12.5 MHz SDIO (6 Channels - CLK, CMD, D0-C3) and a 921600 Baud Uart. https://www.dropbox.com/s/c1nqtdtgbgnz4c1/SampleRecording.sal?dl=0
- It is a Lenovo ThinkCenter M710t.
- Saleae Pro Logic 8
The problem that I am having is the recording ends early due to the backlog filling up. The image above is from Logic 2.2.12. The error says something along the lines of “Capture ended early due to backlog)”. Further with the same settings on 2.2.12 I can watch the recording / memory bars and I never see backlog. On 2.2.13 I will see backlog almost immediately.
Thanks Chris, we’re investigation this. The details help a lot, I’m going to try and reproduce this on Linux soon, to see if it behaves differently than our Windows testing.
We don’t know why 2.2.13 is slower than 2.2.12 yet, and we haven’t produced our own data that shows that yet, we’ve just seen a few reports from customers.
In the meantime, I wanted to point out that the glitch filter pretty much destroys the real time performance of the app. It will cause data to rapidly get backlogged.
I highly recommend disabling the glitch filter, or reducing the digital channel count and digital sample rate to the minimum that’s usable while the glitch filter is enabled.
We’re going to roll out an interim fix which allows you to enable the glitch filter for specific channels instead of all channels, which will help a LOT if you only need it on 1-2 channels, and then later we’ll optimize it, and make sure it’s properly parallelized. (right now we’re glitch filtering all channels, and it’s done from a single thread, which is a huge bottleneck)
We need to review our analytics a bit more, but it also looks like the USB error “can’t keep up at this sample rate” problem might be happening for our users a lot more than we expected. If that’s the case, we’re going to start working on that soon. The error is largely unrelated to processing performance, it’s purely a matter of pulling data from USB regularly. I think it’s negatively affected by high system memory usage and high CPU usage.
We haven’t actually run our performance tests on Linux yet, we’ve mainly run them on Windows, since most of our users are on Windows. I’m curious to see how it compares. (On MacOS, memory allocation is markedly slower than on Windows, we will likely move to a custom allocator with pools to improve this)