Scritch, scratch

re: Scritch, scratch

Luciano — Wed, 31 Oct 2007 12:44:21 GMT

Are you kidding? A mulitcore cpu CAN'T do what a 486 was doing flawlessy?

re: Scritch, scratch

dcook — Thu, 01 Nov 2007 00:33:10 GMT

Like I said before, this has nothing to do with processor speed, cores, or scheduling. It has to do with motherboard chipsets, drivers, and latency. The 486 didn't have the aggressive power saving modes that modern CPUs have.

If you have a system with a good chipset and good drivers, you'll be fine with any modern CPU (100 MHz or higher). If you have a driver that takes too long to do its thing, it doesn't matter how fast your CPU is -- the driver still takes too long.

re: Scritch, scratch

Wesley — Fri, 02 Nov 2007 00:44:02 GMT

I am actually writing about your comment on Ben's site re serial ports. I am not sure what you need to do with your ports and maybe you already understand the following, however VBScript can be used to configure your ports on the fly. While the following sample is written with VS in mind, Ben's blog shows how you can set up a VPC to respond to VBScript. I use the script to assign a port and cpu resources to the current window. The source for the following is from his book.

Option Explicit

CONST vmSerialPort_HostPort = 0

CONST vmSerialPort_TextFile = 1

CONST vmSerialPort_NamedPipe = 2

CONST vmSerialPort_Null = 3

dim vs, vm, serialPort, aSerialPort, savedParameter, ParameterFile, objFSO, objTextStream

'10 Check that the script is running at the command line.

If UCase(Right(Wscript.FullName, 11)) = "WSCRIPT.EXE" Then

Wscript.Echo "This script must be run under CScript."

Wscript.Quit

End If

On Error Resume Next

'17 Attempt to connect to Virtual Server

Set vs = CreateObject("VirtualServer.Application")

If Err.number <> 0 Then

Wscript.Echo "Unable to connect to Virtual Server."

Wscript.Quit

End if

On Error Goto 0

'25 Read data from previously saved parameter file

ParameterFile="VMCadd.dat"

'29 Open requested parameter file

Set objFSO = CreateObject("scripting.filesystemobject")

Set objTextStream = objFSO.OpenTextFile(ParameterFile, 1, True)

savedParameter = objTextStream.ReadLine

objTextStream.close

'35 TURN OFF CADD03 PORT

set vm = vs.FindVirtualMachine("Cadd03")

'39 Set CPU resource allocations

vm.Accountant.SetSchedulingParameters 0, 100, 75

'42 Configure the first serial port to connect to a null port, 1st'x to initilize tablet

set aSerialPort = vm.serialPorts.item(1)

aSerialPort.configure vmSerialPort_Null, "Com1", false

'48 TURN OFF CADD04 PORT

set vm = vs.FindVirtualMachine("Cadd04")

'52 Set CPU resource allocations

vm.Accountant.SetSchedulingParameters 0, 100, 75

'55 Configure the first serial port to connect to a null port

set aSerialPort = vm.serialPorts.item(1)

aSerialPort.configure vmSerialPort_Null, "Com1", false

'61 TURN OFF CADD05 PORT

set vm = vs.FindVirtualMachine("Cadd05")

'65 Set CPU resource allocations

vm.Accountant.SetSchedulingParameters 0, 100, 75

'68 Configure the first serial port to connect to a null port

set aSerialPort = vm.serialPorts.item(1)

aSerialPort.configure vmSerialPort_Null, "Com1", false

'74 TURN ON PORT in Parameter data file

set vm = vs.FindVirtualMachine(savedParameter)

'78 Set CPU resource allocations

vm.Accountant.SetSchedulingParameters 0, 100, 1000

'81 Configure the first serial port to connect to a physical serial port

set aSerialPort = vm.serialPorts.item(1)

aSerialPort.configure vmSerialPort_HostPort, "Com1", true

re: Scritch, scratch

dcook — Fri, 02 Nov 2007 02:38:25 GMT

Wesley -

Thanks. That's cool. Unfortunately, it doesn't help much. I need to be able to have programs on my host machine talk over the serial port to programs on my guest machines. I can do this once by connecting a null modem cable from COM1 to COM2, assigning one of the Virtual PC COM ports to physical COM1, and attaching the program on my host machine to COM2. But now I'm out of physical COM ports, so this doesn't work when I need to use two COM ports at once or when I need to talk to multiple guest machines. The programs I need to use don't work with named pipes.

