• blah
  • blah

Small but perfectly formed...
The much heralded 31st July SETI 'server outage' finally forced me to acknowledge that even my lowly output can benefit from a caching program. SETIDriver (V1.42 is out and about) to cache and SETISpy (v 2.52 latest) for glorious info make a great combination for my BP6/Win98/Celery setup. The topic of caching appeared as a long conversation (see Re:major outage on July 31...) on the alt.sci.seti newsgroup and finally made me decide that Carolyn (of clinic fame) was not human after all. I've been convinced for sometime that her (!) answers were definitely of the AI/Turing machine variety but the 'zipping' files suggestion - "I have zipped one file before by just renaming it and changing the extension to zip, but how do you zip together more than one?" was conclusive proof of a clever software emulation that was repeating key words just once too often. Also in a humourous vein is a well constructed graphic on the HardOCP site that provides answers to a lot of my windows problems. Thanks to Rizen at Rizenet for that one. That's the rambling intro over so I guess I better give you a few times to keep the number freaks at bay...those of you who've submitted beta times can relax in the knowledge that I send them on to RB to cogitate upon.
A K6-2 time from Bjarne of 12:32 achieved via a 450/100 setup on Win98 is in the right area but could be another 30 mins to lose there with the right tweaks. Likewise Francin's 450 Celeron (4.5 multiplier) and 7:49 is okay but should be regarded as a baseline for further reductions to about 7:10 say. If you've been following Rat Bastards prognostications on the beta page then you'll know that FSB is going to be playing a smaller role in the v3 client. But for now we are still living with v2 and it's good to see that Kris is fiddling with bus/multiplier combinations on his PII. He's gone from a 4x108, 6:57 to a 3.5x124, 6:42 to knock 15 minutes off. A small but pleasing improvement, might have expected more but if that's the time then so be it. Coming in at under 6 is Nemo and a Dell PIII 733/133 which benched a 5:52. Not going to win any prizes there but if you want reliable and solid let Dell have their settings but for Seti speed those conservative timings are a killer. Win 98 instead of NT4 would be a significant help as well though an OS change is more for home machines than the one at work! That man Clank has been dusting down the mothballed kit in his neck of the woods, again. The result is a bench on an SGI Origin sporting a MIPS R12000 cpu with 2MB L2 cache, yummy. These are seriously scaleable processors that are happy congregating in groups of 16 to 512 units. This rather stonking graphics machine (though no longer king of the hill) runs at a comfortable 300MHz and quickly produced a 3:02. Is this stuff just hanging around your office looking for an excuse to exist or does someone occasionally put them to proper usage? I wonder what you'll chase out the bushes next! Origin 3800 perhaps, I can dream at least. Finally apologies still for the results table being out of date. The 'guru' problem hangs over it still.
Max out.

