1) Message boards : Number crunching : Versions for x86_64 platforms avaible ? (Message 16213)
Posted 3 Feb 2007 by Travis DJ
Post:
It's good that projects who can benefit from it are. The only benefit that I still see for sixtrack is if it were a 64-bit binary it would only make it "native" so to speak for 64-bit OSes. Performance in sixtrack is dependent on floating point ops and those are way beyond 64-bit calculations.

I'd venture to guess perhaps a -2% - +2% change in speed for sixtrack as 64-bit. Any change would be minor. However, if a reliable way for sixtrack to use SSE instrucitons were to be found, there could be significant speed increases. Oh well.. another battered topic. :)
2) Message boards : Number crunching : Wide variation in credit claims (Message 15275)
Posted 1 Nov 2006 by Travis DJ
Post:
One of the reasons you might notice this now is that for the first time in several months we're getting WUs again. Several months is a long time for multi-core processors to hit the consumer space and work their way in so there are more of those CPUs here on LHC now. So it wouldn't have been as obvious. This problem isn't new, it's only something that hasn't been observed here for the reasons mentioned until now. No biggie, they can "fix" it (I use the term lightly).
3) Message boards : Number crunching : New computer database entry created on each connect (Message 15256)
Posted 31 Oct 2006 by Travis DJ
Post:

1. Stop BOINC.


Quick Tip:

To actually stop BOINC (as opposed to simply closing the BOINC Manager), go to Start -> Run. In the box type "net stop boinc" (without the quotes) then click ok. A box will appear and disappear.

To Start BOINC again, go to Start -> Run. In the box type "net start boinc" (without the quotes) then click ok. A box will appear and disappear.

Stop BOINC: Start -> Run; "net stop boinc" [ok]
Start BOINC: Start -> Run; "net start boinc" [ok]
4) Message boards : Number crunching : Wide variation in credit claims (Message 15255)
Posted 31 Oct 2006 by Travis DJ
Post:
If you take the time to look at the computers crunching the workunits you'll discover a few things.. in this WU that you mentioned take a look at computer 2207997 and computer 2106539.

What you'll notice is the 1st is a Pentium-M 1.6GHz machine (identical to what I have). The 2nd is a Centrino Core Duo T2300. Dual core CPUs get less credit per workunit here at LHC. There is also a Pentium 4 on that WU with a similar claimed credit, which likely means HyperThreading is enabled on that machine. If the admins don't tweak the credit system here at LHC, dual, quad and so on machine will keep receiving less and less credit per WU. It has to do with the way time is calculated.. 2 cores = double time, 4 cores = quadruple time, etc. That roughly halves (or more) the credit. Rosetta et al have also dealt with this problem, search their boards for some insight.

Credit as far as BOINC is concerned is being generated correctly. The current system doesn't assign credit fairly to more than 1-core processors. Either way the SCIENCE of LHC is (and should be) most important here. When (if) things get back into full swing, they'll most likely address it.

My 2 cents..
5) Message boards : Number crunching : Versions for x86_64 platforms avaible ? (Message 15113)
Posted 16 Oct 2006 by Travis DJ
Post:
Good point. And unfortunately it appears from what I've read that sixtrack wouldn't be well suited for GPU (Stream) processing either - for the same reason why it doesn't use MMX or SSEx.

The memory interface on the latest RD600 ATI chips is 512-bit on GDDR4 @2GHZ - the amount of lookups it can do in a second is astounding. nVidia will be behind once those chips end up on the shelf to buy (384-bit memory interface) .. for a few months at least. Competition is splendid. :)
6) Message boards : Number crunching : Versions for x86_64 platforms avaible ? (Message 15104)
Posted 15 Oct 2006 by Travis DJ
Post:
However, as I understand it, a 64 bit machine still gives you faster fetching of program code (8 bytes at a time instead of 4) and faster fetch and store of those douple precision floats that sixtrack so loves. In other words it is the wider bus between RAM and cache that makes the most useful difference to sixtrack.


I'd put my money on it being a key architectural enhancement between generations of CPUs. A wider bus would be software independent. Just like Intel's Macro-Op fusion in Core2 products: The tech is bit & software independent and allows certain instructions to be paired and executed simultaneously in 32 or 64 mode. Pentium M didn't have that tech.