One program I've been looking at is an open source driver called com0com. That might work.

re: Scritch, scratch

Peter Kirn — Sat, 03 Nov 2007 18:56:58 GMT

I have to disagree here. A choice between lower latency and "glitch-free" performance is an artificial one. You ought to be able to have both. In fact, there are plenty of scenarios (ASIO drivers, for one, and some of the other examples people give here) where you got lower latency but more reliable performance ** on XP **.

So don't blame lower latency for Vista's glitch problems. I think the issue is, we're not really seeing the improvements promised by other enhancements like the scheduling stuff, and we're having to fight a bunch of unreliable, buggy drivers. We really need a commitment from Microsoft to get better audio performance.

I think in the end, you'll wind up with something that makes everyone happier. There are going to be more and more media-rich applications that want BOTH low-latency performance AND reliable, glitch-free playback, from communications to audio and music to richer sound in games.

Anyway, fwiw, I'm very pleased with my performance on Vista -- provided I use Winamp, not WMP for playback, and thanks to better drivers than I had a few months ago (particularly NVIDIA video drivers)

re: Scritch, scratch

dcook — Sat, 10 Nov 2007 03:58:38 GMT

Again, just to clarify -

The audio stack on Vista is designed to have lower latency than the default audio stack of XP. As a consequence, drivers that lock up the system are more likely to cause audible glitches than they were on XP.

If everything is working as it should be, you can get low latency on either XP or Vista. The ASIO drivers are a good example of this. As long as your other drivers are cooperating, you can get glitch-free audio with low latency on any modern OS.

On the other hand, if your driver goes out to lunch for longer than your audio stack can tolerate, it doesn't matter what the OS or the scheduler does. Your audio is going to glitch. The lower the latency, the less time the driver has to keep the system locked before it becomes a problem.

This isn't a problem with Vista's scheduler or lack of improvements there. IRQ handlers simply aren't scheduled. They trump everything except other IRQ handlers. When the IRQ comes in, the handler immediately runs until it returns or is interrupted by a higher priority IRQ. If it takes a long time to return, you've got a problem.

An XP machine with poorly written drivers will not be able to play low-latency audio glitch-free, regardless of the CPU speed. Same with Vista. Same with Linux. There's nothing the OS can do about it.

An XP machine with good drivers will be able to play low-latency audio glitch-free (as long as the CPU is up to the task of decoding the audio). Same with Vista. Same with Linux.

The main difference with Vista is that the latency is lower by default, so the "poorly-written drivers" become more obvious. Driver behavior that wasn't a problem with XP's default audio stack is now a serious problem with Vista's default audio stack. However, the behavior that causes a problem with Vista's audio stack would also cause a problem with a low-latency XP audio stack.

There are some things that Microsoft could do. Microsoft could provide a way to increase the latency of their audio stack to reduce the impact of poorly-written drivers. Microsoft could provide their own implementation of the poorly written drivers. Microsoft could pressure the vendor to improve their poorly written drivers. But I'm not sure how it would help to have a commitment from Microsoft to get better audio performance. The Microsoft part of the equation really isn't the problem

re: Scritch, scratch

Roger Barrett — Sat, 26 Jan 2008 17:16:27 GMT

It is, as dcrook says, largely a matter of process priorities, and all modern OS implementations have to make choices about how they schedule tasks (which includes IRQ handlers). The real problem that OS implementations tend to have is that they are "one size fits all" solutions trying to do their best for everyone, and often not succeeding.

Windows, in particular, has almost no ability to be tailored to what it's purchaser wants. For certain machines dedicated to particular tasks, maybe 80-90% of Windows code base is just a wasteful resource hog, but you simply don't have the control to get rid of it. With a lot of effort, you can probably find out how to disable a lot of pointless processes, and maybe also disable hardware/drivers that cause interference, but it is certainly not made easy to have Windows behave the way you might want it.

A better solution for low latency than Vista is the one adopted by the Linux kernel when compiled with real time support. Even with bad drivers, you can modify the priority of the different IRQs and processes/applications to whatever you want. This means you can, for example, set the priority of the IRQ for audio hardware, plus the priority of other audio processes and applications above everything else in the system to get sub-millisecond latency. Of course, you still need to ensure that any process with high priority is coded in a real-time aware manner (doesn't hog the processor), but at least the oprions to configure the OS are there; Windows developers could learn from that.