Just got my daully system today

[stall6g]

Just got my dually system in the mail today and hopefully I'll have enoguh time to play with it and set it up to start genoming before I leave for Pittsburgh tomorrow. Just ahve to finish packing first.:rolleyes: If I can't get it up and running tonight then look for me to be adding it on Sunday night when I return. Hopefully after I get back from Pittsburgh things will calm down enough at work for me to post more on a regular basis again.

[MechCD]

:) Let us know how it runs. Are they regular Tbirds or are they MPs?

[stall6g]

Unfortunately the budget doesn't allow for a dual AMD setup but I figure a dual PIII setup that I hope to get to 2@1 gig should help the cause.;)

[siggy]

Originally posted by stall6g
Just got my dually system in the mail today and hopefully I'll have enoguh time to play with it and set it up to start genoming before I leave for Pittsburgh tomorrow. Just ahve to finish packing first.:rolleyes: If I can't get it up and running tonight then look for me to be adding it on Sunday night when I return. Hopefully after I get back from Pittsburgh things will calm down enough at work for me to post more on a regular basis again.

Good luck with that Stall6g. Make sure you dress light for Pitts. It is a little warmer down here. LB is in PA and I am in VA.

Have a safe trip.:)

[MechCD]

Duallies are cool no matter what!

i want a dual 486 board, or a hex..... wait a sec... her eit comes again

I want a dual or quad or hex ppro 200@233!!!

[siggy]

How does the concept of Duals work. Does it proccess on one and overflow to the other? or does it use both of them at the same time?

[MechCD]

either way, a lil of each cpu or overflow depending how you set it up

[siggy]

So I guess it is cheaper to run Duals, then to have two seperate systems?

[MechCD]

Erm yes, but you need linux or Win2k

it doesn't double the speed, it double the capacity of how many instructions fer mhz your system can do (limited by ram and other stuff of course)

[siggy]

Faster crunching?

[MechCD]

I beleive so. thats why pell's hex (6 cpu) ppro systems do so well

[stall6g]

it's faster in the sense that I will be able to run two separate clients on it utilizing each cpu. either way it will be able to crunch a bit more than a tbird at 1.55 gigs based on the simple fact that it will be running on 2 separate cpus. Just spent that last 2 hours talkng to people on the phone and answering instant messeges so it looks like I won't get around to getting it installed until Sunday.:( Anyone from the Pittsburgh area feel free to drop me a line and tell me where the best places to eat are. As for entertainment that's already booked by going to Pirates and Steeler games everyday. Damn work will be hard this week.:D

[pelligrini]

Originally posted by siggy
How does the concept of Duals work. Does it proccess on one and overflow to the other? or does it use both of them at the same time?
I am not too sure of the really technical stuff, someone please jump in if I am wrong.

As far as genome goes, it will not really use two processors at once. Unless you set the affinity (tell the program to use a certain processor) it will switch around between them, but not really utilizing more than just one can provide. If I run just one client on a dual, Taskmanager will only show 50% CPU utilizaion. You have to ruin a client for each CPU.

Most general applications act the same way, they aren't written to be able to take advantage of SMP. You really wouldn't see much beneifit browsing on a dual 700 compared to a single cpu system, but, If you really multi-task you would see much better performance. Using a program that is written to take advantage of SMP, like Photoshop, 3DS-Max, Autocad, multiple CPU setups are fantastic.

I really haven't read anything specific about it, but I have developed a theory about multiple processor setups, mostly from watching how a program will utilize processors in Windows Taskmanager. Even when running a single threaded program (I believe that is the term} there will be a slight performance increase on a multi-CPU setup. I believe it has a lot to do with the cache. A single PIII has 256k of L2 cache, whille a dual would have 512. If the simple program still switches baack and forth between the processors it would utilize the added cache. My hex systems have 6 cpu's with 512k of cache each, making a total of 3mb of integrated L2. I am starting to believe it is the added cache that makes these multi-cpu systems really perform well.

[Virus]

I have to admit that I find it hard to believe a dual PIII@1ghz will beat a Tbird@1.55. I have an 866PIII at work that takes a full day to do a .99 while my Tbird@1400 does 2.5 a day.

[phil]

Originally posted by Virus
I have to admit that I find it hard to believe a dual PIII@1ghz will beat a Tbird@1.55. I have an 866PIII at work that takes a full day to do a .99 while my Tbird@1400 does 2.5 a day.


Virus, they will do exactly the same in my experience. My dual PIII700@1050 does almost exactly the same work per day as my 1575MHz T-Bird. This may be due to the 150FSB that I am running on the VP6.

[Dave S]

Well my duals do 2 .99 a day'ish *(11.45min)* sorry should be 12:45doh!!! each CPU, as said it because of the 150FSB there running at (1125) [But it varies from CPU to CPU and System to System]

I mean look at my numbers 3k a week on 10 1Ghz CPU's (all Intel), not bad when you look around and see wot the people (not just here) are running 2x my Ghz but not 2x my numbers!!! Even looking around at ppl who are close to me in Ghz their still down on me GHz to GHz CPU to CPU v numbers, i think it just getting it setup right that help a lot!!!

But hey who knows, but all I know it works for me.

Please note I am not having ago at anybody or wot their using just stating facts..........soooooo please don’t burn me toooooo much ok :)

