Hi Robert, hi Alex, since logic data isn't stored per-channel but per-sample, we in this case have 16 bit-sized samples. Repeat that for 10^6 samples for 4 minutes and we end up with 458MiB of raw data. I think that's manageable.
The issue with PV is that for simplicity in the implementation, it uses the vector data type to hold this data and resizes it when data comes in as it can't know ahead of time how much data there will be. Hence, if PV tries to grow the vector (which is really a glorified array) from 450 to 451MiB, it will need to find a contiguous area in memory that can hold 451MB. At the same time, the 450MiB of existing data are also held. So we need about 1GiB of contiguous memory to perform this resize. If the OS can't provide this, memory resizing fails and PV will need to stop accepting data. This is what happens here. Yes, this implementation is in need of improvement, no doubt. In the meanwhile, you can split the .sr files into smaller ones. You can rename your .sr to .zip and have a look at the internals, they're rather straightforward. logic-1 will hold the 16-bit samples and you can cut it in size as long as you adjust the length in the meta data file as well. Someone on IRC wrote a tool for this a while ago but right now I don't remember who it was or where he put it... All the best, -Soeren On Thu, 2017-01-19 at 00:59 +0100, Roland Hieber wrote: > Hi, > > On 17.01.2017 18:28, Alexander Kugel wrote: > > > > I tried to load a .sr file with 12 Channels, 1msps and about 4 > > minutes > > of capturing. > > Wait, let me shortly ballpark that... 12 channels * 10^6 symbols per > second * 4 * 60 seconds = 2880 Msymbols, right? That sounds like a > lot. > > If each symbol is represented by only 1 bit, you'll need about 360 MB > alone to represent the data in memory. (The .sr file format however > is > compressed, so it may be smaller than that.) But there is probably > some > overhead in sigrok and pulseview in order to actually display the > data, > so I'll guess it comes to 1 to 4 bytes of memory for each symbol, > which > will take you to the order of ~2 to 10 GByte in order to display all > information in your file, without any optimizations. > > > > > At about 2:14min it stopps with an Error: > > > > "Failed to Load <File> Out of Memory, acquisition stopped." > > > > Is there a chance to work around this, or get more memory reserved > > for > > PulseView? > > That depends, we need more information here :) Are you on Linux, Mac, > Windows, anything else? On Linux and Unix-likes, you can watch the > memory consumption of the puleview process by using top or htop [0], > sorting by MEM% (press "M") and having a look at the "RES" column. On > Windows, look at the resource usage in the task manager. If you > really > get to the limit of your available memory (RAM+Swap), there is > probably > not much you can do except buy more RAM, reduce the sample rate of > your > input file, split the file into smaller files, or come up with more > efficient memory handling in sigrok and pulseview. > > If pulseview memory consumption is much lower than your available > memory, there might be other issues involved. But let's cross that > bridge when we come to it. > > [0]: https://linux.die.net/man/1/top, > https://linux.die.net/man/1/htop > > Cheers, > - Roland > > ------------------------------------------------------------------- > ----------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, SlashDot.org! http://sdm.link/slashdot > _______________________________________________ > sigrok-devel mailing list > sigrok-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/sigrok-devel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ sigrok-devel mailing list sigrok-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sigrok-devel
