I have been running SETI for over a year now and I am pretty much hooked on it. So, a lot of my tweaking thoughts revolve around a process that I have over 4+ years of CPU time in! Configuration One:While using this configuration, there seemed to be a bandwidth problem...I will explain... Normally, a SETI work unit on a 1 GHz system will complete, on average, between 6 hours and 7 hours. On the Dual system with each processor running a separate copy of SETI, each CPU would take 9 hours! Now, you might think that that is acceptable, after all, a single CPU system would take 12 hours to complete 2 work units (6 + 6 = 12), but with the Dual system, 2 work units would take 18 hours of "CPU time" to complete (9 + 9 = 18). Once again, that may be ok...but in reality, with 18 hours of CPU time, the single system could complete 3 work units...to the Dual systems 2! Yes again...that in 18 REALTIME hours, the Dual system would kick out 4 (9 and 9 + 9 and 9 = 18 hours with 4 units complete) but would tally up 32 hours of "CPU time." Pardon my pitiful math equations, but I hope that you get the point... After cruising the net to look for possible solutions AFTER I went to Configuration Two, I found an answer: The memory performance for the VIA chipsets suck. Well, I was not "OK" with that thought. I am now tending to give them the benefit of the doubt and hope that some additional effort in tweaking would solve the problems... Microsoft provided some help in stating that turning off the I/O counters for the task monitor would help memory/CPU intensive applications. Configuration Three implemented this. Configuration Three:Initial thoughts on this is, well, it really did not change anything. Average time per CPU is still 9 to 10 hours. Now, this could be a theory as to why: The CPU front side bus (FSB) is running at 133MHz, which is, of course, the same as the memory speed. Now, stay with me here...If both CPU's are running a FSB of 133MHz and the memory is NOT clocked at 266MHz, then SOME sort of limitation should exist! I just do not see VIA implementation of separate memory paths to NOT have a problem with bandwidth. In this case, the memory "bus" so to speak, is splitting the 133MHz bandwidth to 66MHz for each CPU at full throttle. This would account for a increase from 6 to 9 hours per CPU. If there was a way to, say, split the 1 GB of memory and have each CPU access only 512 MB of it each, then that "should" alleviate the problem, but what that would solve would be nothing! You would have to be running 2 copies of windows on the system, since the memory would no longer be "shared!" Great solution if you do not want to have 2 complete systems running SETI and put them in one box, but not very good if you actually want to USE the system! :) | System Configurations |
Number One:Dual Pentium III 1 GHz Asus CUV4X-D v1007 BIOS v4.28 4in1 driver 1 GB PC-133 Memory Elsa GeForce 2 Ultra 64 MB nVidia v12.41 drivers 3com 905C-TX-M 10/100 NIC Sound Blaster Live 5.1 Live!Ware 3 Windows 2000 SP1 |
|
Number Two:Single Pentium III 1 GHz Asus CUV4X-D v1007 BIOS v4.28 4in1 driver 512 MB PC-133 Memory eVGA GeForce 2 32 MB tv out nVidia v12.41 drivers 3com 905C-TX-M 10/100 NIC Sound Blaster Live Live!Ware 3 Windows Me |
|
Number Three:Dual Pentium III 1 GHz Asus CUV4X-D v1010 BIOS v4.32 4in1 driver 1 GB PC-133 Memory Elsa GeForce 2 Ultra 64 MB nVidia v12.41 drivers 3com 905C-TX-M 10/100 NIC Sound Blaster Live 5.1 Win2k WDM default driver Windows 2000 SP2 |
Articles Index ~ Page 3 - Sound Blaster Live! ~ Page 5 - IRQ and BIOS Configuration
Quick Links | |
In this article:Introduction | Outside of blackviper.com: Sound Blaster Live! |
Welcome Guest!
"Have you tweaked your OS lately?"
Choose the look:
Windows Service Configurations!
Includes explanations of each service and advice on which services you can safely disable.