[MechCD]

Cough ahem

I'm thinking the linux client supports SMP without dual clients running ahem cough

dnar corect me if i'm spurting absolute nonsense from my word hole

[wbierman]

There is no way on this planet that a PIII @ 1GHz can beat an AMD 1.4GHz OCed to 1.5GHz. A Dual PIII can crunch twice as many as a single T-bird only because it can run 2 Genome clients at once.

You peeps should read the revieve at Anandtech on the Super Cooled 1.4GHz OCed to 1.86GHz! It was running circles around everything including the dual CPU comparisions.

Yes a P4 1.5 is faster at games than an AMD 1.4. Genome in not a game and they crunch faster than any P4.

Take Pells output and divide by his 48 CPUs: 5,680 /48= 118.33 per CPU per week.


Take my output and divide by my 7 CPUs: 1,550 / 7= 221.43 per CPU per week.

My CPUs average better output than his....Pell just has more of them than me. All mine are AMD..most of his are Intel...

[pelligrini]

Most of those are socket 8's on a 66mhz bus too.

[Jodie]

Okey... It's time to set the record straight here...

A given task is (in modern programming) split into threads. A thread is a single execution path. That could be split based on instructions or on functions, etc.

A dual (quad/hex/oct/etc) system, in a perfect world, would have two threads running simultaneously for one task. This isn't the case. You've got hundreds, even thousands of simultaneous threads to be looked at in a modern OS. So they 'switch' in and out of the processor (at 17x/sec. if they were all set at equal priority) In something like Genome@Home which isn't optimized for SMP or windows broken MP systems, it executes one task at a time. The reason a dual running one client will run faster than a single processor at even double the Mhz is that one processor will be devoted ENTIRELY to G@H client while the other will handle house keeping, running and updating the OS/screen drivers, etc. A dual running two G@H clients that are set to maximum priority, will run marginally faster than two singles. Why? Because there's not 100% processor utilization - you have 'breaks in the threads.' During those breaks, OS updates and housekeeping will happen. That's why a hex performs so darned well - there's enough breaks in 6 simultaneous tasks to maintain the housekeeping without switching the client context out very often. Just simple statistics there.

