Hey Zefir, On Wed, Jan 16, 2013 at 05:00:09PM +0100, Zefir Kurtisi wrote: > [...] > >> > >> Maybe you have a host application in mind where it does not really matter where > >> the processing is done. Whereas, if you operate an AP as continuous spectral > >> scanner, shifting the post-processing to the point where it is evaluated / > >> displayed (usually your fat PC) significantly impacts your AP's load and its > >> capability to provide higher sampling rates. > > > > I didn't see any performance limits yet. Shifting the data is probably not so expensive > > (what we do right now in the kernel), but doubled sample size and other aspects > > will certainly have an impact for this kind of "streaming" application for (low-end) APs. > > > Right now, with a 500MHz ARM SoC I am limited to ~12k-samples/s with resources > fully utilized. That's far from the 250kS/s the chip could theoretically provide. > But I'm still with my netlink based interface and need to check if relay-fs is > more efficient. Well, give it a try. My application is not requiring maximum output, but I've changed to relayfs because it was suggested for performance reasons. Let's hope it can keep this promise. :) > [...] > > In any case, I don't want to change the format multiple times again, so let's discuss and > > fix it once and for all[tm] now. There are some parties already experimenting with and integrating > > this feature now. And if I'm not mistaken we have ~3 weeks left to add changes for > > the next kernel version. > > > Beside the required modifications being trivial, since the user space > post-processing is mandatory - could a library for data conversion help to > decouple driver from test development? > Might be a good thing, although I don't plan to write this now - The fft_eval program is good enough for a reference right now. A library could handle both FreeBSD and Linux in the future. Feel free to contribute. ;) > > My suggestions for the new format: > > * fix length bugs (as you said) > > * use a TLV format to hand out samples (as done now) - we can use a new type > > * each "sample packet" holds one sample, i.e. aggregated sample packets from the chip (we are not processing > > them in the current version, but in later versions maybe) are split into multiple "sample packets" > What are your plans for aggregation here, given that you need to convert the data > won't (easily) work in the kernel? I haven't seen the aggregated spectral reports myself yet, only seen comments from Adrian. http://article.gmane.org/gmane.linux.kernel.wireless.general/102030 The plan would be to split them so userspace always gets one sample per TLV, and we don't have to create yet another format. So we would have two types: HT20 report and HT40 report that userspace can support. But we are not handling them now anyway, just to have the format somewhat future proof. :) > > * the bins are not shifted (8 bit per bin) > > * auxiliary information which is larger than 8 bit (tsf, frequency, etc) is converted into network byte order > > > > Anything else? > > > With the rssi and noise-floor values already included: no, looks complete. OK, if no one else objects or has further comments I can provide patches for this one. Cheers, Simon
Attachment:
signature.asc
Description: Digital signature
