nam ng

Very much so, when you OC'ed the FSB, the PCI bus get the same speed up until multiples of PCI divider is reached, at which point PCI bus clock reverting back to 33Mhz. Main goal is holding PCI bus to 5% up to 10% overclock, in which case won't affect any newer IDE drive devices in use, above 10% very few IDE drives can cut the mustard for long term use. If you've SCSI drives the overcloking range can be much greater, as newer SCSI devices are using internal clocks rather than the reference clock from the PCI bus. Most internal onboard controllers are also affected by the FSB clock. Reason why nFORCE architecture do not suffer the same problem

Overclock your PCI bus to increase data throughput. Adjust PCI latency values within BIOS setting, the numerical increase/decrease should be in steps of 16, as that is the minimum cycles for servicing 16 IRQs. Adjusting BIOS latency value is very much similar to MTU values for network connection. Higher values increase data throughput from less overhead at a slight increase of latency response per connection. Other methods within BIOS --> Disable all un-used IRQs to reduce IRQ service cycle time, remove any and all wait time settings for IRQ services, your system is only as fast as the slowest device having control of your system. Do not disable ACPI if possible, as window will assign un-used IRQ resources dynamically to devices in need.

Any here currently using a MOBO with SIS735?

Quote: Hmm...I only get that thing about PCI latency with my duallie rig, not my A7V though, and both are Via chipsets. That my friend is because the extra CPU required an extra permanent load of system bandwidth, IE longer average IRQ response time than single CPU system. The funny thing most experts never realized --> extreme care, highly optimized memory management of various OSs are HACKS, due to inefficient underlay X86 hardware architecture, only one thing at a time in turns takes system control needing huge/deep stacks, or even large swap-out operations sucking up more of needed system bandwidth. SIS735 or nFORCE motherboard support Distributed Processing hardware, allowing point to point simultaneous memory access to all devices at the same time. This not only leveraging all available system bandwidth, but also doing away with most needs to swap-out whole processes/tasks reducing even more wasted loading of system bandwidth. The bandwith efficiency for Distributed Processing hardware depending purely on how much, how far the motherboard, various other hardware components and the OS will go with their implemented supports.

That's the problem SnowHawk, any and/or each one of them can cause the problem. Traditional X86 architechture is very inefficient, everything dependant on "grants" to bus-master devices, one device has a problem then all of them do, one device affects the response, throughput of all others including your CPU, a simplified example... There're 16 IRQ with ordered priorities, assuming worst case response time for 16 IRQs, each with equivalent lock-out service time of 64 cycles at 66MHz, ~1ms per IRQ... 16ms worstcase response to an IRQ. Many things are time sensitive (latency sensitive) such as sound, CD burners became very, very touchy. 32bit device at 33MHz and 32 cycles transfer 3KB per IRQ sevice request. How many seconds worth of sound data is that? Can it be sufficient enough not causing data starvation for 16ms? Which is the source of "snaps", crackles", and "pops", as for CD burners when that happened you get frizbees. Attemp to improve data transfer efficiency by increasing latency values caused worst response time... IE, lock-ups. Remember if you ever needed realtime, latency sensitive hardware or applications, the likes of realtime sound editing, or realtime video editing, or even interactive games... Do yourself a favor and buy a SIS735 or nFORCE motherboard, or for Intel machines get yourself 64bit PCI cards, to improve worstcase data transfer, which in all cases usually are PCI devices. For true high performance, you need to OC'ed the hell out of your PCI bus whenever possible. BTW, avoid ISA cards like the plague it is. ISA bus-master device is performance damnation.

