41) Message boards : Number crunching : sixtrack 4.67 is being bad (Message 12876)
Posted 25 Feb 2006 by Travis DJ
Post:
Which is the offending host? You have two active W2K hosts.
Have you run a RAM diagnostic? (www.memtest.org)
Has the hardware changed in the host?
Are your drivers/BIOS up to date?
Did it occur after a Windows Automatic Update?
Is your antivirus up to date/which is it/do you run AV?
Was there a sudden change to any firewall configuration?
Is your hard drive failing? (www.seagate.com/support/disc/asp/tools/en)

There are too many symptoms that could cause an application to lock up without knowing more information. Could you let me know some more info and maybe I can help you more. Good Luck.
42) Message boards : Number crunching : Host 107106 trying to cheat? (Message 12733)
Posted 14 Feb 2006 by Travis DJ
Post:
Have a 3200+ on XP that refuses to complete a valid work unit, it just crunches for einstein and seti now.


Winman- what's your motherboard & bios revision? AthlonXP 3200+ cpus do not overclock well at all (it's the 400mhz fsb that pushes it so hard) and some motherboards have been known to set the fsb a wee bit too high. My Biostar M7NCD mobo would cause the 3200+ to do weird things if it was set as high as 402mhz fsb. Another factor could be your ram which is also coupled to the fsb. Needless to say there was no OC potential with the 3200+ but man does it perform for a Socket-A cpu.
43) Message boards : Number crunching : @Admin: Release optimised Clients? (Message 12476)
Posted 27 Jan 2006 by Travis DJ
Post:
I can understand but aren't there fale safes.
If you see at d.net they have made there clients go many times faster.
last update was 40% increase, even for p3's :DDDDD


d.net uses integer math in their RC5 & OGR calculations. Fixed-size numbers, no floating point, IIRC. All the RC5 cores basically do bitshifting routines to compare keycodes in sequence from one to .. however many billions of billions of combinations for the 72-bit contest. Some of their cores use SSE/2 on supported platforms because of their register size (128-bit SSE registers) making it faster to do the math .. general purpose registers are 8 or 16 bit. So, you can see the advantage of storing the data in a SSE register vs several smaller ones.

The difference is LHC is highly floating-point intensive. Yes, SSE does do floating point calculations "better" (depending on point of view) however they've experienced variation in the results amongst various CPUs when SSE was used, which is a no-no for scientific work.
44) Message boards : Number crunching : @Admin: Release optimised Clients? (Message 12465)
Posted 26 Jan 2006 by Travis DJ
Post:
@Perle
We wouldnt want to provide erroneus data and have LHC accidently create a black hole.


See this thread. They DO want to create black holes even if by accident I would presume.

As for optimization, 64-bit, SSE/2/3.. the tradeoff is accuracy vs. speed. I can't find the forum post, however the LHC dev team had changed fortran compilers over time and due to just that change, performance boots had been noticed without having to add other instruction sets (i.e. major modification).

Sorry for my bad English, I am a tribble.
45) Message boards : Number crunching : Database Errors (Message 12061)
Posted 15 Jan 2006 by Travis DJ
Post:
I'm very glad to know that deleting a host doesn't affect user credit. :)

There are some old hosts I've wanted to do that to..

46) Message boards : Number crunching : Database Errors (Message 11975)
Posted 14 Jan 2006 by Travis DJ
Post:
I did look at your hosts. :)

Unless you want your user account to be shorted 6,330.41 credits if the affected host were removed (because it can not be merged), then I wouldn't worry about it.
47) Message boards : Number crunching : Database Errors (Message 11973)
Posted 14 Jan 2006 by Travis DJ
Post:
I had 9 computers which exhibited the same problem you mentioned back in the same timeframe. What I didn't "get" when you first posted your question was that you had reloaded with a new OS.

You'll never be able to merge those two hosts because of the difference in the database between what you know is right and what the database thinks is right. The database entry may have invalid data in it (IIRC it was using your LTD in place of other fields as appropriate, hence the numbers instead of "Microsoft Windows...") but the enrty is valid as far as the database was concerned. If your host was available as it was back in August, then yes the reset your client suggestion would have cleared that entry up and you would have been able to reload, give it the same name, then merge away to your heart's delight.

