[reader50]

My system: G4 350 Sawtooth (single processor), 128MB, OS 9.0.4 & OS X PB. 56K internet connection.

The longer times in the OS 9 3.0 client are not satisfactory. For the folks with 512K L2 cache, there is a nice improvement. But I want to once again take advantage of the larger L2 cache that G3 & G4 owners have. So I have been fooling around with X, trying to get the most out of SETI with the multitasking and the crash proofing. The GUI X client is a total loss, at 47% done I took the first WU away and let the OS 9 3.0 client finish it. Even though the 9 client restarted the WU from the beginning, it still took less time to crunch the WU than it would have taken for the GUI X client to finish it. I still use the OS 9 client to crunch WUs in the background when I switch back to 9 to do something. Then I jump back to X and let X crunch away.

The CLI Rhapsody5.6 client has proven to be the answer. Alone, it gives fair times in the 9 hour range for me. It would do better if we could run it from a RAM disk, but Apple has not yet provided the Memory CP for X and no 3rd party has offered a RAM disk utility for X. Without a RAM disk, the client stops crunching every time it writes out a partial result. That idle CPU time is what makes SETI take longer without a RAM disk. Remember, the CLI client is a version 2.x client, it should benefit from a RAM disk just as much as the GUI 2.x clients did.

It may be possible to set up a RAM disk in Classic and use it for the CLI client, but that takes a bunch of memory, a bunch of processor time to maintain Classic, and the Classic RAM disk might be paged out to disk by OS X's vram management anyway. Not so good. But I figured a way around the problem: run multiple CLI clients. The people with MP Macs do it to keep the units crunching on both CPUs, but there are good reasons for us single CPU folks to run multiple clients as well. While one client is waiting on hard disk access, the other(s) are still crunching away. Each client will still take the ~9 hours (for me), but the total WUs produced per day will increase since no CPU time is lost.

The minimum number of CLI clients to run in order to have this 100% CPU usage is two clients, and they will run nicely from a 512K L2 cache. The program code will remain in the fast L2 cache memory. With my G4's 1MB L2 cache, I usually run four clients (when my system is otherwise idle - two clients if I am surfing or doing other things). If too many clients were running, the application code would sometimes be bumped into main memory and would have to be reloaded before that client's crunching could continue. I do not actually know how many clients could be run in 512K or 1MB cache before code started getting bumped. Five clients seems to make for more HD access, but that is just vram swapping because of my 128MB RAM. The only way to catch code being bumped out of L2 cache would be a decrease in WU/week and I have not yet done such a timed test. Whenever I get more RAM, I will certainly run such a test with various numbers of clients running.

I mostly run four clients rather than two because of my dial-up internet connection. Connection has to be done manually, so extra clients make sense. When one finishes, at least two will still be crunching away, still using 100% CPU time. When I do come by and send the WUs in, no time will have been lost as long as two clients are still working. Four clients is also cheap insurance against the SETI servers being down.

With four clients running most of the time, my output does seem to have gone up to at least three WUs per day, or under 8 hours. That is about the time I was getting under OS 9 with the 2.x client and a RAM disk. It is not the disgustingly short 3-6 hours that cheap peecees can get with the 3.0 client, but at least my 1MB cache Mac is back to it's previous speed. I will be counting how many WUs I kick out in the next week and post more exact figures to this thread. The numbers should be accurate. Since the OCN business, I finally started leaving my G4 on 24/7 to crunch away. So the WUs per week should yield an accurate average hours per WU.

Remember, the CPU time will show high if you figure it up. There seems to be no way to decrease the CPU time in each WU, but restoring our previous WU production is the next best thing. Good luck everyone, and I hope these ideas help. Even for you turkeys with 50+ Macs that are permanently ahead of me. (mkbhatia, it is going to be a loooooong chase unless you use these tricks - hehe)

[reader50]

Additional tips:

• Avoid the "-verbose" option when you are not there. It keeps various processes running to update the display in each Terminal window.
• If you do use the "-verbose" option, do not minimize the window. Unlike windowshading, OS X minimizing allows the window to continue updating itself. You would keep the various processes busy, plus you keep the Dock busy stealing processor cycles. You can see this with ProcessViewer, every once in a while the Dock will get some CPU cycles while updating the SETI window icons.
• Quit the Clock. I took it out of the Login items. CPU waste when I am not there.
• Remove the GUI X client. It leaves two processes running to enable the screen saver function. These two processes keep running even if you turn off the screensaver in the GUI SETI prefs. And since they are run as root processes, you can't even force quit them unless you are logged in as root or handy with the unix command line.
• Turn off any other screensavers, including the Apple one. Turn your monitor off instead, the screensavers take some CPU cycles. The 3rd party screensaver modules take a lot more CPU cycles with various animations.
• Don't leave ProcessViewer running for very long. It is neat to see the SETI processes adding up to 98%-99% of CPU, but ProcessViewer seems to want a fair amount of CPU itself plus memory.
• Turn off anything else in the Login items that you can. It comes with Clock and Software Update Scheduler by default. I turned off automatic SW Update in the SW Update application, then removed the scheduler from the Login items. There are no updates yet anyway, and the scheduler runs as a background process stealing CPU cycles.

Does anyone know what administrative processes can be safely killed?

[Joe Cool]

So I have a dual 450. Should I run like 8 coppies at once?

[reader50]

If you have a dual machine, I would run at least two per CPU. That would make a minimum of four clients running. If memory serves, the MP G4s still have a 1MB L2 combined cache, so I would be cautious about running lots of clients. If a client's code gets bumped out of the L2 cache, your WU production will slow down a bit. Probably not too much, but every little bit helps. Try five-six if you wish, see if production per week drops any. I can't try this until I have more than 128MB or I see VM swapping in main memory.

With a minimum of two clients per processor, no CPU sits idle while waiting on disk access. Running more is insurance against SETI server problems or delays in sending in WUs if you connect manually.

Another tip: If you connect via PPP.Connect, you can quit PPP.Connect while you are online. The connection is left open, and you have one less process taking some CPU and memory. Just remember to restart PPP.Connect and use it to disconnect before you drop offline. OS X does not know how to disconnect itself from a PPP connection, and there have been warnings about shutting your Mac down under X with the connection still open.

[This message has been edited by reader50 (edited 10-31-2000).]

[Joe Cool]

Sounds good. I will try it.Dual G4's have 1mb cache for each g4. I should be kranking out the WUs!

[Todd Madson]

Did you say nine hours per work unit on a G4/350? Ick. I am staying with
9.04 at the moment despite the benefits of OS X. The issue I have is that
I will be getting more work units done per day than under X. However, now
that I am aware of the fact that one can run two copies at once this may
be a good thing.

I realize the OS 9 GUI 2.4 client will expire long before the OS X CLI
2.4 client. The very moment the 2.4 OS 9 GUI version expires, I'll
reboot into OS X and run the 2.4 CLI version (two copies, or even
four) until such time as that expires.

I realize there is more science in the 3.x client, but the OS X client
is so dog slow it isn't even funny. And the 3.x client on my G4 makes
it seem pathetic and slow. The PII and PIII machines at the office
can charge through a block in 6-7 hours versus the G4 chunking away
at 14 hours.

I suspect, however, more Altivec optimization will occur in the next
version of OS 9 (9.1). If this is the case, we may see better performance
simply because various math routines will be using Altivec instead of
whatever standard routines were involved.

This still is laughably bad performance in some respects. If you've
run the RC5 distributed.net clients at all on an Altivec machine, and
these clients are Altivec optimized - you get ridiculously fast
performance. Thousands of work units in a day aren't out of the ordinary.

Of course, searching for aliens is a little more exotic than trying to
crack a 64 bit code...

[reader50]

OK, testing done. At least until OS 9.1 comes out, and/or Apple upgrades OS X Public Beta.

My subjective perceptions were off the mark. Even with two CLI clients running, covering each other's disk access downtime, it still averaged around 10 hours per WU. Only a bit faster than the OS 9 3.0 GUI client.

For now I have gone back to the OS 9 2.03 client and the under-8 hour times that come with it. If anyone has the 2.04 installer lying around, please email.

I will keep my OS X clients in work units for whenever I am in X. That is also good coverage against server outages. And it does not have the 2% overhead that Seti Unit Manager imposes.

Whenever they cut off the 2.x GUI Mac client, I will go back to mostly CLI crunching. It seems a little bit faster than OS 9 3.0 and works better for those of us without full time internet connections.