> I agree, when the system is treated as a > monolithic black-box it is the only way one CAN address the problem > (which means that, for most of us this is the only way to deal with > the problem). OTOH, there are people with the tools to allow us to see > inside the black-box. >
I couldn't agree more. The problem, however, is that there is not a group of people who, when taken together: a) Have the necessary domain-specific knowledge to solve the problem b) Have the time or inclination to solve it c) Can solve the problem for the general case, such that it will work on everybody's system... irrespective of the types of devices, drivers, and CPUs they're running. > I would give large odds that the problem is one of some high-priority > task stealing lots of cycles on a periodic basis or a scheduling issue > between the threads of PowerSDR, VAC, and whatever other digital mode > program one is running. Well, using the term "task" loosely, what you obviously must be correct: SOMEthing isn't getting to run when it needs to, and thus SOMEthing is getting discarded, overflowing, or otherwise buggering things up. If Flex called ME and asked me (given that I know something about Windows OS and I/O subsystem architecture) to help fix this problem, here's what I'd do: a) Sit down with the people who understand signal processing in PowerSDR and ask them what latency requirements they have, even an approximation would help. Try to find out how data moves through the system, and under what loads and conditions. Cuz, when it comes to signal processing, I know less than nothing. b) Pick ONE SYSTEM... with a specific set of peripherals and drivers and hold that constant. c) Take the necessary measurements to find the problem. Assuming you can find a suitable set of configuration parameters, publish the system information as THE "Reference System." Cuz, if Flex could say "Go out and buy a Dell XYZ, set it up with these parameters and you'll be happy" I bet that's what a lot of people would do. I know *I* would. The only caveat is, given that reference system, neither the peripherals nor the software nor even the specific versions of the drivers on that system can change without the risk of significantly changing the system's behavior. I've solved problems like this in the past. Without getting into war stories, I worked with a client once who had an imaging device that could tolerate no more than 1ms latency. That, folks, is a LOT of latency. However, their device (controlled by a complex embedded Windows system) when working in production environments (not their lab, unfortunately) encountered a problem about once a day, always at a different time. Turned out, the problem was caused by combined interrupt and DPC latency created by a combination of their net card and the IDE controller handling a paging operation. In other words, it had nothing to do with their device or any of their image processing threads. We locked (pinned) their code in memory (making it non-pagable) and... the problem was solved. de Peter K1PGV _______________________________________________ FlexRadio Systems Mailing List FlexRadio@flex-radio.biz http://mail.flex-radio.biz/mailman/listinfo/flexradio_flex-radio.biz Archives: http://www.mail-archive.com/flexradio%40flex-radio.biz/ Knowledge Base: http://kb.flex-radio.com/ Homepage: http://www.flex-radio.com/