To clarify:
1) The database does have wrong host information in it
2) Those entries are valid as far as the database is concerned
3) No chance at merging ;(
4) They do need to expunge such entries, however doing so would alter the total amounts of credits have been issued once those hosts have been removed (BadThing™).
48) Message boards : Number crunching : Database Errors (Message 11970)
Posted 14 Jan 2006 by Travis DJ
Post:
In another post, long, long ago....

The fix is to reset your clients. After then you can check your computers on the LHC website and the information should show up correctly then. If not, wait a minute then wash, rinse, repeat.

Some people have WUs that will never receive credit. Last time I heard, it was a very low priority problem. I wouldn't worry about it.
49) Message boards : Number crunching : New work when? (Message 11790)
Posted 3 Jan 2006 by Travis DJ
Post:
...there is no 'Magic Button' that makes work.


You're right, but if I go down to visit the local Staples I can buy an "Easy" Button.. :)


50) Message boards : Number crunching : can't download (Message 11746)
Posted 27 Dec 2005 by Travis DJ
Post:
Their servers appear fine:

(Log)
12/27/2005 12:56:59 PM|LHC@home|Fetching master file
12/27/2005 12:57:04 PM|LHC@home|Master file download succeeded
12/27/2005 12:57:10 PM|LHC@home|Sending scheduler request to http://lhcathome-sched1.cern.ch/scheduler/cgi
12/27/2005 12:57:10 PM|LHC@home|Reason: Requested by user
12/27/2005 12:57:10 PM|LHC@home|Requesting 8640 seconds of new work
12/27/2005 12:57:15 PM|LHC@home|Scheduler request to http://lhcathome-sched1.cern.ch/scheduler/cgi succeeded
12/27/2005 12:57:25 PM|LHC@home|Sending scheduler request to http://lhcathome-sched1.cern.ch/scheduler/cgi
12/27/2005 12:57:25 PM|LHC@home|Reason: To fetch work
12/27/2005 12:57:25 PM|LHC@home|Requesting 8640 seconds of new work
12/27/2005 12:57:30 PM|LHC@home|Scheduler request to http://lhcathome-sched1.cern.ch/scheduler/cgi succeeded
12/27/2005 12:57:30 PM|LHC@home|No work from project

There's no work until after the new year, but you should still be able to connect. Perhaps you have a firewall application? Good luck.
51) Message boards : Number crunching : Boinc farms. (Message 11637)
Posted 10 Dec 2005 by Travis DJ
Post:
I wish there was some form of "boinc remote access" so I could manage projects and attach machines to projects remotely. Many of these machines are across town or out of state. Calling up Grandpa and trying to walk him through the process is futile, working the email is the limit of his PC prowess.


Visit the Unofficial Boinc Wiki .. or just click here for a link to the article that answers your wish.

I realize your setup will indeed be more complicated than the article describes as it doesn't go into what's necessary to connect to your machines across state. Hint: You'll need to register with a dynamic DNS and installa monitoring client amongst other things. Good Luck. It's not impossible if you have the right information.
52) Message boards : Number crunching : Screensaver lockups (yes, that again) (Message 11548)
Posted 2 Dec 2005 by Travis DJ
Post:
Paul,

I did a google search in the Wiki and only found the criteria "local system account" in two places, within the CPDN FAQ on how-to install at the command line as a service. Couldn't find anything that referred to setting BOINC to run as a service under the LSA (with Interact w/ Desktop privileges) instead of a user with admin privileges. The LHC@Home FAQ didn't mention it at all. Could you point me in the right direction?
53) Message boards : Number crunching : Screensaver lockups (yes, that again) (Message 11545)
Posted 2 Dec 2005 by Travis DJ
Post:
I have done it ... and it works. how do you think i got all the images for the Wiki? :)


Is this another glorious example of how I should read the Wiki first before putting out my hypothetical ideas.. lol
54) Message boards : Number crunching : New Reccommended Version... (Message 11525)
Posted 30 Nov 2005 by Travis DJ
Post:


exactly all the changes were for the new users to help them connect to the overloaded servers as BOINC got confused it wasn't a problem that could be tested for properly and showed up only due to classic closing


What? Don't they have punctuation where you come from?



last time i looked it wasnt a rule that messages have to be perfect the thing that brings the BOINC boards down is people been arogant and arsey to each other so what if a post doesnt have puncuation you can still read it to see what it says but the puncutation init as you read it if your really so bothered


