I wrote (about 4G/4G) > The basic trade-off that 4G/4G flushes > the TLB each context switch, so that kernel and user both get > nearly 4 GB, and TLB flushes are expensive. Gene Heskett replied: > Ouch! Does this help explain why my old mobo runnng a 1400XP athlon > could do 4.5 seti nits a day, and a 2800XP with this turned on is > only doing 6? Possibly. However, I don't think the SETI client does many context switches (except when it's hitting the network to send results and retrieve a new work unit). It should be all user-land calculation. Besides, IIRC, they never produced a 1400 XP. There was a 1400 MHz "Thunderbird" design Athlon, then after a couple of redesigns, AMD came up with the 2800+ "Barton" Athlon, which *was* labelled XP. Those redesigns were aimed at getting more performance "per clock" (per MHz) out of the Athlon, rather than increasing the frequency, and they normally worked. AMD had (has) a fairly neutral benchmark which they used to calculate the processor rating: even though the 2800+ only runs at 2.083 GHz, it's supposed to be twice as fast as a 1400 MHz Thunderbird -- on "average" Windows apps. But I understood SETI to be dependent more on memory speed than on the efficiency of the processor once the data has reached it (with modern processors). On the third hand, I understood that a SETI work unit was supposed to be around 340 K, which should fit into Barton's 512 K cache (if not into Thunderbird's 256 K). That should mean the Barton doesn't have to go back to main memory for SETI data, which should (again) make it much faster. Perhaps SETI have changed the work unit size. So I'm not sure exactly why you're seeing those figures. You could try compiling a vanilla 2.6.7 kernel and see what happens. James. -- E-mail address: james@ | "Right lads, we've got 45 minutes to score 37 goals. westexe.demon.co.uk | No problem with that -- the other team just did."
