Hi, On Sun, Feb 21, 2016 at 08:35:26PM +0100, Henk Hendricks wrote: > I was trying to continuously log some signals using an FX2 demo-board. > And I noticed a big difference the number of samples recorded on Win7 > and Fedora23, 250kS and 200MS respectively. > > This was at a sample frequency of 200kHz, using a sample frequency of > 500kHz, around 650kS were received. > Trying the same on a i3 Win7 laptop resulted in roughly the same the > numbers. A 7inch Acer with an Atom cpu wasn't able to compete. > Then I tried an old i7 desktop, it receives 410kS, and 1MS respectively. > > This was all recorded using a python script which repeatedly called > sigrok-cli with a new filename. > So this is where I thought the problem was maybe my python script, so I > tried manually on the old i7. > But manually was worse!, 320kS and 810kS respectively. > Note that I just reinstalled sigrok-cli and the zadig driver. So I would > think the new libusb patch would be included.
The most recent Windows installers we provide for sigrok-cli and PulseView are fine, yeah. Both include the special libusb branch that's currently required and an additional patch on top of that to improve fx2lafw performance. > So is 't possible to get the performance I got using Fedora 23 on Windows? I don't think this specific issue is related to Windows here. It's more likely to be a difference between sigrok-cli and PulseView in general. I opened bug #762 for this and attached some of my own measurements there. http://sigrok.org/bugzilla/show_bug.cgi?id=762 I haven't verified this, but my guess is that the difference is due to PulseView storing samples directly in RAM (which is fast), while sigrok-cli (with "-o foo.sr") will try to save every chunk into an .sr file immediately when it arrives. This takes a lot longer due to file access in general and compressing via libzip, so samples may be missed eventually. If that's the case, we'll need to add some buffering (in RAM) so that no matter how long the .sr save takes, samples will not be "lost" by the hardware. > Maybe some simpler questions: > Why is a sample limit of 1T invalid using the command-line, but it is > selectable in PulseView? Good point, that's missing support in libsigrok. Filed a bug here: http://sigrok.org/bugzilla/show_bug.cgi?id=763 The max number of samples (for devices where there's no limit) is pretty arbitrary in PulseView, might as well add higher ones too, and most certainly a "sample continously" option (I think there's a bug for that already, haven't checked though). > And is 't possible to 'continiously' measure (like my script) with > sigrok-cli, i.e. without restarting sigrok and overhead associated with it? Yep, use --continous instead of --samples or --time. Until the buffering mentioned above is implemented PulseView will currently yield better results with fx2lafw devices, though. Cheers, Uwe. -- http://hermann-uwe.de | http://randomprojects.org | http://sigrok.org ------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140 _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
