List of Known Bugs [SMP Win v6.22]

[7im]

I almost copied over the old list from v5.91, but starting fresh seems more optimistic. Add your bug info in a new post below, and a Mod or Admin will add/update this post.

EDIT: Let's use this thread to report any new bugs, and I'll also point you back at the list of known bugs from the v5.91/v5.92 clients... most of which have not been corrected yet... http://foldingforum.org/viewtopic.php?t=50

1. v6.22 SMP Windows client stops folding after every EUE, and displays a popup error message "This is a sign of more serious problems, shutting down." This is a change in behavior from the v5.9x client. This behavior goes against the long standing fah client design philosophy to recover from all errors if possible and continue folding. qfixing a v6.22 client doesn't appear to work either, so the only option to clear the error is to delete the work folder, the queue.dat file, and the unitinfo.txt file. NOTE: Do not delete your work folding if there are other completed work units not yet uploaded.
   
2. v6.2x SMP Windows client will trash a work unit if you switch client modes in the middle of a work unit, i.e. if you start and configure your client without the -smp switch, the client will download a CPU work unit. If you then add the -smp switch in the middle of that CPU work unit, you will get FILE_IO errors and the work completed is lost. Wait until the WU is completed before switching. NOTE: A feature request/bug report has been filed to have a start up saftey check so WUs are not trashed, similar to the start up check if you try to run more the one fah client with the same Machine ID.
   
3. Next new bug goes here...
   

[mikeb12]

I've only had 2 run ins with problems and they are wu specific..
2 different machines, 2 different wu's.. but exact same error message..
otherwise the new client hs been running 24/7 on all 3 of my Q6600's, dual mpich 6.22's... 2 have 8800gt gpu2 6.20 systray clients.
other than these 2 wu's, they've been error free running 24/7 since last friday aug1.
both machines were on dual 5.91's for the last 6-10months 24/7, and rarely had issues..
my last eue was in March, and it was a wu specific thing. viewtopic.php?f=19&t=1717&p=14304

viewtopic.php?f=19&t=4693 Project: 2665 (Run 0, Clone 426, Gen 37) reported

[08:10:51] Completed 150000 out of 250000 steps (60 percent)
[08:27:38] Writing local files
[08:27:38] Completed 152500 out of 250000 steps (61 percent)
[08:39:17] Quit 101 - NaN detected: (ener[25])
[08:39:17]
[08:39:17] Simulation instability has been encountered. The run has entered a
[08:39:17] state from which no further progress can be made.
[08:39:17] This may be the correct result of the simulation, however if you
[08:39:17] often see other project units terminating early like this
[08:39:17] too, you may wish to check the stability of your computer (issues
[08:39:17] such as high temperature, overclocking, etc.).
[08:39:17] Going to send back what have done.
[08:39:17] logfile size: 72678
[08:39:17] - Writing 73228 bytes of core data to disk...
[08:39:17] ... Done.
[08:39:17] - Failed to delete work/wudata_07.sas
[08:39:17] - Failed to delete work/wudata_07.goe
[08:39:17] Warning: check for stray files
[08:41:18]
[08:41:18] Folding@home Core Shutdown: EARLY_UNIT_END
[08:41:18]
[08:41:18] Folding@home Core Shutdown: EARLY_UNIT_END
[08:41:25] CoreStatus = 7B (123)
[08:41:25] Client-core communications error: ERROR 0x7b
[08:41:25] This is a sign of more serious problems, shutting down.

viewtopic.php?f=19&t=4605 Project: 2665 (Run 3, Clone 530, Gen 36) reported

[13:51:09] Completed 70000 out of 250000 steps (28 percent)
[14:07:58] Writing local files
[14:07:58] Completed 72500 out of 250000 steps (29 percent)
[14:20:16] Warning: long 1-4 interactions
[14:20:18] Quit 101 - NaN detected: (ener[0])
[14:20:18]
[14:20:18] Simulation instability has been encountered. The run has entered a
[14:20:18] state from which no further progress can be made.
[14:20:18] This may be the correct result of the simulation, however if you
[14:20:18] often see other project units terminating early like this
[14:20:18] too, you may wish to check the stability of your computer (issues
[14:20:18] such as high temperature, overclocking, etc.).
[14:20:18] Going to send back what have done.
[14:20:18] logfile size: 63628
[14:20:18] - Writing 64177 bytes of core data to disk...
[14:20:18] ... Done.
[14:20:18] - Failed to delete work/wudata_05.arc
[14:20:18] Warning: check for stray files
[14:22:18]
[14:22:18] Folding@home Core Shutdown: EARLY_UNIT_END
[14:22:18]
[14:22:18] Folding@home Core Shutdown: EARLY_UNIT_END
[14:22:21] CoreStatus = 7B (123)
[14:22:21] Client-core communications error: ERROR 0x7b
[14:22:21] This is a sign of more serious problems, shutting down.

[Foxery]

Bad work units are not a result of the new client version, as the FAHCore has not been changed. Some WUs are just bad - it happens, it's fairly random - and should be reported in the "Issues with a specific WU" section.

[Insidious]

Bad work units are not a result of the new client version, as the FAHCore has not been changed. Some WUs are just bad - it happens, it's fairly random - and should be reported in the "Issues with a specific WU" section.

I switched over to the 6.22 MPICH version of smp and within (literally) hours, the 'bad Work Units' were released.

I really don't mean to be the voice of discontent, that would tend to contradict my participation in F@H for several years now,