Einstein's Blackboard...
Typical no updates for a few days then several all at once...happening news: great isn't it. So here I am - back in the land of the living Seti crunching monster we call TLC. Grand. I have returned from a seriously intensive week of pure math's (9am - 9pm, with optional 10pm lectures if keen) at Nottingham and after catching up on some sleep am almost refreshed and on a charge. With the various changes to the site structure Rat and zAmboni have been loading the front page with juicy news - some very interesting bits about 'tailor' made PCI Seti cards (hoax it seems) and V2.70 client info (see below - right now!) especially the FFT size details that will make a lot of small L2 cache cpu owners happy!. In regards to beta testing and benchmarks thanks to wehringer for your time (a painful 40hrs) but I'm not starting a separate table (lets get the old one updated first - Rat is working on it) for the beta, RB is covering it's vagaries far more efficiently than I can.
Anything that speeds my modem up is pleasing so here's an interesting link for a registry hack - p.2 & 3 are the useful bits. It seems to have given a slight boost (10% perhaps) so some of you might benefit. I thought I'd come across most of them but this was new to me. Enough natter and onto the submissions that have appeared during my absence...d2s  opens the account with a Pentium 166, W98 and the nonIntel 2.4 client churning out a 29:36, now if this is the same underclocked beast that produced 37.35 running at 133 then this is interesting. If not then it's in just the right area time wise. A 9:54 from Felipe is reasonable but there's some slack to be cut off there if you want, but it's good to see any K6-2 owners into single figures. The names get more bizarre but that's up to you (I'm just the messenger, good taste is not in my remit) so Chewie's Hairbrush gets a special mention for originality. Another rare sighting of a very solid Unix server (HPPA 8000) system running out benches in 8:58. Excellent at what it does but that was never meant to include crunching Seti WU's! Yet more rarity but this time in the OS from Jose Moreno whose BeOS equipped 800MHz Athlon returned an 8:03 but then as expected knocked a hour off to 7:10 by running Linux. Unless you have antipathy towards running W98 it will take another 20 minutes off if you go down that route. Thanks for that as I always like it when people do direct comparisons on the same hardware. Here you go Jason, the answer to your question (assuming the link holds) about Thunderbirds. Vanzuylen has an 800MHz T-bird with Win2k that delivers 8:01, nothing special there, in fact downright disappointing considering the 256 KB L2 runs at clock speed. Standard Athlon L2 runs at a fraction not exceeding a half of the cpu clock. There's a long and detailed account of Athlon/Thunderbird/PIII differences at Anandtech. Win2k can account for some of the slowness but my guess is that the mobo you have uses the KT133 chipset which is definitely sub par. As if to prove a point Vanzuylen also offered up a 700 Athlon/W98 time of 6:55 - more than an hour to the good. An overclocked PII (433/108) time from Kris of 6:57 is in the right area though you'd gain some worthwhile time by disabling those background applications such as Norton AntiVirus, DirectCD, MDM etc, it's a benchmark after all. Also disabling ECC in bios should give you a slight edge - depends on how necessary it is for system stability/data integrity. Look forward to your next considerably faster submission. Seems quite a while since Angus graced this page so here's a Celery II (another disappointing new-ish cpu) time from the man himself. Overclocking a 566 to 708 with CAS2 ram and W98SE outputs a 6:44. Nothing special except that it's actually quite good considering the 83 FSB, up from the laughable 66 these cpu's default to. Chaz benched a new Dell 4100 (PIII, 933 MHZ, 133 bus on the 815 chipset) and was slightly down about the 5:13 it returned. After a little more 'playing' he reduced that to an average 4:50 in safe mode (W98) but still felt it lacked something. Looking at the table it seems to be in the right area considering the FSB. The Dell tweaked (read under-optimised for stability) bios could easily be a source of time losses and the Intel 815 (Solano) chipset is still only reviewed generally as 'okay' compared to the venerable BX. Added to this is the latency doubling once the 256Kb cache is exceeded so perhaps you shouldn't be too surprised. Keep tweaking if you can find anything to tweak! Bob, if you are reading this could you supply some more info in regards the stunning time you submitted, thanks. As for the blackboard (the great man visited Notts Uni and the offending blackboard and clever grafitti is in a glass case) it looked like any other - I couln't understand the sloping scrawl but who needs to be able to write clearly to be brilliant.
Finally thanks to Mournblade who got an interesting reply from SGI technical support (UK) about the speed of  MIPS processors for Seti crunching. The last line reads "...so a 400Mhz R12000 (which is the current CPU) should take 1 hour 34 minutes therefore a 512 CPU Origin should manage about 7804.1414 per day." Anyone got a spare Origin?
Max out.

Initial results from the beta
I've had a chance to review the new 2.70 beta client, and I've managed to get all the data that I can for the time being. Of course, I'd like to point out before I go over the results that this is not the final client, nor should it be expected not to change. However, it is indicative of the final client's performance, and there may not be a change. So, for the time being, just consider it as a possibility of the future. 
With the hardware that I had on hand, the best testing I could do would be to try 3 different cache sizes on what would be otherwise identical (more or less) CPUs. What I was trying to find out was whether or not the new FFT routine really was as cache friendly as had been previously thought. And just how small the new working set would be. I had at my disposal a PIII 550 Katmai, equipped with a 512K L2 cache, a PIII 550 Coppermine, equipped with 256K of L2, and a  366 Celeron, which I overclocked to 550, and had a 128K FSB. Notice that not only were all CPUs the same speed, but the FSBs were identical on all of them.
The rest of the test bed consisted of a Abit BX6 Rev2 board, equipped with 128M with a 2-3-2 timing. The reason for the funny timing? It's the fastest memory settings I can get to work at the normal FSB for this machine (138), and I simply forgot to set them back. The system is running Windows2000 Professional, with any unnecessary programs shut down. The screen saver was set to a standard blank screen, instead of the Seti clients screensaver (it's too slow), and the client was set to run all the time. I ran this test overnight each time, so that I could ensure that nobody would disturb the machine. 
The first test was performed with the 550 Coppermine, which was already in the system. I ran the client overnight, finishing the workbench unit in a blazing fast 5:13. This is very impressive for the new client, considering the fact that with the same system running at 760MHz with the 2.0 client, it took 5:23. So everything was faster with the slower CPU. Very nice and indicative of L2 cache optimizations. One way to tell on that though.
The next run was with a 550 Katmai, which is equipped with 512K of L2 cache (half speed, so 275MHz). I ran the test again on the testbed machine, using the same work unit and the same conditions. The time was 5:13. Identical! So the new 2.7 beta looks to have shrunken the working set size down below 256Kb which is a huge boost for everyone. The only thing left to test was whether or not a Celeron would run as well.
Thanks to MadMac, who sent a slotket to me for testing purposes, I was able to try with a Celeron. So I took a 366 out of my BP6 and affixed it to the slotket, and installed everything in the testbed. The FSB was set to 100, bringing it up to the same speed as the other processors in the test. Then I ran the work unit again. The time increased slightly to 5:41- which means that it didn't all fit into the L2 cache. However, most of it did, and it was a lot faster than the current client is. 
So, where does this put us? For starters, there is 2 major changes that I see happening from a hardware perspective. First of all, you no longer will need 1M of L2 cache to run Seti efficiently. You can do it with as little as 256K, which makes the new Coppermine an excellent choice. Secondly, I think you no longer have to worry about the FSB. With previous versions, high FSB speeds helped to make up for the fact that the client wouldn't fit into the L2 cache. However, since the client is fitting into the L2 of anything with 256K or more, this won't play a significant role. In fact, I think that the memory's performance in general will be less important, and that clock speed will finally start to be the deciding factor. Which means that the Via chipset might be a very effective alternative to the BX. 
One thing I don't have info on is non-Intel CPUs. Which, of course, really means AMD's. So if you have one, now might be a good time to try a bench run on it to see how it performs. In the past, Athlon CPUs have had disappointing times for Seti, which I believe was due to memory issues- hopefully that will no longer be a problem. Only time (and the finalized client) will tell though. -Rat