This makes me giggle. :)
55) Message boards : Number crunching : Screensaver lockups (yes, that again) (Message 11524)
Posted 30 Nov 2005 by Travis DJ
Post:
I'm running BOINC 5.2.7 as a service, and sixtrack 4.67. BOINC is set to be my screen saver and my machine is set to require me to enter a password to unlock it.

HM, if you really run BOINC as a service, it can not display the graphic. This is an unsolved problem.


Yeti,

I'm curious if someone set the BOINC service (In the services console) to log in as "Local System Account" and checked "Allow services to interact with desktop" if that would allow the service to run and display graphics. It's no more a security risk than allowing a user with administrative privileges to run BOINC on XP/2K/2K3 systems. Of course I could follow my own advice and try for myself. :)
56) Message boards : Number crunching : New Reccommended Version... (Message 11513)
Posted 30 Nov 2005 by Travis DJ
Post:
MikeW has a good point and I should do that. :)

Halifax-lad:
That's why development should be done in cycles. Release a beta client, those interested can participate and provide feedback. Changes are made, another beta, more testing, until all known bugs have been removed. Wait for a period of time (say, a week) for unexpected problems. At that time if nothing bad shows up, promote the release to a "stable" version and release it to the masses. If problems are found (which are non-critical) release a new beta and resume the above process. Should a critical problem be found, release a new stable version as soon as possible.

I totally appreciate the efforts that go on behind the scenes in regard to product development, especially under the strain of "unusual" circumstances such as an overloaded server. After reviewing the changelog on the last few clients I can understand the network related updates per seti's problem. Some of the other updates could have waited for a more major version - hopefully they have been thoroughly tested.
57) Message boards : Number crunching : New Reccommended Version... (Message 11508)
Posted 29 Nov 2005 by Travis DJ
Post:
That's what irritates the fire out of me with the BOINC developers..

Their product release cycle is horrendous. It's akin to AOL releasing 9.0.1, two days later 9.0.2, the next day 9.0.3, and after a month they've had 14 releases and are up to 9.1.7. NO ONE would have confidence in that software much less having to install a new AOL every time a "recommended" version is posted.

Why is the official "recommended" boinc client being updated so frequently? Where is the bug testing before releasing it into the wild? It seems completley unprofessional to have updates like that. TEST YER SOFTWARE THOROUGHLY before recommending an entire community of a few hundred thousand users to download it.. then again a few days later.. and again, and again.

There's a reason for development builds and there should be a decisive distinction between the development and production releases. Limewire has an excellent system for beta & public builds. They use an odd/even version numbering system..

/end rant
58) Message boards : Number crunching : new work eta? (Message 11426)
Posted 21 Nov 2005 by Travis DJ
Post:
Like mom always said "We'll get there when we get there"

...and as I'm sure I'll say to my children...

"We'll get there when we get there, play your PSP for a while.."
59) Message boards : Number crunching : project priority ideas. (Message 11401)
Posted 17 Nov 2005 by Travis DJ
Post:
MikeW made an excellent observation. Boinc 5 doesn't need to be configured like that.
60) Message boards : Number crunching : Projects use very little virtual memory? (Message 11356)
Posted 15 Nov 2005 by Travis DJ
Post:
1. if you go away to make some coffee and come back before a checkpoint, then the work BOINC did will be wasted unless the app stays in memory. This can be a reason to keep apps in memory, especially users with a machine that is newer than the versions of the software they usually use (and so have plenty of excess memory available).
False - BOINC doesn't waste any work, it adjusts the time available to projects in accordance with the PC's apparent "idle" time. It will continue to work even during periods of high user activity, albeit proportionately slower to the demand the user creates. The checkpoints occur when they should regardless of the % cpu time available to it. Keeping the app in memory when preempted refers to the BOINC client behavior when LHC is "paused" by another BOINC enabled project, the BOINC client will not unload the LHC project from memory while it's not in use. The result is, on systems with low amounts of ram and many apps running, slower performance while the OS swaps out to the HDD to compensate for lack of memory.
2. if the memory used is needed by your real work (Word or whatever) then it will take a time for the app to be swapped out and your real work swapped back in. This can be a reason to avoid keeping apps in memory, especially users with a machine with onlu just enough memory for the task they normally work on.

Abso-freakin-lutely True :)


Previous 20 · Next 20


©2024 CERN