stephenbrooks.orgForumMuon1GeneralLinux client
Username: Password:
Search site:
Subscribe to thread via RSS
AlArenal
2007-03-27 11:45:41
I remember the days when there was a command line client for Linux.  I mean, I have so much CPU power controlled by Linux I'd like to dedicate to Muon but there's no way of doing it anymore

If I can I'd like to assist porting the code.  Maybe I could even get it to work on my SGI workstations? 

Noone else out there who'd be interested in a Linux client?
Pascal
2007-03-28 17:27:00
This has already been discussed years ago.  Because of the used DirectX code from Microsoft it is not that simple at all and since most participants have MS systems, there was and is no real necessity to bring a linux client. 
There was another thing discussed years ago, the client in version 5. Up to now nothing has happened. 
But this is only my point of view. 

Whats going on with the project?
AlArenal
2007-03-28 19:00:26
That makes sense regarding the graphical client.  But I don't care about eye candy.  I don't run muon because I like to spend 16 hours a day watching stuff go on on my screen

The linux boxes would be servers that idle around >95% of the time.  It's about my willingness to contribute, not because I want to hang 300 TFTs on my walls and watch all the muons fly
Pascal
2007-03-28 19:51:53
Oh, I forgot.  The text client also uses DirectX components for the simulation. 
AlArenal
2007-03-28 20:29:09
I don't know much about DirectX coding but I can't imagine where one would use DirectX for scientific computation.  There have been 4.3 Linux ports of the command line client: http://www.rdservice.de/lang/download/german (scroll to bottom)
Pascal
2007-03-28 21:22:32
Muon uses definitely DirectX in its clients.  And the only one who has the actual code is Stephen Brooks and that is his job.
I know that in former times as mentioned above he did not know much about Linux.
Stephen himself can say more about this.  Everything else is speculation.
Stephen Brooks
2007-03-30 11:27:26
The DirectX doesn't actually contribute to the calculation, that's just the graphics(!) The part that may be hardest to port to Linux is the stuff where I have to use the Windows API functions for doing things like sending network commands and downloading files, they'd have to be converted to the Linux equivalents and that would mean lots of testing too.  Project has been standing still for a little bit as I'm supposed to be writing up my DPhil thesis this year! 
Stephen Brooks
2007-03-30 11:28:27
Having said that, I've already ended up replacing some of the Windows APIs by lower-level things written on top of WinSock because the Windows ones were unstable or hung in the case of connection drops and I wanted something a bit more fault-tolerant.
AlArenal
2007-03-30 21:21:16
So what's your personal forecast on the project?  Do you think there's a reasonable chance for a Unix client and what would the timetable look like?  Maybe next year?

I don't know what you changed concerning the platform dependant code between 4.3 and 4.4 but if someone able to port 4.3 that port may be a good source of information...
Pascal
2007-04-03 16:50:41
And what is about version 5 of the client?  Up to now there is no answer to this.  Thanks.
Pascal
2007-04-11 14:25:15
Up to now no answer - I am going away from DPAD for the next months absolutely.  Thanks.
Pascal
2007-04-11 14:28:00
To all others: if you are intelligent, you just leave this project, because there is no real work at the moment.  Rather go on to folding@home, they really need the CPU power.  But please, no overclocking.  That just brings faulty results. 
Velociraptor
2007-04-15 14:22:08
HI!!!

how is the progress on the linux client version?  Isnt it coded in C?  If yes than it should be easy to transfer or not?

Hope for some answers!!  CU
[TA]z
2007-04-16 20:36:09
If a project yields faulty results from overclocked CPUs then there is an inherent flaw in the design of that project.  I would rather not invest my processors' idle power in such a poorly designed system.  When I overclock anything I verify with certainty that it is completely stable.  Granted the majority of overlockers don't necessarily do this, there is still no excuse for a project to lack adequate fault detection.

