From laforge at osmocom.org Sun Dec 1 13:40:33 2019 From: laforge at osmocom.org (Harald Welte) Date: Sun, 1 Dec 2019 14:40:33 +0100 Subject: OsmoDevCon 2020 registration Message-ID: <20191201134033.GB1292548@nataraja> Dear fellow Osmocom developers, I would like to invite all developers and contributors to Osmocom [sub]projects to register for OsmoDevCon 2020 (held on April 24th-27th, 2020 in Berlin). For details known so far, please check http://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020 Please enter your name at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2020#Requested in case you would like to attend. Registering early allows proper planning. Thanks! Looking forward to meeting old and new Osmocom developers in April 2020. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From dchardware at gmail.com Thu Dec 19 14:06:17 2019 From: dchardware at gmail.com (Sipos Csaba) Date: Thu, 19 Dec 2019 15:06:17 +0100 Subject: Fwd: gr3.7-qt5 --> CL Error: Unable to queue clear of spectrum buffer In-Reply-To: References: Message-ID: Hi Sylvain, Resent it to the list as requested. I tried to use the 'gr3.7-qt5' branch today, and after successful compilation, I am getting this error message on the terminal: [+] Available device: 0:0 NVS 4200M [+] Selected device: NVS 4200M [!] CL Error (-59, /root/gr-fosphor/gr-fosphor/lib/fosphor/cl.c:438): Unable to queue clear of spectrum buffer I attached the complete output of the event, if you want to take a look. I also attached the screen how it looks during the run. OpenCL works fine otherwise, and I used gr-fosphor successfully on this same machine before. I am on Ubuntu 18.04.03 LTS with the proprietary Nvidia driver (v390). The gnuradio is 3.7.13.5 (comes with the ubuntu repo, not compiled from source). If you have any idea, or you need more info, debug log etc. please let me know. Regards, Csaba -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_2019-12-17_21-21-37.png Type: image/png Size: 47807 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gr-fosphor.log Type: application/octet-stream Size: 26508 bytes Desc: not available URL: From tnt at 246tnt.com Thu Dec 19 14:23:11 2019 From: tnt at 246tnt.com (Sylvain Munaut) Date: Thu, 19 Dec 2019 15:23:11 +0100 Subject: gr3.7-qt5 --> CL Error: Unable to queue clear of spectrum buffer In-Reply-To: References: Message-ID: Hi, > OpenCL works fine otherwise, and I used gr-fosphor successfully on this same machine before. Which version did you use and with which drivers ? > I am on Ubuntu 18.04.03 LTS with the proprietary Nvidia driver (v390). The gnuradio is 3.7.13.5 (comes with the ubuntu repo, not compiled from source). Try reverting a269271fed026d5e633fa45f4dd5db125133f453 and see if that helps. Cheers, Sylvain From dchardware at gmail.com Thu Dec 19 16:54:46 2019 From: dchardware at gmail.com (Sipos Csaba) Date: Thu, 19 Dec 2019 17:54:46 +0100 Subject: gr3.7-qt5 --> CL Error: Unable to queue clear of spectrum buffer In-Reply-To: References: Message-ID: Hi, I attached the clinfo output about the version and capabilities of my hardware. Other than this, I am using the proprietary nvidia driver for linux (version 390) with kernel 4.15.0-62-generic, and gnuradio 3.7.13.5~gnuradio~bionic-4. I tried to find that commit you are referring to, but it seems it is no in the git log (or at least I cannot find it). Can you take a look if it is correct? Thanks in advance! Regards, Csaba Sylvain Munaut ezt ?rta (id?pont: 2019. dec. 19., Cs, 15:22): > Hi, > > > > OpenCL works fine otherwise, and I used gr-fosphor successfully on this > same machine before. > > Which version did you use and with which drivers ? > > > I am on Ubuntu 18.04.03 LTS with the proprietary Nvidia driver (v390). > The gnuradio is 3.7.13.5 (comes with the ubuntu repo, not compiled from > source). > > Try reverting a269271fed026d5e633fa45f4dd5db125133f453 and see if that > helps. > > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Number of platforms 1 Platform Name NVIDIA CUDA Platform Vendor NVIDIA Corporation Platform Version OpenCL 1.2 CUDA 9.1.84 Platform Profile FULL_PROFILE Platform Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts cl_nv_create_buffer Platform Extensions function suffix NV Platform Name NVIDIA CUDA Number of devices 1 Device Name NVS 4200M Device Vendor NVIDIA Corporation Device Vendor ID 0x10de Device Version OpenCL 1.1 CUDA Driver Version 390.116 Device OpenCL C Version OpenCL C 1.1 Device Type GPU Device Topology (NV) PCI-E, 01:00.0 Device Profile FULL_PROFILE Device Available Yes Compiler Available Yes Max compute units 1 Max clock frequency 1480MHz Compute Capability (NV) 2.1 Max work item dimensions 3 Max work item sizes 1024x1024x64 Max work group size 1024 Preferred work group size multiple 32 Warp size (NV) 32 Preferred / native vector sizes char 1 / 1 short 1 / 1 int 1 / 1 long 1 / 1 half 0 / 0 (n/a) float 1 / 1 double 1 / 1 (cl_khr_fp64) Half-precision Floating-point support (n/a) Single-precision Floating-point support (core) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Correctly-rounded divide and sqrt operations No Double-precision Floating-point support (cl_khr_fp64) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Address bits 64, Little-Endian Global memory size 474873856 (452.9MiB) Error Correction support No Max memory allocation 134217728 (128MiB) Unified memory for Host and Device No Integrated memory (NV) No Minimum alignment for any data type 128 bytes Alignment of base address 4096 bits (512 bytes) Global Memory cache type Read/Write Global Memory cache size 16384 (16KiB) Global Memory cache line size 128 bytes Image support Yes Max number of samplers per kernel 16 Max 2D image size 16384x16384 pixels Max 3D image size 2048x2048x2048 pixels Max number of read image args 128 Max number of write image args 8 Local memory type Local Local memory size 49152 (48KiB) Registers per block (NV) 32768 Max number of constant args 9 Max constant buffer size 65536 (64KiB) Max size of kernel argument 4352 (4.25KiB) Queue properties Out-of-order execution Yes Profiling Yes Profiling timer resolution 1000ns Execution capabilities Run OpenCL kernels Yes Run native kernels No Kernel execution timeout (NV) Yes Concurrent copy and kernel execution (NV) Yes Number of async copy engines 1 Device Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts cl_nv_create_buffer NULL platform behavior clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) NVIDIA CUDA clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) Success [NV] clCreateContext(NULL, ...) [default] Success [NV] clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) No platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) Invalid device type for platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) No platform ICD loader properties ICD loader Name OpenCL ICD Loader ICD loader Vendor OCL Icd free software ICD loader Version 2.2.11 ICD loader Profile OpenCL 2.1 From tnt at 246tnt.com Sat Dec 21 21:53:00 2019 From: tnt at 246tnt.com (Sylvain Munaut) Date: Sat, 21 Dec 2019 22:53:00 +0100 Subject: gr3.7-qt5 --> CL Error: Unable to queue clear of spectrum buffer In-Reply-To: References: Message-ID: Hi, > I attached the clinfo output about the version and capabilities of my hardware. Other than this, I am using the proprietary nvidia driver for linux (version 390) with kernel 4.15.0-62-generic, and gnuradio 3.7.13.5~gnuradio~bionic-4. Sure but you said you used fosphor previously on that machine. My question was about the versions you were using back then, not the ones you are running now. > I tried to find that commit you are referring to, but it seems it is no in the git log (or at least I cannot find it). Can you take a look if it is correct? Err sorry it's 306f197108d1a264bebea9f96ac22fa084d402fb Cheers, Sylvain From dchardware at gmail.com Mon Dec 23 12:07:05 2019 From: dchardware at gmail.com (Sipos Csaba) Date: Mon, 23 Dec 2019 13:07:05 +0100 Subject: gr3.7-qt5 --> CL Error: Unable to queue clear of spectrum buffer In-Reply-To: References: Message-ID: Hi Sylvain, I reverted to the version 340 nvidia (proprietary) driver, and now it works with the "gr3.7-qt5" branch and an rtl-sdr radio. I did not needed to revert anything on the gr-fosphor side. However with the XTRX it outputs nothing (starts up properly, no error messages whatsoever, device initialization seems to be fine). I attached the clinfo output of the working nvidia driver, you might be able to find something in it. The XTRX side of thing is likely something irrelevant to gr-fosphor, as they still not merged XTRX support to gr-osmosdr, I need to use their fairly old gr-osmosdr fork from 2017. The only question is where can I get a hold of them, as I was ot able to find a public forum, or mail list or anything in regards of XTRX... Non the less, thanks for the help, and if you find something driver-wise on the Nvidia/OpenCL side and want me to test something, I am happy to do it. Regards, Csaba Sylvain Munaut ezt ?rta (id?pont: 2019. dec. 21., Szo, 22:52): > Hi, > > > I attached the clinfo output about the version and capabilities of my > hardware. Other than this, I am using the proprietary nvidia driver for > linux (version 390) with kernel 4.15.0-62-generic, and gnuradio > 3.7.13.5~gnuradio~bionic-4. > > Sure but you said you used fosphor previously on that machine. My > question was about the versions you were using back then, not the ones > you are running now. > > > > I tried to find that commit you are referring to, but it seems it is no > in the git log (or at least I cannot find it). Can you take a look if it is > correct? > > Err sorry it's 306f197108d1a264bebea9f96ac22fa084d402fb > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Number of platforms 1 Platform Name NVIDIA CUDA Platform Vendor NVIDIA Corporation Platform Version OpenCL 1.1 CUDA 6.5.51 Platform Profile FULL_PROFILE Platform Extensions cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts Platform Extensions function suffix NV Platform Name NVIDIA CUDA Number of devices 1 Device Name NVS 4200M Device Vendor NVIDIA Corporation Device Vendor ID 0x10de Device Version OpenCL 1.1 CUDA Driver Version 340.107 Device OpenCL C Version OpenCL C 1.1 Device Type GPU Device Topology (NV) PCI-E, 01:00.0 Device Profile FULL_PROFILE Device Available Yes Compiler Available Yes Max compute units 1 Max clock frequency 1480MHz Compute Capability (NV) 2.1 Max work item dimensions 3 Max work item sizes 1024x1024x64 Max work group size 1024 Preferred work group size multiple 32 Warp size (NV) 32 Preferred / native vector sizes char 1 / 1 short 1 / 1 int 1 / 1 long 1 / 1 half 0 / 0 (n/a) float 1 / 1 double 1 / 1 (cl_khr_fp64) Half-precision Floating-point support (n/a) Single-precision Floating-point support (core) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Correctly-rounded divide and sqrt operations No Double-precision Floating-point support (cl_khr_fp64) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Address bits 32, Little-Endian Global memory size 536412160 (511.6MiB) Error Correction support No Max memory allocation 134217728 (128MiB) Unified memory for Host and Device No Integrated memory (NV) No Minimum alignment for any data type 128 bytes Alignment of base address 4096 bits (512 bytes) Global Memory cache type Read/Write Global Memory cache size 16384 (16KiB) Global Memory cache line size 128 bytes Image support Yes Max number of samplers per kernel 16 Max 2D image size 32768x32768 pixels Max 3D image size 2048x2048x2048 pixels Max number of read image args 128 Max number of write image args 8 Local memory type Local Local memory size 49152 (48KiB) Registers per block (NV) 32768 Max number of constant args 9 Max constant buffer size 65536 (64KiB) Max size of kernel argument 4352 (4.25KiB) Queue properties Out-of-order execution Yes Profiling Yes Profiling timer resolution 1000ns Execution capabilities Run OpenCL kernels Yes Run native kernels No Kernel execution timeout (NV) Yes Concurrent copy and kernel execution (NV) Yes Number of async copy engines 1 Device Extensions cl_khr_byte_addressable_store cl_khr_icd cl_khr_gl_sharing cl_nv_compiler_options cl_nv_device_attribute_query cl_nv_pragma_unroll cl_nv_copy_opts cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_fp64 NULL platform behavior clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) NVIDIA CUDA clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) Success [NV] clCreateContext(NULL, ...) [default] Success [NV] clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) No platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) No platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) Invalid device type for platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) No platform ICD loader properties ICD loader Name OpenCL ICD Loader ICD loader Vendor OCL Icd free software ICD loader Version 2.2.11 ICD loader Profile OpenCL 2.1 From dchardware at gmail.com Wed Dec 25 15:19:02 2019 From: dchardware at gmail.com (Sipos Csaba) Date: Wed, 25 Dec 2019 16:19:02 +0100 Subject: gr3.7-qt5 --> CL Error: Unable to queue clear of spectrum buffer In-Reply-To: References: Message-ID: Some extra info: It seems for this old card (9400M), Nvidia recommends driver 340 on their PPA. Of course, ubuntu recommends the wrong (390) version to be installed, and there is no alarm or anything during the process... Anyway, I think this is it: might need to switch to a newer card... XTRX with gr-fosphor also works, just needed to add an extra ARG to the command line: osmocom_fft -a xtrx -A RXW -s 4000000 -f 804000000 -F Thanks again for the help! Regards, Csaba Sipos Csaba ezt ?rta (id?pont: 2019. dec. 23., H, 13:07): > Hi Sylvain, > > I reverted to the version 340 nvidia (proprietary) driver, and now it > works with the "gr3.7-qt5" branch and an rtl-sdr radio. I did not needed to > revert anything on the gr-fosphor side. > > However with the XTRX it outputs nothing (starts up properly, no error > messages whatsoever, device initialization seems to be fine). > > I attached the clinfo output of the working nvidia driver, you might be > able to find something in it. The XTRX side of thing is likely something > irrelevant to gr-fosphor, as they still not merged XTRX support to > gr-osmosdr, I need to use their fairly old gr-osmosdr fork from 2017. The > only question is where can I get a hold of them, as I was ot able to find a > public forum, or mail list or anything in regards of XTRX... > > Non the less, thanks for the help, and if you find something driver-wise > on the Nvidia/OpenCL side and want me to test something, I am happy to do > it. > > Regards, > Csaba > > Sylvain Munaut ezt ?rta (id?pont: 2019. dec. 21., Szo, > 22:52): > >> Hi, >> >> > I attached the clinfo output about the version and capabilities of my >> hardware. Other than this, I am using the proprietary nvidia driver for >> linux (version 390) with kernel 4.15.0-62-generic, and gnuradio >> 3.7.13.5~gnuradio~bionic-4. >> >> Sure but you said you used fosphor previously on that machine. My >> question was about the versions you were using back then, not the ones >> you are running now. >> >> >> > I tried to find that commit you are referring to, but it seems it is no >> in the git log (or at least I cannot find it). Can you take a look if it is >> correct? >> >> Err sorry it's 306f197108d1a264bebea9f96ac22fa084d402fb >> >> Cheers, >> >> Sylvain >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chibill110 at gmail.com Thu Dec 26 17:41:22 2019 From: chibill110 at gmail.com (Bill Gaylord) Date: Thu, 26 Dec 2019 11:41:22 -0600 Subject: Request for Comment: Creating a binary format output for rtl_power Message-ID: Hello, I am working on making a binary format for rtl_power to save space on my server for observing the spectrum. I am wondering if anyone else would be interested in this idea. I am hoping keep the same format in terms of how the data is organized in the file but instead of using text use some form of binary format. For example for the date and time I think using a unix epoch timestamp would work. I am hoping to receive any comments or criticism. Thanks, KD9KCK -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Thu Dec 26 20:11:05 2019 From: gdt at lexort.com (Greg Troxel) Date: Thu, 26 Dec 2019 15:11:05 -0500 Subject: Request for Comment: Creating a binary format output for rtl_power In-Reply-To: (Bill Gaylord's message of "Thu, 26 Dec 2019 11:41:22 -0600") References: Message-ID: Bill Gaylord writes: > Hello, > > I am working on making a binary format for rtl_power to save space on > my server for observing the spectrum. I am wondering if anyone else would > be interested in this idea. > I am hoping keep the same format in terms of how the data is organized in > the file but instead of using text use some form of binary format. For > example for the date and time I think using a unix epoch timestamp would > work. > > I am hoping to receive any comments or criticism. My suggestions are: Think about whether you want the binary format to be portable. This means being more careful about types and also endianness. Post a draft file format for comments. With a binary format for an existing text format, it would be nice to have programs (pipes ideally) that convert text->binary and binary->text. For portability, I think the obvious answer is that the file format should be independent of CPU type, compiler, and specifically endiannesss. Thus you are writing a format that could be used over the network (even if it's only intended to be stored). This means you have to choose fixed-width types, and you have to store in a particular endianness. I am 99% sure that the network protocol standard is big endian, and I think you should follow that. I think there is precedent in things like sqlite. For pgsql I think so, but there is a culture of having to use pg_dump to change versions (and as a result pg_dump is 100% satisfactory; see my comment above about converters). I don't know about mysql. From abgoyal at gmail.com Fri Dec 27 14:41:31 2019 From: abgoyal at gmail.com (Abhishek Goyal) Date: Fri, 27 Dec 2019 20:11:31 +0530 Subject: Request for Comment: Creating a binary format output for rtl_power In-Reply-To: References: Message-ID: The design of such a format would depend on the end goal. You mentioned that you wanted to save space on your server. A streaming compression of the current textual format should work quite well, and even better if we do a sort of a preprocessing of it to "delta encode" the date: i.e, if a series if, say: [ 241, 234, 221, 201, 100, 43, 0, -10...], convert it to [ 241, -7, -13, -20, -101, -57, -43, -10...]. If the use only involves streaming access to data (i.e, process each entry and move on), the compression works really well, and most compression formats allow both, streaming while writing, and streaming while reading (meaning one won't need to fully decompress a file on the filesystem before using it); look at tools like zcat, zstdcat, etc. In practice you will find that [text format+ compression] will be fairly close to [binary format + compression] in final size. Compression obviously will reduce random access to data, so if your intended use involves seeking randomly around in the data, things get tricky. If the format is intended to be shared with other people, and/or manage large collections of such data, either use hdf5[1] or look into it for inspiration. If that sounds too complicated, then protobufs[2] might be another option. Both hdf5 and protobufs benefit from having readily available code for access to the data for later analysis, and from having hundreds of man-years of bugfixes and portability fixes behind them. Again, depending on the use case, another option might be to store the data in a sqlite[3] database file, its an underrated option for large amounts of data: here the binary conversion to and fro can be handled by the sqlite tools themselves, and you have access to the data in a fully random-access fashion. There are ways for sqlite to do online compression of data as well[4], incase you find the standard size reduction from going to binary isn't enough. Having dealt with custom binary formats for large amounts of data quite a bit, I tend to recommend against doing that if standard options can instead be used: there are a large number of pitfalls in going binary, both when writing the data, as well as when reading it back; Greg brought up endianness, then theres framing(indicating the start if each "row" of data, in case a few bytes got corrupted on disk, thus allowing the rest to still be recovered), versioning (if you change the data format, how do you have the reading code still remain able to read the older format), debugging (its very hard to be 100% sure that a binary data you intended to write, typically there will be no error messages from the code and no crashes - just wrong and misleading results due to miswritten/misread data), etc. Just my 0.02USD. -Abhishek [1]: https://www.neonscience.org/about-hdf5 [2]: https://github.com/protocolbuffers/protobuf [3]: https://www.sqlite.org/about.html ("Think of SQLite not as a replacement for Oracle but as a replacement for fopen()") [4]: https://sqlite.org/zipvfs/doc/trunk/www/readme.wiki On Fri, Dec 27, 2019 at 1:46 AM Greg Troxel wrote: > Bill Gaylord writes: > > > Hello, > > > > I am working on making a binary format for rtl_power to save space on > > my server for observing the spectrum. I am wondering if anyone else would > > be interested in this idea. > > I am hoping keep the same format in terms of how the data is organized in > > the file but instead of using text use some form of binary format. For > > example for the date and time I think using a unix epoch timestamp would > > work. > > > > I am hoping to receive any comments or criticism. > > My suggestions are: > > Think about whether you want the binary format to be portable. This > means being more careful about types and also endianness. > > Post a draft file format for comments. > > With a binary format for an existing text format, it would be nice to > have programs (pipes ideally) that convert text->binary and > binary->text. > > > For portability, I think the obvious answer is that the file format > should be independent of CPU type, compiler, and specifically > endiannesss. Thus you are writing a format that could be used over > the network (even if it's only intended to be stored). This means you > have to choose fixed-width types, and you have to store in a particular > endianness. I am 99% sure that the network protocol standard is big > endian, and I think you should follow that. I think there is precedent > in things like sqlite. For pgsql I think so, but there is a culture of > having to use pg_dump to change versions (and as a result pg_dump is > 100% satisfactory; see my comment above about converters). I don't know > about mysql. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Fri Dec 27 14:50:03 2019 From: gdt at lexort.com (Greg Troxel) Date: Fri, 27 Dec 2019 09:50:03 -0500 Subject: Request for Comment: Creating a binary format output for rtl_power In-Reply-To: (Abhishek Goyal's message of "Fri, 27 Dec 2019 20:11:31 +0530") References: Message-ID: Abhishek Goyal writes: > Having dealt with custom binary formats for large amounts of data quite a > bit, I tend to recommend against doing that if standard options can instead > be used: there are a large number of pitfalls in going binary, both when > writing the data, as well as when reading it back; A message full of excellent points. I failed to think of hdf5/protobuf and all the rest of the great suggestions. So I will second the notion that a custom binary format is very likely not a good idea. From abhigyan17 at gmail.com Sun Dec 1 18:46:04 2019 From: abhigyan17 at gmail.com (Abhishek sharma) Date: Sun, 01 Dec 2019 18:46:04 -0000 Subject: FL2k error Buffer Message-ID: Hello Team, This is Abhishek Sharma a infosec researcher from India. It was stange that I was getting an error constantly i.e. "no free transfer, skipping input buffer" even though I setup the sample rate to minimum but still getting the same error. IT WOULD BE GREAT IF YOU CAN HELP IN RESOLVING THIS ISSUE Waiting for your response Below is the screen grab for reference: [image: image.png] -- Thanks Regards Abhishek Sharma Mobile: (+91) 9458406845 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 100299 bytes Desc: not available URL: