• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

For those of you running Linux...

...You might want to take a look at this.

I asked here first and heard that Wine ran the Windows Seti client much faster than the Linux binary ran natively. Sounded like a lot of effort though, so I just ran the Linux CLI on Linux here once I converted the machine from Win2k.

Anyway, I decided to switch over today, and the image linked to earlier shows the impact. The first 2 listings are for the wine emulated binaries running right now (dual-processor box). The third is the results from looking at the old Linux directory.

Look promising?

Anyway, the secret was simple (Redhat 7.2):
1) create a ".wine" directory in my home directory
2) "wine ./setiathome-3.xxxxyyyyyzzzz.exe"to run the program with the long name. 😉
3) "ps -ef | grep seti" to find the process ID's
4) "renice 19 <PID>" to make sure they're only consuming idle CPU cycles.

Let me know if this helps anyone. I'm still relatively new here and this may be old hat to most of y'all.

Oh yeah -- set times under WIn2k were a touch under 8 hours/WU.
 
Hi Southerner!

First, are all those WUs that are running, the same angle range (AR)? That will make a difference in the times due to the fact that certain analyses are only performed on certain AR WUs. Also, is the dually a Xeon or other? What's the cache size on the dually?

All of this will make a major difference in times with either client, ie., the win CLI runs VLAR (very low angle range) WUs much slower than the "mid" angles, when compared to every other non-wintel client. This would apply to running the CLI in WINE as well. Second, all clients will run VHAR (very high angle range) WUs much faster than the mids.

Whenever we've benched, we'll grab the Ars TLC benchmark WU, which was selected due to the fact that not only are most of the SETI analyses done on that AR of WU, but that WU has the highest incidence of distribution (~13% of the total) of any WU given out by the SETI data servers.

Hopefully this will help in accurately determining how well your system is doing when comparing the various clients. 🙂
 
Looks like I'm going to be crunching that WU a couple of times then. 😉

Question: any reason not to benchmark both clients at the same time on my duallie box?

 
Question: any reason not to benchmark both clients at the same time on my duallie box?

You still didn't answer my question, bum!!!!!!! 😛

Is that a dual PPro? A dual PII? A dual PIII? A dual Xeon II or III? Dual Atlhlon???? 😛 Running 2 WUs on anything other than a processor with cache 1MB or greater will mean that the times taken for 2 results will be longer than running both separate and adding them!

And It WILL make a difference with linux benching 2 WUs on the same system (including having 1 run in WINE) because linux doesn't let you set affinity like winblows. Thus there will be sharing across both CPUs.
 
It's a dual 933 MHz P-III -- one of the Gateway 6400's from a while back ($420 shipped?)

Oooo... I heard about that! 😀

Well... you'll find that running 2 processes of SETI on that will give you individual times that will be just a little longer than if you ran them separately on the same speed processor. This is due to the SETI data set not fitting in the PIII's 256K cache, thus it dumps to RAM and then both CPUs will be fighting over that RAM.

Yeah... benching is HARD work and you lose production while you do it... But it at least gives you an idea of how well your system (and OS) is functioning. 🙂
 
Cool. So here's the question I should have started this with.

I'm running Redhat 7.2 on my main WU-crunching box (2x 933 PIII), and I'd like to determine (empirically) the most efficient way to knock out WU's.

What's the best way to do this?
 
Run 2 processes of the win CLI in WINE and pray you don't get any VLAR WUs. 🙂

{Edit: If you have another machine running just windoze, you could have Setiqueue on it, run one linux client + run WINE /w the CLI on the dually, and have Setiqueue reroute the VLAR WUs to the linux client]
 
I've recently done a little testing on my dual pIII 550/512k machine under Redhat 7.2.

I ran the i686 linux binary on both processors and got these results in SETIq:

2002 Jan 13 05:31pm 6.322,18.01 0.417 192.168.0.2 13:10
2002 Jan 13 03:54pm 0.409,18.01 0.417 192.168.0.2 13:13
2002 Jan 13 04:17am 17.11,8.98 0.602 192.168.0.2 13:13
2002 Jan 13 02:38am 18.256,10.76 0.555 192.168.0.2 12:59
2002 Jan 12 03:00pm 1.161,16.84 0.421 192.168.0.2 13:17
2002 Jan 12 01:36pm 1.139,16.84 0.421 192.168.0.2 13:20


Then I switched to WINE (not running X-win, and in nt2k emulation mode) and the winnt386 binary on both processors and got this:

2002 Jan 15 07:50am 9.29,8.63 1.739 192.168.0.2 9:58
2002 Jan 15 07:40am 2.785,18.01 0.417 192.168.0.2 11:54
2002 Jan 14 09:52pm 0.528,10.28 1.133 192.168.0.2 10:16
2002 Jan 14 07:21pm 0.398,10.97 1.416 192.168.0.2 10:11
2002 Jan 14 11:35am 8.482,18.01 0.417 192.168.0.2 11:57
2002 Jan 14 09:10am 1.138,22.58 5.74 192.168.0.2 9:57
2002 Jan 15 08:02pm 0.692,9.54 0.433 192.168.0.2 11h46m
2002 Jan 15 07:36pm 16.802,8.9 0.696 192.168.0.2 11h31m

Note these are not the same workunits during the test (I didnt want to lose production 😀), but it gives a good idea how much faster the WINE/winnt combo is compared to linux binaries.

-SETIdude
 
Hrm. I'll have to see how Wine+NT/2k CLI works on my systems... I wonder how big of a difference it'll make when running 6 processes.
 
I've made a post with the same message.. Only I have found it out myself 😛
It is true though. It takes more then 3 ours less on my system.. that's more then
20% of the time it usually takes!
I really wonder why this is possible.. You should say that it would be slower.
 
Back
Top