I'm also not sure why you are under the impression that there is no real work being done at the moment.  The %yield trend speaks for itself.
RGtx
2007-04-16 22:36:35
There is nothing wrong with F@H's error detection, just some overclockers don't seem to mind repetitive EUE (Early Unit Ends), rather blaming the WUs than their unstable platforms.
Pascal
2007-04-17 10:53:46
[TA]z, what is your definition of stability of an overclocked system?  How do you validate it? 
As long as Stephen himself does not anser my question about client version 5, there is nothing to do in my opinion.  I rather fight against diseases with my systems.
waffleironhead
2007-04-17 15:09:38
Pascal: Its one thing to decide that you no longer want to run a project, but I dont see your need to try to convince others to leave the project.  If you are tired of it then by all means leave.  As far as I am concerned there is no reason to update the program versions.  Neither of the optimisations has stalled out(though I was concerned about DecayRot. Typically in the past there was no reason to update the client until there was a reason to try a different optimization. 
UnderTitan
2007-04-22 06:29:27
Why not port a version over to .NET?  A .NET ported MUON1 will run natively on Windows.  It will also run natively on Linux, Mac OS X, Solaris, and Unix with Mono installed.  http://www.mono-project.com/ The project is mature, and supported by Novell, together with the opensource community.  So, it's not going anywhere, just like .NET.  I don't see any argument against a .NET port, unless someone just wanted to make it only work on Windows.... Whatever language it is written in now, there is almost without a doubt, a method to convert the code over to .NET, especially if it's written in a Windows language like C# or VB.
UnderTitan
2007-04-22 06:52:36
by the way, does anyone know which language the program is written in?
Pascal
2007-04-22 11:02:24
The client is written in C.
UnderTitan
2007-04-22 17:21:51
by the way, does anyone know which language the program is written in?
Pascal
2007-04-27 14:52:24
Interesting, up to now Stephen does not like to post in this thread any more. 
K`Tetch
2007-05-12 02:54:07
Pascal - maybe its because your attitude sucks.  What makes you think you're so special to even deserve an answer, especially considering the way you post.  You like folding@home so much, go do it.  Its, mathematically, a small scale, 1st gen project built around the boinc base - ad run by a team of people.  Muon1 is a high variable project run by one person using all custom stuff, and right on the ragged edge of technological simulative progress in this field.  Here's soemthing to ponder, which I've said before - assuming there were only 200 variables, there would be 10^600 possible simulations.  thats a 1 with six hundred zeros.  Distributed.net took 3 1/2 years with rc5-64, to cover 10^15 keys, with 10x the userbase at least, and clients crunching thousands of keys a second.  As waffle says, unless there is a problem with the client, or the designs stall out, theres no need for new versions. 

Undertitan - the main problem, as i understand it, is speed.  .net is ery slow as far as data processing goes.  Somewhere on a par with java, i believe.  Increasing the userbase by 5x is all well and good, but not if you slow the client down 10x. ends up a net loss. 
AlArenal
2008-05-30 00:01:35
Been away from distributed cmputing for quite a while (if you mostly run on battery, you have to be careful)...

As I can see, yoyo did a great job in implementing a BOINC wrapper.  That's good. 
Muon's client still is Windows only.  That's not so good.

I'd still / again like to let some Linux machines do some work.  As well I happened to switch to Mac for which there is also no client available.  I'm willing to help out on porting the app, but given the fact that Stephen didn't reply in a year, I doubt there's interest

So, just for the books: Is there any news or interest?
Stephen Brooks
2008-05-30 15:38:30
--[(if you mostly run on battery, you have to be careful)]--

You also missed the update of Muon1 that puts the client on hold when you are running with batteries in the last year!

There are no plans to port Muon1 to other operating systems at the moment.  Actually, I'm busy writing a thesis so I can barely do any normal client updates, let alone on other OSes right now!  That's not to say it's impossible, I've managed now to get some OpenGL graphics examples compiling under Linux, which only leaves the networking and a few miscellaneous operations as "unknowns" in the porting.  But don't hold your breath.
yoyo
2008-05-30 21:07:44
Would be good idea to separate the crunching part from the graphics part and port only the crunching part to Linux, Mac and 64 bit win/linux.  And what about a PS3 client?
I think if I could get major parts of the sources of the core client I would find some people who help in porting the stuff to other operating systems.  Have a look to the operating systems which are supported by yoyo@home's cruncher, but I have only a Linux compiler.  All other versions are compiled by different volunteers.
But at least I respect, that Stephen has not much time.  It is almost the same on my side.
AlArenal
2008-05-30 22:08:54
Time is always a factor, but it wouldn't hurt to give it a shot.  You can't be certain if it works out, only that there won't be a port if noone tries.

My C has gotten rusty over the years I spent with Java and PHP, but I'm wlling to learn
[DPC]white_panther
2008-05-30 22:55:29
just maybe a realy crazy idee, but why not a java client?  or is that inposible
AlArenal
2008-05-30 22:58:35
You would have to rewrite the whole client from scratch to create a Java client.  Even I (as former professional Java coder) don't think it would make sense.
[TA]Assimilator1
2008-05-31 13:35:20
Just to correct an earlier statement by Pascal about F@H which is just plain wrong, F@H will detect inaccurate calculations & will terminate the WU early (EUE), no false results are sent off AFAIK.

And btw because F@H does the above it makes it an ideal program for testing o/ced stability, far more stringent than Prime 95!

AlArenal
Maybe as a short term measure you could trade CPU power with someone? 
ie if you have say 6GHz of Linux power available 24/7 to run a DC project & another person has 6GHz of Windows power available 24/7 & he/she runs a project which does have a Linux client, then you could run their project for them under their account & they could run DPAD for you under your name.

Of course a few major snags to this is trying to find someone (or people) with matching power & trusting them to crunch as promised (you can check the stats for this at least), but it's a possibilty nonetheless.  Even if you only use part of your fleet this way it's be better than nothing .

If you're in a team that makes it much more possible, are you?
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel charactermstdn.io

Site has had 17125780 accesses.