7) Message boards : Number crunching : Versions for x86_64 platforms avaible ? (Message 15070)
Posted 12 Oct 2006 by Travis DJ
Post:
This topic seems to get asked over and over again .. the "64-bitness" refers to integer functions .. which explains the larger physical, virtual, and register memory sizes - and potentially faster integer functions. The thing about Sixtrack is the important parts of it aren't ran on the integer (ALU) but rather in the Floating-Point Unit (FPU). The FPU has 80-bit registers going back into the days of the 386DX series CPUs, IIRC.

Reasons why a 64-Bit native Sixtrack doesn't make sense:
1) the bulk of the work is executed in the FPU (up to 80-bit registers)
2) all 64 & 32 bit OSes for the x86 platform run 32-bit applications
3) the calculations are somewhat FPU specific (i.e. no PowerPC version)

..porting and testing for a 64-bit native applcation where no visible or only marginal performance boost is seen is not worth it. The real beauty is in MMX/SSEx computing, especially on a 64-bit x86 CPU. This topic has also been covered to some extent. However, Sixtrack produces unreliable results when MMX or SSE1-4 is used in 32-bit mode; imagine the results when additional and larger registers are introduced due to 64-bit enhancements that have to be accounted for. That is how sensitive this program is. Steam processing is not for every application.

Trust me I'm all about progress, doing things faster and better. In this case the tradeoff for those speedups is precision and that's what matters most. It would suck to blowout a section of the LHC when it goes live because the math was wrong.. it happened to NASA with the Mars Climate Orbiter when it crashed into Mars in 1999 where part of its mathematical programming was in English Units and the rest in Metric. :)
8) Message boards : Number crunching : LHC@home Alpha petition (Message 14875)
Posted 26 Sep 2006 by Travis DJ
Post:
FWIW- LittleBouncer made a very good observation - LHC@Home Alpha has been down since 9/20/2006 and is still unreachable. It makes little sense for only that reason to start a petition to "open it up" when it's not even available. Like some of the other posts on this subject I agree wholeheartedly with River, Ledi, and Gaspode. I realize that by allowing those WUs to run on my machine may make it crash, lockup, or any number of undesirable things. Those undesirables go against the intention of BOINC (A fully working distributed computing network) and thus should be controlled to some extent. Besides, LHC Alpha has been doing nothing useful for over a year now. IMHO, with all the in-house testing with LHC@Home at CERN there seems to be not much of a reason for a public alpha site at this time. As always, I would love to be corrected by someone who works with LHC@Home..
9) Message boards : Number crunching : Status of LHC Alpha? (Message 14667)
Posted 20 Sep 2006 by Travis DJ
Post:
When I looked at BOINCStats I noticed LHC-Alpha didn't update today and the server does not respond on the web or to BOINC.

The thought occured to me the site has long since fulfilled its purpose and possibly there may no longer be a need for a public alpha site. My curious mind would like to know what has become of it. :)

Trav
10) Message boards : Number crunching : LHC@home Alpha? (Message 14248)
Posted 7 Jul 2006 by Travis DJ
Post:
Which is the proper release version of BOINC to use with LHC@home Alpha??


I'm using 5.4.9 without problems. Shouldn't this question be posted here instead?


11) Message boards : Number crunching : Discepency in Credits? (Message 14178)
Posted 24 Jun 2006 by Travis DJ
Post:
To throw in my two cents:

Could the problem LHC is experiencing with multiple host-ids be contributing to this symptom? It seems it might make sense if the servers are no longer able to track which hosts a user has due to the hosts issue.
12) Message boards : Number crunching : Still can't upload! (Message 14140)
Posted 23 Jun 2006 by Travis DJ
Post:
All I did yesterday to get it communicating again was to go into my DNS cache and remove the entries for lhcathome-sched1.cern.ch and lhcathome.cern.ch. Then the new addresses were picked up right away.
:)


In English (on windows 2k/xp machines):

1) Start -> Run -> type "ipconfig /flushdns"

A box will appear and disappear. All stored dns entries are emptied and will be automatically refreshed. :)
13) Message boards : Number crunching : Stuck resullts in database?? (Message 14004)
Posted 16 Jun 2006 by Travis DJ
Post:
I'll do my best to answer your question and try not to giggle while I type...

