results with linux clients are marked invalid
9 Mar 2005 22:36:18 UTC
Topic 188420
(moderation:
I have started this week with the einstein client on a linux OS. The first result I produced was marked invalid. Therefore I did a little research. I examined the results from work units 390200 till 390300. I gathered the info of all units with 0 for granted credit. From this list I removed all units which were passed the deadline. The result list consists of 5 work units at which at least 1 computer has its result marked invalid:
WU:
39025 -> Linux OS
39027 -> Linux OS
39213 -> Windows 98
39249 -> Linux OS
39288 -> Linux OS
I find this very strange, because most computers uses XP as OS, and therefore statistically you should expect XP has also the most rejected results! But all invalid results are linux OS's and 1 windows 98. I think this must be investicated further. Until this is resolved, I will stop processing WU's.
results with linux clients are marked invalid
)
They are looking at rewriting the validator program, all those results flagged as invalid are just outside of the threshold, ie. close but not close enough.
They thought perhaps a week on the rewrite. Yes it is primarily a linux problem.
>Yes it is primarily a linux
)
>Yes it is primarily a linux problem.
I had this problem alot too, but switching to running the windows binaries with wine on linux, also solved this problem(as well as a huge increase in performance).
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
I may end up giving that a
)
I may end up giving that a shot on my xandros system. Only 1 of a dozen has gotten credit there. How much performance are you talking. This particular systrem is averaging 55-60 seconds/wu. What gains did you see?
make that 55-60,000 seconds
)
make that 55-60,000 seconds
I switched to the windows
)
I switched to the windows binary with wine, and I get twice the performance as a linux native binary. However I discovered some disturbing info. Looking at the "Fstats.Ha" file, I see that the windows binary produces always 2 zeros at the end for the value in the last column, whereas the linux binary will not. Is it possible that the linux client produces results which are more accurate then the result of windows clients? (And are therefore slower). And because the validator reject all results which are different from the first two received, the linux client results will marked as invalid. But in fact I think that all windows clients produces wrong results! (To be sure, this test must be done with the same work unit on a windows and a linux computer, and not with 2 different work units as I have done)
Linux native binary output for a work unit ("Fstats.Ha" file)
1417.260892361111 5.00033335 -1.55079633 118 7.00571 5.13692 26.80491145512875661
1417.199267361111 0.00000000 -1.53079633 119 7.27406 5.93235 27.11517352248414170
1417.200923611111 0.00000000 -1.53079633 118 5.39935 5.71899 26.42133098217932741
1417.276809027778 0.50013336 -1.53079633 117 6.81250 5.13277 25.53302884369448122
1417.275375000000 1.00026672 -1.53079633 117 6.93007 5.09107 25.41538057274135198
1417.301840277778 1.50040007 -1.53079633 105 9.39480 6.11870 26.61506027388067963
1417.297770833334 4.50120022 -1.53079633 117 7.90598 6.16988 25.46803614493974877
1417.263788194444 5.50146694 -1.53079633 117 7.01216 5.33821 25.32610283889811598
1417.198704861111 6.00160030 -1.53079633 131 7.04768 6.07229 29.06831009780695041
1417.244548611111 0.00000000 -1.51079633 117 6.30771 5.68988 26.07362447640903014
Wine Windows binary output for a work unit ("Fstats.Ha" file)
788.304572916667 0.50013336 -1.53079633 118 7.64171 5.77767 25.85702392129655900
788.303621527778 1.00026672 -1.53079633 129 7.57434 5.61263 25.93861051027674200
788.302222222222 1.50040007 -1.53079633 129 7.63127 5.83440 26.31326505672991800
788.300642361111 2.00053343 -1.53079633 118 7.74808 6.17085 26.27117158676713900
788.370256944444 3.50093351 -1.53079633 117 6.31798 5.28554 25.18087576601423500
788.306392361111 0.00000000 -1.51079633 118 7.48883 5.68452 25.91862699143237600
788.306295138889 0.33353342 -1.51079633 118 7.65356 5.42839 26.05774963134365100
788.305680555556 0.66706683 -1.51079633 118 7.78274 5.44152 25.50587402326232200
788.304621527778 1.00060025 -1.51079633 117 7.87149 5.57945 25.12472906623862600
788.303277777778 1.33413367 -1.51079633 130 7.71998 5.47700 25.75418791324081600
> I switched to the windows
)
> I switched to the windows binary with wine, and I get twice the performance as
> a linux native binary.
This is the same with me.
> However I discovered some disturbing info. Looking at
> the "Fstats.Ha" file, I see that the windows binary produces always 2 zeros at
> the end for the value in the last column, whereas the linux binary will not.
This should definately be looked at. Hopefully Bruce will read this, maybe someone should even email him directly, as this could be of some significance.
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
i'm just going to stop
)
i'm just going to stop processing WUs until they resolve this.
it's kinda sad the linux client runs at 45% the speed of the windows build, then gets invalidated WUs to boot..
if i could get windows to run on my toaster, it would probably outperform my amd64 linux box for the purposes of running this client >.>
btw, a 64bit client would be really nice to have.
> i'm just going to stop
)
> i'm just going to stop processing WUs until they resolve this.
I emailed Bruce, hopefully he reads it.
> btw, a 64bit client would be really nice to have.
Lot's of people have been asking for this if you look in the wish list forum. Not sure how long, if at all, it will take for them to get one.
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell
I did extra some testing, and
)
I did extra some testing, and I think that windows clients are indeed less precise in calculation then linux clients. I used a test program from www.winface.com/sqrc_results.html, this program does sum 1000000000 times a sqrt function. I have compiled this program 3 times:
- gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
- gcc version 3.4.3
- Visual C++ 6.0 Enterprise Edition
I have a dual boot computer with linux redhat 9.0 and windows 2000 server. Therefore all tests are done on the same hardware!!! (PII 400 Mhz)
The correct answer:
21081851083600.37596259382529338
Answer: redhat 9, kernel 2.6.10, gcc 3.2.2:
21081851083600.38281250000000000
Answer: redhat 9, kernel 2.6.10, gcc 3.4.3:
21081851083600.38281250000000000
Asnwer: Visual C++ 6.0 Enterprise Edition
21081851083600.55900000000000000
What do we learn from this, I think 2 things. First, the answer from the gcc compiler is more precise then from the microsoft compiler. Second, the gcc compiler displayes more digits in the result then the microsoft compiler. The last observation I have already seen before, see message id 8116. In that post I explained that, the last two digits for the values in the last column in the "Fstats.Ha" file are always two zeros for windows clients, and real values for linux clients.
Maybe the results for all windows clients must be invalidated, and not the results from linux clients!
> > Maybe the results for
)
>
> Maybe the results for all windows clients must be invalidated, and not the
> results from linux clients!
>
>
This is indeed very interesting I emailed Bruce and got no reply, and it seems as no one higher up on the LIGO project has noticed this posting yet. Maybe it should be cross posted in the problems section?
such things just should not be writ so please destroy this if you wish to live 'tis better in ignorance to dwell than to go screaming into the abyss worse than hell