However; With all due respect,

It really does seem a little much to ask in the way of acceptance that the EUEs I am seeing (and apparently, from the numerous comments throughout these forums I am anything but alone) Are purely coincidence and the client is working as it should.

I think science will benefit MUCH more from acknowledging it's shortcommings... we truly do learn from mistakes..... IF they are treated as such and corrected.

Bug #1: Work Units are failing at an increased rate throughout the smp project in comparison with previous verisons (5.91 and 5.92)
Bug #2: Installation results seem somewhat erratic amongst users. Many client installations are failing for unknown reasons

Dismiss the problems we are experiencing at the peril of science

-Sid

[Foxery]

After getting 2 bad WUs myself this week, I'd like to revise that somewhat -

Feature-not-bug? A behavior which should be reverted: This version of the SMP client no longer handles EUEs in a productive manner, as it freezes and waits for user intervention. Previous clients continued to work; I believe the intended behavior was to reattempt the bad WU 2 more times to verify that it was indeed bad, then download a new WU. With the new behavior, unattended machines will simply fail and sit idle indefinitely.

[MtM]

I see where Mike's feeling of being taken serieus comes from

Nice 180 Foxery, but maybe you shouldn't be so hasty next time?

[mikeb12]

If you'd like to comment on my 2 wu reports, the reported wu threads are linked in my above post.

I was just adding the issue to this thread since no one seems to be using this thread to report anythng and it's at the top of the forum.
There's no need to hash it out again since the 6.22 eue issue has thoroughly been discussed here viewtopic.php?f=46&t=4353

Unfortunately, none of the clients (MPICH or Deino) have been able to deal with EUE on A1 core under Windows. They were both doing something wrong (processing the WU 3 times for example ...) instead of submitting partial credit, and move to another WU.
That's why I always suggested to use qfix in this case ...
By the way, I hope this issue will be gone with A2 core, and that the fixes kasson is implementing will prevent the client from crashing (but I guess we'll still have to use qfix on EUE with Windows A1 core ... I hope I'll be wrong).

Our goal is to improve the client (i.e. possibly "option C" or something better) and that's in development.

v6.22 is not broken, it just behaves differently. To some v6.22 is an improvement, to others it has become more troublesome. So until there is an Option C, please try to understand this difference in behavior, and make a choice of Option A or Option B. v5.91 or v6.22. Thank you.

so there's really nothing to debate or correct in this thread, just let it remain a bug report thread...

personally, I'm going to continue running dual 6.22 mpich clients on my Q6600's until a2 core comes out... then I'll drop to one client.
as of now all my 6.22 mpich smp's have been running 24/7 for over a week and only 2 eue's (listed above in 2nd thread post).

and they are all doing good as I speak... (the 0% is a finished, and sent unit)

[RipD]

Not sure if these are bugs:

1. [deleted for irrelevance]

2. If I rename the client .exe to "fah6.exe" I can not run -configonly. It will crash every time right after the "acceptable size of work assignment" question. I get the XP pop-up: "fah6.exe has encountered a problem and needs to close." This also sets the client.cfg back to the default values.

[MtM]

1. Where did you get -smp x from as a possible flag? -smp only indicates to the server you want smp wu's. The affinity lock is only for the gpu2 clients.
2. Don't rename the client Though it is suspicieus a name change triggers an error.

[RipD]

Hmmm, just realized that I pulled that off another site. Never mind.

One of the recommended installs here tells people to rename the client to fah6.exe.

[MtM]

Ok didn't know about that guide, it's not the one I would recommend then anyway. Why would you need to rename it anyway?

[Foxery]

1. Where did you get -smp x from as a possible flag? -smp only indicates to the server you want smp wu's. The affinity lock is only for the gpu2 clients.

Version 6 supports the "-smp x" flag, where x is the number of CPUs. The FAHCore_a1 does not accept this, but it is used by Linux clients and will become a useful Windows feature in the future.

Nice 180 Foxery, but maybe you shouldn't be so hasty next time?

It wasn't a 180; my original statement is still 100% correct. The WUs are still bad; the FAHCore still has not changed; the fact that the client freezes instead of recovering is the only trouble.

This may be an intended behavior for this version, but I hope it doesn't stay this way.

[RipD]

Ok didn't know about that guide, it's not the one I would recommend then anyway. Why would you need to rename it anyway?

From the Stanford FAQ for this version of Windows SMP:

Type "Folding@home-Win32-x86.exe -configonly" (some people like to first rename the exe to fah6.exe to make less typing) then configure it to your needs.

[MtM]

Ok didn't know about that guide, it's not the one I would recommend then anyway. Why would you need to rename it anyway?

From the Stanford FAQ for this version of Windows SMP:

Type "Folding@home-Win32-x86.exe -configonly" (some people like to first rename the exe to fah6.exe to make less typing) then configure it to your needs.

Still says, some people like, not that you actually need to. And I think I read an report before of this and UF I think posted that no code in the program itself is reliant on the executable's name so that report turned out to be bogus as well.

[7im]

I don't know either way if the new v6.22 client has anything to do with what appears to be an increase in EUEs. However, I do know that because the v6.22 stops at every EUE, the visibility of each and every EUE has greatly increased. So the appearance of the increase in errors noted could easily be attributed to the increase of noting those errors.

However, the long standing design concept of fah clients recovering from errors and continuing to fold has not been followed in this instance. We'll log that at the top of the list.