In the context of multimedia Quality of Service (QoS), the term "crosstalk" refers to the undesirable effects of one process on another due to their interactions via a shared resource.
Processing time
For a simple example, imagine we have a video player (say, VLC, mplayer, RealPlayer, WinDVD etc) running on our desktop computer. If the video player needs 60% of our computer's processing time to render every single frame and avoid dropping any, we don't have a lot of spare processing time. Typically, if we were to start another application or process which would demand processing time, the operating system would allocate 50% of the computer's time to each process.
If this happens, our video player needs 60% of the computer's processing time, but only gets 50%. The result, if the player's error recovery is ideal, is that we end up losing 1 out of every 6 frames of the video. This represents a massive degradation in the quality of the video playback, possibly enough to make the video unwatchable. While incredibly annoying at the best of times, it's even more annoying if, as is so often the case, the other 50% of our computer's processing time is being used by a Flash advert on a web page we happened to browse to.
This interference between processes is what's known as crosstalk.
There are ways round this sort of problem: install AdBlock, or buy a faster computer which only needs 50% of its processing power to show your video. The real solution, unfortunately, is for operating systems to be more aware of QoS issues. Nemesis attempted to address some of these issues, most notably the processing time issue, but was unsuccessful as a general purpose operating system for other reasons.
In this specific example, the shared resource which constitutes the "communication channel" between the processes, is processing time, but other shared resources within the computer are also subject to crosstalk.
Network
As described on Quality of Service, one of the focal points for QoS work is in network support for multimedia. Indeed it seems that the term QoS is perceived as having no meaning other than QoS on TCP.
Crosstalk caused by competition for network bandwidth is particularly unpredictable since more than one computer (and hence more than one operating system) can compete for the bandwidth, and hence media players on entirely different computers can interfere with each other.
Physical memory
Memory is a significant source of crosstalk for many workloads. Modern operating systems can make good use of almost as much memory as you can cram into the machines: If it's not directly used by a process, it can be used by the operating system to cache commonly used disk files, so that they needn't be brought in from disk each time they're used. In either case, having physical memory avoids the need for disk access (either a major page fault, or a simple file access), and since available memory is divided between processes by the operating system, physical memory forms another channel for crosstalk between processes.
Imagine a video or audio player, playing a very long movie over a bandwidth limited connection. What will likely happen in this case, as you've probably seen happen in your web browser, is that the player will pause playing, and continue downloading the movie, buffering it in memory until there is enough to play without dropping frames.
If the movie is long enough, the amount of memory required to buffer it will become significant. If other processes are also demanding memory, the operating system may swap part of the buffer out to disk (unless the process has requested that its buffer be wired into physical memory; this would create problems for other programs and the operating system, however, if the buffer is large). Servicing page faults and recalling this data back into physical memory can introduce a significant time delay in the actual playback of the video when it's finished downloading, enough to make the playback judder or drop frames.
This has more effect in general purpose applications that multimedia ones: the video buffering example is somewhat contrived in that it requires an exceedingly large playback buffer to exhibit crosstalk effects.
Due to the nature of desktop computing, filesystem cache can be just as important as virtual memory in determining performance. Indeed, in recent versions of Linux, the operating system can be told to treat the two classes of memory usage as identical via the swappiness setting. Because of this, background processes which access a lot of disk data can push useful bits of desktop processes (or files used by them) out of physical memory, and hence interfere with the performance of a users' interactive desktop. This is harder to quantify and analyse than with simple linear streaming media, but is just as significant. I've recently dealt with friends complaining about systems being slow due to this sort of crosstalk issue: Norton Antivirus, Limewire, ZoneAlarm all have disk-intensive processes which interfere with desktop activity, to a degree which has caused an entirely unacceptable degradation of performance. My workstation at university takes a couple of minutes to pull itself together after the night's rsync jobs.
Disk activity
As well as the issues mentioned above, disk activity has its own associated crosstalk effects.
Hard disks can achieve quite high data rates for transferring data in continuous bursts, to sequential disk addresses. But they take large amounts of time to seek between non-sequential disk addresses, since this usually involves a great deal of physical movement of the disk head actuator. Thus, when two concurrent processes are transferring data, rather than each process managing to transfer at 50% of its peak transfer rate, it may be significantly less since the operating system and disk subsystem will intersperse their disk transactions, so the disk system may easily spend most of its time moving the head between the two processes' data areas.
Optical disks such as DVDs and CD-ROMs are even worse, because their seek times are far greater. Not only do they have to move and potentially refocus their laser read/write heads, but they also have to change the speed of rotation of the disk since they employ constant linear velocity data storage.
Interprocess Communication
Where independent processes communicate with a third process, say an X-Windows server, a Mac OS X WindowServer, a filesystem server process, or something similar, that process itself can form a channel for crosstalk between the applications. If I'm watching a video in X-Windows, and I have an xterm showing the output from a lengthy process such as an rsync, I might run the xterm and its process via nice in the hope of ensuring it doesn't interfere with my video.
However, both the video and the terminal emulator rely on the X server to do much of their work for them: the xterm process needs it to render lot of characters, and the video player needs it to render the frames of video. Because the X server runs with a fixed process priority, it doesn't distinguish between work done on behalf of the xterm and work done on behalf of the video player. Boom! Crosstalk, and the possibility for degradation in the QoS of my video playback experience.
Cache crosstalk
Crosstalk due to processor cache memory is a subtle effect. It's closely related to processing time. If we measure a given application, say a video player again, on a quiescent system, and determine that it needs to run for 60% of the available processing time, in a sensible operating system we can allocate that process 60% of the processing time to that application. Problem solved?
Not quite. To perform the processing required to play the video, the video player application will make use of the processor's caches. When the application has finished rendering a frame (using only 60% of the time for which that frame will be displayed), the operating system may allow another process to run. In fact, it may even have interrupted the video player to allow another process to run, so long as it knows that it will then be able to interrupt the new process to allow the video player to complete its frame in time.
This other process will, doubtless, make some use of the processors' caches, causing cache lines of the video player's working set to be evicted from the cache to make room for its own.
Thus when the video player is resumed, it will have to fetch parts of its working set from main memory, taking perhaps hundreds of cycles for each cache line. Hence the video player will have been able to do less work in the same amount of time. On the quiescent system, no other process will have been running while the video player was "resting" (except perhaps the system's idle loop), and hence its working set would still be resident in the cache.
Let's make things better
Crosstalk is bad, and our desktop operating systems are not good at dealing with it. Nemesis mitigates most of these sources of crosstalk, with its vertically structured application environment, ATM networking support, and QoS processor scheduling. BeOS handles streaming media from disk without going via the filesystem cache, thus avoiding one tiny little problem (the one of playing long movies causing the rest of the operating system's filesystem cache to be invalidated).
So, what's to be done? Existing operating systems can fairly easily be modified to reduce crosstalk via physical memory. Interprocess communication crosstalk generally requires systems to be rearchitected to avoid the single interaction point, or requires the interaction point process to be rearchitected to allow prioritised servicing of requests. Processor time crosstalk is almost a faut accompli in most operating system kernels thanks to simple priority and real-time schedulers, but in desktop operating environments very little use is made of these. Monolithic applications such as web browsers also destroy the opportunity for using these scheduling methods effectively.