Quick status update
Hey everyone- just some quick news on things happening on the benchmarking front. First of all, Things have not exactly been idle. I've spent my time by doing things other than frivolous thread posts in which ColinT and hanser threaten to beat each other up. I've been playing with my son, and setting up a new server. So I'm having fun. Anyways, here's where things stand.
The new beta client is certainly proving to be much more reliable than the old one. With realistic (and fast) run times, it's much more workable than the 2.66 client was. It still has bugs though, as some are reporting that some work units are taking extremely long. Eric Kopela is aware of the issue- if indeed it is an issue, and not just a result of the added science. Intial results from a benchmarking front are VERY good. As in better than they have been in the past good. I recieved a slotket for my system today (thanks MadMac!), and I'll be running one last bench tonight before posting my preliminary findings for Intel platforms tomorrow. 
Also, with the departure of Guru from the team, we have run across an issue with the results page. Specifically, the results page has been hosted on Guru's system, and the scripting was written by him for the sorting. I no longer have access to this system, and need to come up with another option. I can split the results up over multiple pages and post it in the old fashioned non-sortable way, but that would suck. Therefore, does anyone have the skills needed to write a Perl or PHP script that can do sorting like our current table does? If so, please let me know. Or if you just know where I can find a table that's available, send me a link. Thanks in advance for any replies I might recieve. -Rat

No pain, no gain and other modern myths...
Interesting week, SP1 for IE 5.01 followed almost immediately by IE 5.5 (reviewed coolly at CNET) and even the fabled Win2000 bug fix, sorry Service Pack is due for release imminently if you fancy some large downloads (say 10/25/60ishMB respectively) for the sheer pleasure of watching the modem download stats flashing by! Also in the modem arena there's an new ITU standard called v.92 (upload improvement only) and also another at v.44 for improved software compression. If any of you love your fans then this will be up your alley at netkills. I've seen cases with far more installed but not with quite such an eye for understated suckage. 
On a personal level I am getting a lot of pain in my left arm from a pinched c7/c8 nerve that seems to have returned to haunt me again after several years absence. It was due to a climbing accident (or rather not climbing) - while soloing found that I was not capable of controlled VTOL. Good job I landed on my head - might have damaged something otherwise. Ironically enough the way I get relief is to put my head into one of my old climbing slings and stretch my neck. Must seem dodgy to onlookers! Since I'm off to Nottingham Uni for the week I could well do without this attention destroying pain. Though they have computers in abundance I am there to do some work so I think any more ramblings will have to be left either to RB or my return next weekend (23rd or so). You have been warned.
I feel a few benchmarks coming on...not too many today, I guess it's been a quiet week. Stefan got back to me, well the submission page anyway and his K6-2 has appeared with a very sensible time of 12:53 on a 90 bus. Not a lot you can do with that as I'm not sure the Pchips mobo goes much (meaning not at all) on incremental bus speeds. Check with the site for a bios update (always worth a look) that might have some user changeable settings and try disabling the onboard sound (worked for wyvince, 11:44). But it's still almost two wu's a day so be pleased. Back in the real world we have sbeikirch who's using the GUI on a PII for a 10:30. Ditch it! Go with the Cli and say 'bye bye' to those time wasting graphics and watch your times drop. Clank is back with some more SGI MIPS lovelies. He benched the Onyx2 again for us but with the client running on each of the four cpu's. Result as expected - all completed within 66 seconds of each other averaging 6:24. Exactly the same as running a single instance. Big L2 cache means no RAM bandwidth problems as the Client data set almost never gets to ride the memory bus. So one cpu or four there's no infighting for data and it runs just as quick as if the other three weren't there at all. Just a real shame it has such a low cpu clock speed (195MHz). Clank also came across an Octane (another very serious graphics workstation) which has only (!) 1MB L2 but again is crippled by the speed, a lowly 175MHz crunched out a disappointing 8:19. Although with two MIPS cpu's this is a very powerful graphics SMP machine the client is not multithreaded and runs purely on one cpu, the distributed nature of Seti is the only parallel processing part of the project. Interestingly the SGI site  info suggests the Octane runs a MIPS 12K at 300MHz so I wonder if this is just an upgrade over previous older examples or you have a crippled runt of a beast? The mystery deepens to at least ankle depth. Keep sending them in. A quick time from pboel on a 466 Celeron (66 bus a real brake on further progress) that's screaming to be overclocked to 75 if you have the option. Set memory to CAS2 in bios to go faster yet. JonT's PII 450 coughed up a respectable 7:15 and then he repeated the exercise at a 112MHz bus to skewer a 6:32. There's only one PII that's quicker (spiffy 5:59 using a 129 bus) so I would have to agree that's a very good bench indeed, consider yourself old but worthy. Sir Rich is only 8 minutes off the fastest Athlon title (not a status filled position unfortunately due to the known woeful Seti performance of the Athlon) with his 5:35 on a 103 bus. Perhaps you could vary the cache speed fraction to gain a few minutes but you are pretty much at the end of the line with that baby. We all (nearly all) overclock our kit but when it comes to the work machine then stability usually comes first so it's a brave Dave who runs his PIII 450 office system at 630/140. I always have admired the crash and burn spirit of our team. Anyway it cracks the 5 with a 4:55, a very respectable time but there's a long way to go if you want to get serious about cooling and FSB. But as you say it is your work machine so let's not be to adventurous (sound like my mother). Lastly a couple of times from Manta70 who benched an overclocked PIII 600E on an Abit BH6 with CAS3 RAM (shame) at 135 to end up with a 4:51. You're in very competitive PIII company under the 5. Same setup but disabling the bios shadowing (a known tweak) dropped the time a relatively small but useful 11 minutes to 4:40. Good stuff but get some decent memory and lose another 15 minutes. That's the numbers for this evening but before 'vamoosing' (too much High Chaparral and not enough Virginian - Trampas was my hero) I'd like to thank styve for his positive comments received in a roundabout fashion - most people use email these days!
Max out.

Life discovered on benchmark page...
Good evening to those of you on the other side of the screen. At last SetiSpy has gone to 2.5.2 and the history shows 23 minor and not so minor revisions. Going straight into the times brings me to styve who produced a 19:08 on a 249MHz K6 (83 bus) which is okay and then put an overclocked P233MMX into the same board and came up smiling with 16:36. I hope I got your numbers right from the submissions - corrections always welcome. A seriously useful speed up for Geordie and that dual PIII Supermicro system with a new bios. Getting the FSB up from 100 to 112 has dropped the time from 8:46 to 7:45 for two completed bench wu's. Excellent outcome. It's the bus increase that has improved the time but no harm in checking you have the newest bios available. Though new bioses generally just allow compatibility with new hardware they can occasionally provide a efficiency boost, so stay up to date. Next up is litespeeds Celeron II up from 566 to 850MHz which lays down a lazy 7:06. As is the case with the Celerons big cpu clocks - they always play third fiddle to the FSB and memory CAS settings. Now start chipping away the 'default' (bios and RAM) presets and get that time down another 30 minutes at least. Some notebook benching from Exchequer who used a ramdisk on a Dell Inspiron (450 PIII) and received a 6:58 for reward. Notebooks and ramdisks are well suited as the RAM uses a lot less power than keeping the hard drive spinning, but don't expect any speed benefit! This time is pleasingly similar to Actions 6:56 from a while back on a similar machine. Clank came up with a rare piece of power graphics kit, an SGI Onyx2, but since the client is not cache limited (MIPS R10K processors come with 4MB) it's bench speed is going to be dictated by the cpu clock. Hence your heavy duty hardware running at a meagre 195MHz is never going to light up any Christmas trees as the 6:24 bench shows. In effect it's roughly comparable to a Xeon but with a slow clock, shame. On the upside a beast like this has huge overhead, you could run a client on each of the four processors and still end up with 6:24! Take comfort in that thought. Next up is Joker who related his server problems in a forum thread, not an electrifying read but a link is a link (though Redbeards' comments should be standard practice for most of you). After a reinstall Jokers PIII spat out a very respectable 5:32. Stilgar submitted a 5:30 squeezed from a PIII/Win98 combination (common as muck, but only because I'm a jealous Celery owner) - changing from the 2.0 to 2.4 client and upping the bus from 120 to 122 has apparently done nothing for you in terms of time, a little odd, should be worth a few minutes at least. Nearing the end of this evenings (I always work at night) offerings is Jtrinkle and a pleasant sub 5 (4:55) on yet another ferociously OC'd PIII, but as you comment you certainly could do better...perhaps another 20 minutes to prune off yet. Getting ever closer to the 4 hour barrier on a overclocked PIII (!!!) is Endless with a blazing 4:06. A 550E at 154 bus on an Abit BE6, CAS2 RAM (at last at this FSB) and Win98 appears to be the magic combination. I await the sceptics mailbag with trepidation. Finally on benchmark matters, Stefan could you get in touch as I'm pretty sure you didn't mean the time you submitted, thanks. Extra finally, If you cannot find your times, we are aware that the results are lagging behing my words and it's being 'worked' upon! 
It's been suggested that a 2.66 beta client bench page would be in order...I struggle to keep up with this one! So don't expect too much enthusiasm from me until 2.66 becomes v3 official and we start a new results page proper. Always open to suggestions but since the beta is at present very slow (double or more) due to huge cpu switching it seems likely that it will be rapidly updated with amended versions, I hope! zAmboni is keeping you very up to date with his progress and that is sufficient for the present.  Surprisingly that suggests I have a life, hard to believe. Right, I can go off to bed happy now.
Max out.

Touchy Feely Huggy type stuff...
I will put up some benchmark numbers soon (small backlog) but just felt like writing some words today, please forgive me (drops to knees and quietly sobs). Roelof (he of SetiSpy) gave me a nudge about a couple of things but since I was going to mention them anyway I don't mind the attempt at self-aggrandisement. Envelope full of unmarked currency soon please. Firstly the proprietary Engelbrecht CpF vs. CPU Multiplier graph has been updated with new Celery II, Xeon and K6-3 plots. Secondly there is a beta version of 2.5.1 on the SetiSpy page. It has several interesting new features including more performance info, an extra graph on the results tab, the processor comparison table has been re-modeled and allows a personalised multiplier to suit your own system. Also the sky map shows the telescope path (though a straight line is not very informative - something missing I think) and there's a new logging feature on the set-up tab for saving graphics. Other minor changes I'll leave to you to discover and though beta I haven't needed the insecticide yet. So much info and usefulness packed into something so small - I am unashamedly a fan. If only it downloaded and cached wu's perfection would be in my grasp. Though I personally am already there. Naturally.
So in the last few weeks we've had SetiHide (1.3), SetiDriver (v1.21 claims compatibility with SetiSpy) and now SetiStash (v1.1) which I noticed being referred to in the forum by ColinT (of course). It's a caching program written by one of the Knights Who Say Ni! (KWSN - just in case) aimed at dial-up connection users and works in conjunction with SetiLog. Early days in its development so if it doesn't quite meet requirements you can be sure there will be revisions to come. All these goodies - wonderful!
Noted on overclockers.com 7/2/00- "I have a question. Some of you are using all kinds of radiators found in cars for industrial-strength coolers. While I realize this isn't exactly an iMac crowd :), how many of you are doing this, and do the rest of you want to know how?" Next step - anyone got a standby generator in the backyard because you don't trust the UPS to keep you powered up for Seti?
In TLC things have been getting kind of hectic: stats for all; Art Bell passed; dedicated forum appears; Rat and zAmboni get some recognition from Caesar; Guru leaves, cratering totals and knowledge base; CES pops up out of the swamp with big ideas (hi!); RB & Caesar & zAmboni get together and talk (good). Big posting traffic in forum about these events with almost all being enlightening and thoughtful (as you expect with the TLC crew), which even on the bad days makes me feel there's something fun and worthwhile going on here. Some of the most interesting details have been the background history of Ars TLC, its setting up, co-ordination (and obvious lack of) and subsequent development into the monster mutant offshoot it has become - reminiscent of the scene in 'Alien Resurrection' where the albino newborn says 'hi' to Mum. Most of my views have been covered adequately by others so there's a lot I don't need to say, saves a thousand or so words. Recently zAmboni replied to a series of posts on the alt.sci.seti newsgroup from Trust No One (29/6/00) and I was surprised how unpleasant it felt reading about the stats integrity (and by inference TLC) being questioned in such an ignorant way. Rat and zAmboni need your support and it's been good to see how much there is available. By losing a few team places I feel it's a new challenge rather than a major downer and is a re-injection of the competitive spirit that could quite easily have calmed after passing Art Bell. The apparent negatives of the last few days have just reinforced my views about the positive spirit and lively nature of this place. Keep benching, keep me humming and do what you enjoy.
Max out.

What, another one...it must be the weekend already!
Yet more numerical goodies to lay at the feet of you good people. No farting about with an attempt to educate or enlighten in other spheres today just the lovin' spoonful of hardened bluesy benchmarks. Busy Al Bartenstein (any relation to Mad Al Jankovitz? Remember the cover of Michael Jackson's 'bench it' all those years ago) - sorry wrong planet...completely lost it, back to benchmarks. As I was saying Al Bartenstein is not a person to retire old hardware gracefully and has been putting Pentiums to the sword. A P75 running at 100MHz clock threw up a 39:53 which has just edged his Cyrix 133 by 3 mins (39:56). At this end of the table almost anything goes and the three minutes might just have been a cold draught blowing over the chip! As long as your happy to lord over some other piece of old architecture then that's okay. Fast is fun, slow just is. They all get there in the end, I hope. Next in Al's locker is a P166 on an 'old motherboard' (!) that offered a 25:31 which in turn was roundly thrashed by an hour (24:30) by an overclocked P120 (to 133). Surprising on the face of it except the lower multiplier and use of SDRAM more than make up for the unimportant clock difference. Astute readers (both of 'em) will notice that when I read 'old mobo' in the comments I assume they are indeed talking DX vintage memory as well. Finally Al has unearthed a 233 IBM ThinkPad, serious kit 18 months ago, which commendably managed an 18:37. Now here's a place for a RamDisk - allowing the HD to be powered down, conserving batteries. But only if you can't be bothered to reach over to that wall socket. All of Al's systems ran RedHat 6.1, ideally suited to slower machines due to lower OS overheads and considerable efficiency compared to Windows in a restrictive environment. Long live Linux. Before continuing here's a...

K6 benchmark special...
Here in the middle kingdom of times (10 to 20 hours) talaktalan rules the AMD roost in numerical terms returning a stonking nine benchmarks at one sitting (collective noun a 'gluttage'). All use a 400MHz K6-3 with 96MB CAS3 RAM running the 2.4 client on Win98 which is the simple baseline config. stuff. Taking them in groups of three as I think he intends the slowest is 21:36 with the 2MB L3 cache disabled, a FSB of 100 but the RAM at 66 (non-synchronous). Note: L3 by AMD convention (Intel would demur) is on board, i.e. memory specifically added to the motherboard and dedicated to the cpu in an effort to improve performance on chips with little or no on die (L2) cache. Next step is to synchronize the FSB and RAM (both now at 66) which drops the time to 19:55. Finally in this group have memory and FSB running at 100Mhz to yield 16:16. As usual faster bus quicker time but also better to be synchronized on a slower bus than faster bus and get cache misses due to non-synchronization. I hope this is making sense to K6 owners at least! I'm sure my mail box will put me right by tomorrow!
Next group of three disables the L2 cache (the on die stuff, small but fast memory located intimately within the CPU chip architecture), which apparently approximates a K6-2. Running everything at 66MHz produces a 16:27. Now keep the RAM at 66 but put the FSB to 100 (non-synchronous) to get a time of 12.09, a very useful difference. Finally memory and FSB at 100MHz gives 11:40 which shows that if the L2 is disabled there is a small loss of efficiency by running non-synchronous memory and FSB.
Final group of three leaves L2 and L3 running. Firstly in synchronous mode at 66Mhz comes in at 11:46 and with FSB 100 and memory at 66 a big jump to 9:46. Lastly synchronous at 100MHz romps home to 9:26. So there you have it how to from 21:36 to 9:26 on what is in essence the same hardware running at identical clock speeds. The major effect of cache is clearly shown by the big time differences and also the small but significant downside of running memory and FSB at different values. It would be worth K6 owners checking their bios and board settings as you could be returning apparently reasonable times (11 - 12 hrs) while having the L2 disabled! Just a thought. Thanks to talaktalan for all those benchmarks. If I missed something important let me know!

...and back in the real world.
A big jump now to several happy chappies. First is fsgray and that Celeron II again. Using a VIA 133 board allows a 100 MHz FSB while using a 133 Memory bus (4/3 divider), being a creature of BX vintage I am very jealous. Overall result is 6:32 an excellent improvement of 52 minutes from the last benchmark. But before you go all dewey eyed on me, there are several tweaked Celerons ahead of you running Win98 to your Win2K. So that's the next the next speed step which should be good for another 20 minutes. Isn't freedom of choice wonderful (a great album by DEVO as well, especially 'gates of steel').
Another very happy bunny is Jeremy Crawford who changed mobo to a BE6-II allowing him to up the FSB from 117 to 126 in turn knocking 36 minutes off to record 5:13. What next from this eager bencher? Coming in at 4:48 system has pleasantly cracked the 5 with a Coppermine PIII on a 138 bus (897MHz clock), you are in good company here with hordes of similar cpu's pushing out very respectable times. Bus is the only way to go if you can push it. Next up is Isobe & garbage machines (great name) marginally overclocked Mac G4 at 4:38. No pointless chip snobbery here, Mac's run Seti extremely well due to large cache (mainly) and a smaller, more efficient instruction set. Marzio Nieddu has benched Win98SE for us on his 1085MHz PIII and not too surprisingly knocked 14 minutes off his Win2K time to post a superb 4:09. Think that's end of the line for speed-ups on your machine, please prove me wrong! While in the area Marzio also ran Win Millennium (rc2) and recorded the same time (well, 9 seconds slower if you really need that level of detail). Since ME is just a repackaged Win98 with a slightly cleaner interface that's not surprising, Win98 Third Edition would be a more accurate title. ME still has all the legacy baggage underneath so don't expect any speed up from this 'new' OS. To round off this collection of benchmarks off Hance_wu has breached the 4 on a Dell packaged Quad Xeon, 4 clients (one per cpu) running on NT4 came in at 3:54. Great fun to be had putting the office furniture under the Ars WU hammer.
Endless could you get in touch about that yummy PIII time, thanks. There must be many of you who are beginning to think that your job is actually to run and tend Seti farms, good for TLC but only if  legal, moral and within your objective control. Keep TLC clean, especially now that Art Bell has fallen and the next on the list is so far off that the temptation to cut corners must be strong. Moralizing over. If anyone is in the Bedford area (fat chance) on Sunday morning come along to the Triathlon and say 'hi'. I'm less objectionable in person!
Max out.