Quote: The latency of the network card is 128 and the Latency of the HPT366 is 248 They share an IRQ. The Radeon has a PCI latency of 255... <---- Very odd And the PCI to AGP bridge has a PCI latency of 64 cycles All other components are at 32 Could this be causing the random freezing in OpenGL and D3d i'm getting? I used to have the "snap, crackle, pop" with my SB Live! but now with updated drivers (3300a) It doesn't do it anymore... "PCI to AGP bridge has a PCI latency of 64" this is the master AGP latency value, "The Radeon has a PCI latency of 255" meant the Radeon will try using 255 at all times if possible, but the master AGP latency timer will terminate it at 64, it will have to issue another IRQ demand for another 64 cycles if required still more data transfer. All others are usually 32bit, 33MHz type PCI devices, their 32 cycles settings consuming equivalent of 64 cycles for 66MHz AGP device. PCI devices have a master PCI to PCI latency value, which will terminate all PCI devices when the master latency value terminate, no matter what each individual device's value is at. All these values affect bus data throughput efficiency, too low cause poor efficiency, too high cause lock-ups from overly high latency, late response time from an IRQ. Latency value determine how long, how many cycles a bus-master device in turns can take control of the system, locking out all other devices for a time period. All bus-master devices required an IRQ for demand service at their IRQ priority level. This is the fundamental foundation for all X86 architecture, if your CPU has 3.2GB/s bandwidth, at the time a 32bit, 33MHz PCI sound card takes system control, your actual system bandwidth will be determined by the sound card, which is ~130MB/s for this service time period. For an AGP video card, it's 520MB/s. Have you noticed when copying a floppy disk, your computer acting like its came to almost a complete halt? Your floppy disk controller is a bus-master device. BTW, all the above no longer hold true for nFORCE, OK?

I'd buy nFORCE just for the fact it's the first most complete implementation of Distributed Processing hardware architecture ever implemented on traditonal X86, the equivalent of a 10/100 network SWITCH comparing with multitude presence of 10/100 network HUBs. Will this "switch" outperform other "hubs"? You bet yer a*s my buddies...

I don't memorize which driver versions with perfect working overlay control panel, but I suggest using one of the WHQL versions which will more likely to have it working properly than others would be.

Ofcourse adjusting display color correction won't work for movies, output for movies goes to the overlay, adjusting overlay color correction is what you want under the overlay control panel, usually within Nvidia's "additional properties" panel, if such is available in the driver version you're using, if not... registry hackings would probably be required. Though if the YUV color space conversion had to come out wrong, green isn't so bad a color for you, eh?

Within the controller's BIOS setting, you can specify CDROM boot support or any alternative boot device other than SCSI ID 0, during boot-up BIOS screen and pressing CTRL-A for the menu. For more than one SCSI card, use common sense in enabling features for no conflicts, and controller's ROMBIOS address space mappings will provide priority of importance, the controller occupied lower address has priority over one with higher BIOS address, this feature will hold true even for non Adaptech controllers, or non-SCSI controllers depending on how old, or when the controllers were made.

For accurate and decent SCSI info, go here http://www.scsifaq.org/scsifaq.html General long time conventions SCSI boot device ID is 0 CDROM type device ID is 3 SCSI controller ID is 7 ETC... But nowaday there's no need to follow such conventions, unless you intend to load multiple OSs with some following very strict conventions, except SCSI terminators or the last self terminated device in the cable chain should always be at the end of any SCSI cables for proper cable termination... There should be only one terminator at each end of the cable chain and none in between.

This problem usually caused by ISA data interface failures, commonly from Schottky data buffers suffering an excessive static charge from PCB handling, sometimes by greater noise and ringing being in a less than quality ISA slot, which can be compensated with moving to an ISA slot nearest adjacent to the PCI slot, or cleaning the dirty, oxidized finger contacts. Unless the modem is a single chip intergrated design, you normally can fix this data buffer failure... replacing the chips designated 74xx14, 54xx14, or equivalent 4K series nearing the ISA card edge. OOPS... forgot to include same problematic symtoms from an OC'ed ISA bus.

I bought 2 of THIS almost 10 yrs ago, still operating very well, smoothed and slicked as Bill Clinton's MO to this very day.

Reboot to safe mode, remove video hardware device then run regedit to delete all nvdia registry keys such as nv4, global, the 0000 or 0001, etc... under class. Verify or copy the exact version of all the video driver files you were installing to their proper places by using the search function to find/compare them. Reboot again and all will be very obvious as to what needed to be done next by window itself.

kingtrey... Most artifacts if any left in 16bit mode are from z-accuracy errors, turn on 24bit-z for both OpenGL and D3D will fix them with a small performance penalty, BTW I suggest using 1080 driver --image quality in 16bit is also much nicer. [This message has been edited by nam ng (edited 15 March 2001).]