(I saw some Oct 1.7G Xeons today, that's right,EIGHT 1.7 Ghz processors on a board - drool)

Synchronos Multi Processing is a complex process - not many operating systems get it right, and few scale over 4-8 processors well. Instead of 600% for a hex, you often see like 580% (on a good one) The Cray was able to run a non-SMP task soooo darned well because it did it in hardware rather than in software - an application not written to SMP still was split over 512 or so processors in the case of the T3E, and a hardware gaussian matrices elimination machine used to reassemble the results. True massive parallelism which we don't see too often. NCube was another good one for it.

Generally, I like 2proc or larger systems just for the space savings and the cost savings of not duplicating HD, OS, memory, etc. But remember that a hex machine shares the SAME 66mhz bus for all six processors. In a worse case scenario of everything trying to get to memory at once, you've got 11mhz bus speed per processor.

Gosh, rereading that, it seems clear as mud... Sigh. I spent two semesters in the MS/CS program at Cal Berzerkeley mastering it, guess it's tough to explain in one smallish post...

[wbierman]

Interesting....

So processor affinity means nothing? Or I can't run two seperate Genome clients concurrently on a dual CPU system?

Please clarify Jodie.....

[Jodie]

Originally posted by wbierman
Interesting....

So processor affinity means nothing? Or I can't run two seperate Genome clients concurrently on a dual CPU system?

Please clarify Jodie.....

I don't understand your misunderstanding.

"Processor Affinity" is a broken SMP model. It says "Always assign all threads from this process to this processor, come hell or high water. I think I'm smarter than the Operating System even though the OS can examine my stack seventeen times a second."

It is the equivalent of saying "Always always always treat this as if it were two separate machines, each with one processor. (or some combination there-of if it's a multi-proc >2)

Why are you suggesting you can't run two separate clients concurrently? They are single-threaded apps. (Effectively) So the OS (assuming affinity is left alone, or assume true SMP) is going to run them at as close to whatever the priority is set at as it can. If you set one of the to the highest possible priority and the second to a lower priority, the second processor will get the vast majority of the housekeeping tasks as well as the client task. So the second client will naturally run slower even if you do NOTHING on the machine. If they're both set to the highest priority, the OS housekeeping simply won't get done for the most part, as it runs a low priority thread(s). Try setting both clients to "realtime" on W2K and then close a third window. Or even move your mouse. - The screen update gets trashed. That is an illustrative example of why running one high and one low causes the low-priority client to run even lower than expected. What it really means is: "Each processor is sliced and diced into 17 pieces every second. Bottom priority means that I can take 1/17 context or more if available. Top priority means I get 16 or even 17 contexts and everything else gets suspended until I give some back" That's why you generally want to let the OS deciding on its own, especially if it has a good context-model. (Look, for example, at Win3/95-vs-Win98-vs-NT/2k. Win 3, and largely 95, was "cooperative multitasking", meaning that a runaway app could ruin your whole day. Today's Windows are truely multitasking, up until you start playing with the priority and affinity...

My statement that you get 11Mhz to the bus off of a worse-case scenario on a 6 proc machine is that you still have ONE northgate and ONE southgate. If all six processors hit your southgate at the same time, they're going to bottleneck. You don't suddenly grow 396Mhz (6x66) just because you hucked 6 processors onto a board. The Cray architecture was sooooo hot because it had nothing resembling the bus controllers on our boards - it had a massive fabric'd backplane. Capable of moving hundreds or even thousands of terrabits/second. It was a parallel fabric rather than a serial bus like our northgate/southgate...

Do I explain myself better here?

[phil]

Originally posted by Jodie
Do I explain myself better here?


erm...could you repeat that please?


hehe, just joking :D

[Jodie]

Originally posted by phil



erm...could you repeat that please?



Nope, sure couldn't... Try the Cut/Paste function...


hehe, just joking :D

SUUUURE you are...

:p :p :p

[wbierman]

Do I understand beter? Yes and no. There is much I do not understand.

When I look at Performance Monitor I see several things.

Handles: 7892

Threads: 432

Processes: 34

The CPU meter is pegged 100%. I also see spikes every so often of the Kernel time (I guess thats the housekeeping functions).

If a single CPU can run a single genome client in a single CPU machine and suck 99% of CPU cycles, then why not 2 genome clients assigned seperate CPUs in a dual box each sucking 99% of their respective CPUs?

Is this possible or am I completely off track? Should I go back to reading comics and finger painting?

[viperdog]

First time I've ever heard it called "the broken SMP model"...gee I never knew it was fixed!

The only thing I own that is truely multi-threaded is a sweater..:D

---and I have my doubts about that..

[Jodie]

We're getting there!

Two genome clients, with their respective "affinity" set one for each task would allow each one to run close to the 99% mark that you speak of, under normal or below priority. However, running both them associated with both processors will allow one or the other to pick-up slack as the 'housekeeping' (yes, kernel threads are one of those) comes up. IE if you've already context'd out to do something on one processor, you might as well give another slice away - context switching is generally the slowest part. Of course the way around all of that is to set your affinity and set each process to be "realtime" so NOTHING else happens unless it can be squeeeeezed in. Half the time, the mouse doesn't even move. Each of my clients sucks down 100% of the processor...

This assumes perfect scalability and perfect MP modeling. Not always true - I prefer true SMP myself, but won't argue that one. What I will say is no OS scales 100%. But at 2procs, it's sooo darned close as to hardly make a difference in this discussion.

[Jodie]

Originally posted by viperdog
First time I've ever heard it called "the broken SMP model"...gee I never knew it was fixed!

The only thing I own that is truely multi-threaded is a sweater..:D

---and I have my doubts about that..

There are various SMP schemes out there, some better than others...

Hey, viper... What's this thread on your back? Here, let me pull it off... OOPS! I guess it WAS single threaded...

[wbierman]

So is Pell running a single genome client on his 6x6s or multiple clients?

[MikeTimbers]

I have t2o clients running on a dual-processor HP Server. AT first, I manually set the affinity so that each had its own processor and left the priority at idle.

Recently, I have just let the OS handle them and I have seen no difference whatsoever. This proves (allegedly) Jodie's supposition that the OS can handle it.

[phil]

I also let the OS handle it....I have never found any difference running either way.

[Jodie]

Originally posted by wbierman
So is Pell running a single genome client on his 6x6s or multiple clients?

He would be running six clients - due to the fact that the genome client isn't optimized for multi-proc usage (same with Seti, incidentally) That's why they came up with the file-locking scheme - to allow multi-clients to run in different directories but protect us from ourselves. (and the subsequent data corruption) Ideally, it would be written to split the single task across multiple processors. The improvement would probably be 2.5x on a 2 processor system. (little or no penalty for the context switch)