The simple answer to your restated question is "no" - no orphaned records are going to be cleaned up/purged/regurgitated/etc for the above reason and reasons stated in other threads.
14) Message boards : Number crunching : ??what does average turnaround time mean?? (Message 14003)
Posted 16 Jun 2006 by Travis DJ
Post:
Average Turnaround Time is an average of the amount of time between when one of your hosts downloads a work unit, crunches it, and reports it back.

There is a bug with ATT here at LHC. I have a few computers who report their ATT is 236378.64 days.

Basically I wouldn't trust the ATT on this project. It's no big deal and the scheduler here doesn't take ATT into consideration when sending out work.

15) Message boards : Number crunching : New host id being created at each connect (Message 13988)
Posted 15 Jun 2006 by Travis DJ
Post:
I don't believe that BAM in and of itself is a culprit, either. Your #2 choice is the best one, though.
16) Message boards : Number crunching : Stuck resullts in database?? (Message 13987)
Posted 15 Jun 2006 by Travis DJ
Post:
Upon first glance, my answer to you is "yes."

As reported in other threads, without a project admin to work on these things and the fact that as things are in their current shape on the servers, attempting to manually fix the problem WUs may introduce more problems.

Patience is a virtue. :)
17) Message boards : Number crunching : Solution for LHC Long Term debt problem ? (Message 13915)
Posted 10 Jun 2006 by Travis DJ
Post:
Or you could get Boinc Debt Viewer . It has a feature that allows your to reset your debts with the click of a button.


That utility sure does simplify that process. It's kinda cool for those who need it. :)
18) Message boards : Number crunching : Solution for LHC Long Term debt problem ? (Message 13907)
Posted 9 Jun 2006 by Travis DJ
Post:
Does any newer Version of BOINC fix this annoying Problem ?


Honestly, I don't know. The 5.4.x BOINC client updates have to do with network connectivity, security, screen saver and performance enhancements. My observations on 5.4.9:

1) I'm attached to 5 projects
2) LHC & Rosetta RS:10
3) Einstein, CPDN, and LHC-Alpha RS:1
4) Connect to network set at 0.1 days
5) There's always work for all projects who are issuing work in my tasks with respect to project settings, WU Deadlines, and LTD
6) When LHC issues WUs, BOINC works off the LTD as best it can with respect to project settings and WU deadlines
7) I haven't experienced the problem you're describing on this or prior versions of BOINC

FWIW, you don't have to continually reset your projects to get the LTD to disappear. You can manually remove it if you choose. If you're running BOINC as a service try this:

* Go to Start -> Run -> Type "net stop boinc" and click ok
* Close the Boinc Manager if it's open
* Find your BOINC folder in Program Files and then locate client_state.xml
* Right-Click on it and choose Edit (It should open in notepad)
* Look for LHC@Home's section and find the <long_term_debt>xxxx</long_term_debt>
* Replace xxxx with 0.000000
* Save & Exit Notepad
* Go to Start -> Run -> Type "net start boinc" *done*

If you're running BOINC only while the user is logged in, Just Exit the Boinc manager and skip the net start/stop commands.
19) Message boards : Number crunching : dual core chips and BOINC (Message 13880)
Posted 4 Jun 2006 by Travis DJ
Post:
FWIW I won't now be upgrading anything until Microsoft releases a proper requirements list for Vista.


You said it, bro. And while I'm on the tangent of Vista.. doesn't it worry anyone that Microsoft has not only taken an extra 2 years to release an OS but in that timeframe can't finalize the specs for DirectX10 or Vista? If I were some vendor like Best Buy or NewEgg I'd be fuming right now -- users don't know what to buy, products aren't selling quickly, the CPU market bombed (at least for Intel; their sales are down 52% y/y, but it's Intel's fault) and users who buy things now may end up in a position where their hardware won't allow them to fully utilize the more premium versions of Vista. But not only that, I wonder if there will be some kind of damage to any vendor's image when Vista is finally released due to those reasons. </rant>

20) Message boards : Number crunching : Server problems (Message 13732)
Posted 25 May 2006 by Travis DJ
Post:
I think the key to proper operation is to make sure that all projects have the same email addy and password and then using this same email addy and password for BAM.


You know, I had read that and I had forgotten BOINC projects could have passwords. I was a victim of not keeping up with the times; BOINC projs. didn't have passwords when I joined up! Even after setting all the projects I have or do participate in to the same pw that I use on BAM it still hasn't ever worked.


Next 20


©2024 CERN