Read some suggestions for problemsolving on planetZ relating the adjustment of PCI latency timer in BIOS. Apparently this can help solve overloaded PCI-busses, and it also seems to work.
I was wondering though ; My motherboard has PCI-LatencyTimer adjustable from 64 - 248. Tips regarding problemsolving usually involve adjusting it from default 64 to maybe 128 or so. Is there any reason not to set the maximum latency possible. What's the "catch" on OS performance (XP Pro) ? What is the "intended" use of this parameter?
I've been fiddling on a Intel 850 chipset with the Chipset PCI latency and the per-card latency timers, but never found any reason to set them to another value than the default one (32 or 64). I've been testing PCI throughput with the Masterverb test (I think that was an idea of Subhuman) and was always able to load 11 MV's on my double Pulsar2, no matter how high I would set the timers, so I stopped fidding with the timers. Maybe they do have effect in relation to other PCI devices, but I have none.
To answer my own post, after some research and in case someone else was interested...
I read that PCI latency timer setting is the guaranteed time that a PCI-device can have exclusive access to the PCI bus, via bus-maastering. During this time period no other device can cut in and interrupt, as is usually done as devices share processor-time controlled by the systemclock (interrupts). They still share, only they have bigger shares
This would appear to explain why this setting might not increase a systems performance in anyway (read above post) , but rather just eliminate some problems arising from early interruption by the system clock. Symptoms of such interruption could be clicks and strange error messages, yes?
So the highest PCI setting would get you the best PCI performance, right? What about *fastest*? What's the best setting for low-latency audio? I'm currently at 256.
One specific "problem" that changing PCI latency solved on my system:
When playing CW synths via external MIDI keyboard ( MIDIsport 4x4, USB ( i.e PCI ) ) moving a controller for say modulation or volume quickly would send more MIDI-messages than ScopeCard could handle ( or PCI-bus rather ), and so audio from synths would crackle and pop while controller was moved fast. Raising PCI latency to 248 removed this "problem".
So apparently too frequent interrupting ( low PCI-latency setting) of a ScopeCard in the midst of heavy data-flow, can cause problems. Maybe this only applies to "border-line" performance systems though. I have a PIII 666MHz running 100MHz PCI-bus, so it's not exactly the latest in computer-wares!
From what I've learned ; When the ScopeCard get's it's "turn" to use the CPU for specified amount of guaranteed time (ms or cycles don't know), this is the only time that SFP-software can actually communicate with SFP-hardware. When the time is up, interrupt controller on motherboard passes the bus-control over to some other hardware. SFP-sw probably stores the info it has recieved in this time. Maybe sometimes SFP-hw buffer fills up before next time comes to flush it through bus to SFP-sw though = click snap crackle pop.
<font size=-1>[ This Message was edited by: zoofar on 2003-06-02 13:41 ]</font>
so, it's better high or low latency timer?
on my asus cusl2C i have it at 32 nd never changed it.
the maximum masterverb i can load is 5 (but i never use more than 2, normally). i never had PCI overflows, but i cannot get VST latency of 7 ms without crackles
Garyb is right, latency for the Pulsar board is best set to high, but keep in mind that the whole operation is pretty useless when no devices exist on the PCI bus that are capable of interrupting the Pulsar PCI-time-slot. In my case: I have no other PCI devices and no chipset-attached devices (USB, onboard LAN etc.) that can cause an interrupt of the time-slot. As for the chipset attached devices: read the chipset datasheet to understand what busses exist, and if they share bandwidth with the PCI bus or not. e.g. boards with intel 850 chipsets and USB2 option: the USB2 chips share the PCI-bus as USB2 is not integrated in the 850. On the other hand, the onboard LAN option in most 850 implementations does not interfere on the PCI-bus - they reside on a different (internal) bus.
Hmm, not sure my rambling will actually help someone
Better stop then.
Cheers!