On Thu, Mar 19, 2009 at 7:06 PM, Trent Piepho <xyzzy@xxxxxxxxxxxxx> wrote: >> The argument being put forth is based on the relative efficiency of >> the multiply versus divide opcodes on modern CPU architectures?? And > > Maybe I just like writing efficient code to do interesting things? Wow, um, ok. You realize that getting the SNR on most devices is probably going to require an i2c call that is going to take a couple hundred CPU instructions, not to mention I/O, right? And that you're doing this in an expensive ioctl call? So perhaps a micro-optimization with no visible gain, at the cost of readability and complexity shouldn't be a overriding consideration? >> that you're going to be able to get an SNR with a higher level of >> precision than 0.1 dB?? (if the hardware suggests that it can then >> it's LYING to you) > > Not really. Absolute accuracy is not going to be that good of course. But > the error measurements from which SNR is calculated do support precision of > better than 0.1 dB. That precision does give you more power when fine > tuning antenna position. > > Put another way, what advantage is there of less precision? Well, here is one disadvantage: The driver decides the SNR is 23.1. So I convert that to your format: 0x1719. Then userland gets it back and goes to display it. I'm going to show the user an SNR of 23.09765625, and I have no way to know what the expected precision (and thus I don't know where to round). So the end result is the user sees a really stupid number in the GUI (and might actually think it is more accurate than it really is). Or when I push patches to applications I just round to 0.1dB anyway. It also means apps like femon and zap are going to have to change to support a non-fixed width result with no appreciable gain in value. By saying explicitly there is one digit of precision - it allows for applications to know how to round, and I continue to disagree with your assertion that you will get any better accuracy with that anyway. We could *in theory* provide a separate ioctl so the driver can know what the expected precision is, but I do not believe it is worthwhile to over-engineer the interface. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
