Moving from one OS to another won't necessarily make it better, but it will be almost certainly different.
DPCs are a Windows thing - it refers to how hardware interrupts are handled, and what processing is done "in real time" when an interrupt happens versus done later (deferred) when the O/S gets around to it. However, I think all OSes have a mechanism analogous to DPCs. So the problems associated with DPCs can happen in any OS. "Device drivers" are usually pieces of software with 2 components. One runs asap when the hardware interrupt triggers it, and how quickly it runs depends on things like bus contention, IRQ sharing, etc. OSes can't do much about that, it's associated with the specific hardware. When the device driver runs, what it is allowed to do, and what it is recommended to do, is determined by the O/S architecture - e.g., how the O/S prioritizes processes, what "hooks" it provides to drivers, the algorithms the scheduler uses, etc. Generally, you want that first piece of code that runs on interrupt to do only the absolute minimum that is needed to happen right away, such as reading data from a hardware buffer before it gets overwritten by the next incoming data. While this software runs, nothing else can run, except maybe a "higher priority" hardware device. All other processing should be "deferred", to be run when the O/S scheduler decides it's time. Problems occur when things don't happen as soon as they need to. Input data gets dropped, buffers overflow, etc. How bad that is, on identical hardware, depends on how well the O/S juggles competing priorities, as well as on how well the people writing device drivers follow the rules. If a particular driver spends too much time when it has control of the CPU, other drivers lose out. Different people write drivers for Windows, Mac, Linux, etc., or at least there are different versions, because the environment provided by the OS is different. So the behavior will be different, on the same hardware, depending on the OS used. Some programmers are more skilled than others. Writing good device drivers is an art, and a difficult one at that. Writing simple device drivers, that work for your device but can cause all sorts of problems for others, is much easier, and it gets the product out the door faster. Linux gets used in a lot of lab environments, real time data acquisition, etc., so those kinds of drivers are likely well tuned. Windows gets used in a lot of home and office environments, with multimedia, graphics, etc, so those kinds of drivers are likely well tuned. Changing OSes probably won't solve all problems, but it will make a difference. 73, /Jack On Tue, 2010-11-16 at 10:56 -0800, Brian Lloyd wrote: > On Tue, Nov 16, 2010 at 10:37 AM, Frank Goenninger <[email protected]> wrote: > > > Am 16.11.2010 um 19:32 schrieb Brian Lloyd: > > > > > On Tue, Nov 16, 2010 at 10:26 AM, Jack Haverty <[email protected]> wrote: > > > > > >> I use Debian, which I think is still the same genetic code as Ubuntu. > > >> Debian has lots of 1394 software, for disks, video devices, etc. None > > >> of my Linux machines have a 1394 card, but that's easy to fix. But if > > >> "driver" means the code that connects dttsp to the kernel 1394 device > > >> and knows the Flex language used on that device, it's quite possible > > >> that hasn't been written. But I think the kernel drivers are there. > > >> > > >> I agree -- if anyone knows otherwise... > > >> > > > > > > Has anyone considered the possibility that the kinds of DPC latency > > problems > > > (which seem to be hardware related) might apply in Linux and other OS's > > when > > > run on the same PC hardware? > > > > Well, my experience is that you just don't have latency problems at the > > speeds (192kHz) FRS is using as a maximum. Iff you connect two or more FRS > > devices then the Mac Mini might get in trouble. That's what I see from using > > multiple professional sound interfaces and sequencer software on it - all > > running in OS X of course. Windows presents problems others simply haven't. > > > > I have had the same experience with Apple and sound devices. (Apple has > spent a lot of time making sure that FireWire devices work well with > MacOS.) > > Still, I was referring to generic PC hardware mostly running Linux. There > seem to be a lot of people assuming that just moving the Linux from Windows > will solve all the problems and I am not sure that will be the case. The > hardware that induces DPC latency problems still exist on that hardware > regardless of the OS running on top of it. > > Don't get me wrong, I would love to move to a different software platform. > Most of my stuff is MacOS but I would much prefer even Linux over Windows. > Still, I don't want people to just assume that changing OS's will solve all > the problems, especially those that are down at the hardware level. > > _______________________________________________ Flexedge mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used for posting topics related to SDR software development and experimentalist who are using beta versions of the software.
