How odd

[Aussie]

include your original registration as well, and you've done 76 Tinker wu's to date!

Yes but I've only stopped using the -advmethods flag for the past month on the Aussie username and two machines are using the graphical client with no flags whatsoever so the Aussie username statistics are confusing.

The Aussie_Challenge & Aussie_Dual usernames have not used the -advmethods flags at all so that data is "pure".

One thing I have noticed is that the slower AMD machines (Duron 800 & Athlon 800) are more likely to get Tinkers than the faster machines with or without the -advmethods flag. Also the Celeron 950 very rarely, if ever, gets a Tinker yet it is running the graphical client with no flags at all.

Here's some extracts from FAHlog.txt & FAHlog-Prev.txt files as an example, these are the most recent WU's from each machine:-

Athlon 800 3.25 console with -advmethods flag

p638_L939_K12M_ext

p639_L939_K12M_nat

p688_L939_K12M_444K

p689_L939_K12M_503K

p690_L939_K12M_532K

p638_L939_K12M_ext

Athlon 800 3.25 console without -advmethods flag

p638_L939_K12M_ext

p638_L939_K12M_ext

p692_L939_K12M_int

Celeron 950 graphical client no flags

p352_nat_305_99

p369_tip5p_pf2_Na

p830_p53dimer830

p548_BBA5_ext

p328_A21unf_273_op

p344_gnra_unf_1

p1010_lzip_350

p683_TZ2_NAT_EXP

p344_gnra_unf_1

p344_gnra_unf_1

p320_nat_273

p803_p53dimer803

p683_TZ2_NAT_EXP

p683_TZ2_NAT_EXP

p828_p53dimer828

p352_nat_305_99

As you can see the Athlon has received Tinkers exclusively with or without the -advmethods flag and the Celeron has received Gromacs exclusively despite having no flags at all.

AMD machines apparently handle Tinkers far better than Intel machines so I'm wondering if tinkers are targeted at AMD machines.


Aussie

[Ladd]

Check this out Aussi:


[22:45:18]
[22:45:18] *------------------------------*
[22:45:18] Folding@home Gromacs Core
[22:45:18] Version 1.51 (September 25, 2003)
[22:45:18]
[22:45:18] Preparing to commence simulation
[22:45:18] - Assembly optimizations manually forced on.
[22:45:18] - Not checking prior termination.
[22:45:18] - Expanded 169171 -> 957557 (decompressed 566.0 percent)
[22:45:18] - Starting from initial work packet
[22:45:18]
[22:45:18] Project: 1020 (Run 5, Clone 88, Gen 0)
[22:45:18]
[22:45:18] Assembly optimizations on if available.
[22:45:18] Entering M.D.
[22:45:24] Protein: p1020_FSnat_273_99
[22:45:24]
[22:45:24] Writing local files
[22:45:24] Extra SSE boost OK.
[22:45:24] Writing local files
[22:45:24] Completed 0 out of 2500000 steps (0)
[22:58:16] Writing local files
[22:58:16] Completed 25000 out of 2500000 steps (1)
[23:10:27] Writing local files
[23:10:27] Completed 50000 out of 2500000 steps (2)
[23:22:40] Writing local files
[23:22:40] Completed 75000 out of 2500000 steps (3)
[23:34:52] Writing local files
[23:34:52] Completed 100000 out of 2500000 steps (4)
[23:47:31] Writing local files
[23:47:31] Completed 125000 out of 2500000 steps (5)
[00:00:08] Writing local files
[00:00:08] Completed 150000 out of 2500000 steps (6)
[00:14:22] Writing local files
[00:14:22] Completed 175000 out of 2500000 steps (7)
[00:27:06] Writing local files
[00:27:06] Completed 200000 out of 2500000 steps (8)
[00:39:57] Writing local files
[00:39:57] Completed 225000 out of 2500000 steps (9)
[00:53:06] Writing local files
[00:53:06] Completed 250000 out of 2500000 steps (10)
[01:06:47] Writing local files
[01:06:47] Completed 275000 out of 2500000 steps (11)
[01:19:09] Writing local files
[01:19:09] Completed 300000 out of 2500000 steps (12)
[01:31:25] Writing local files
[01:31:25] Completed 325000 out of 2500000 steps (13)
[01:44:20] Writing local files
[01:44:20] Completed 350000 out of 2500000 steps (14)
[01:57:09] Writing local files
[01:57:09] Completed 375000 out of 2500000 steps (15)
[02:10:43] Writing local files
[02:10:43] Completed 400000 out of 2500000 steps (16)

[02:25:40] Writing local files
[02:25:40] Completed 425000 out of 2500000 steps (17)
[03:55:46] - Autosending finished units...
[03:55:46] Trying to send all finished work units
[03:55:46] + Sent 0 completed units to the server
[03:55:46] - Autosend completed
[03:55:46] + Working...
[09:55:46] - Autosending finished units...
[09:55:46] Trying to send all finished work units
[09:55:46] + Sent 0 completed units to the server
[09:55:46] - Autosend completed
[09:55:46] + Working...


I left it running again all night last night and if you look at the bold it didnt do anything from like 2 until almost 10. Anyone have any ideas? NOthing else was running....

[Aussie]

Personally I would ditch that work unit if it has stalled like that. Firstly you need to find out what number that work unit is in the queue by using the -queueinfo flag, the client will start then immediately stop and the queue info will be written to the FAHlog.txt file in your foldin@home folder.

When you have identified which number the work unit is in the queue you can use the -delete x flag to delete that work unit.

http://folding.stanford.edu/console-userguide.html

-queueinfo
Get information on queued work units. Includes for each unit the status (READY/FINISHED/EMPTY), unit type (Folding/Genome), originating server, and date when the unit was received (local time in GMT), as well as deadline if the server sent that information.

-delete x
Delete item #x from work queue. This option should only be used if there is a serious error with the current unit that the client does not automatically recover from (e.g. crash-inducing). This should not normally happen, and if it does, we would be grateful if you could send us the FAHlog.txt file from the unit that causes the error.

Aussie

[len444]

if using the windows console version, a mouse click in the console window will stop any verbiage in the command window. i forget what key sequence was recommended at fah forum, but ctrl -c will work as well. something about service mode i believe.

anyway it might not be related to a faulty wu, but if you mouse clicked in the command window (which would mean that everything is ok- just restore the command window)...

[len444]

Personally I would ditch that work unit if it has stalled like that. Firstly you need to find out what number that work unit is in the queue by using the -queueinfo flag, the client will start then immediately stop and the queue info will be written to the FAHlog.txt file in your foldin@home folder.

When you have identified which number the work unit is in the queue you can use the -delete x flag to delete that work unit.

http://folding.stanford.edu/console-userguide.html

-queueinfo
Get information on queued work units. Includes for each unit the status (READY/FINISHED/EMPTY), unit type (Folding/Genome), originating server, and date when the unit was received (local time in GMT), as well as deadline if the server sent that information.

-delete x
Delete item #x from work queue. This option should only be used if there is a serious error with the current unit that the client does not automatically recover from (e.g. crash-inducing). This should not normally happen, and if it does, we would be grateful if you could send us the FAHlog.txt file from the unit that causes the error.

Aussie

aussie, wouldn't stopping, and restarting folding be sufficient to let the wu be analyzed, and discarded w/ o using the -delete x flag?

[len444]

As you can see the Athlon has received Tinkers exclusively with or without the -advmethods flag and the Celeron has received Gromacs exclusively despite having no flags at all.

AMD machines apparently handle Tinkers far better than Intel machines so I'm wondering if tinkers are targeted at AMD machines.

i have almost exclusively used amd cpu's, so this might explain matters!

i did get a 71 point tinker once while running my p166, which was very strange, as it would have taken forever (65 days). i had specified GAH wu, but for some reason the specification was dropped after a gah wu was completed. this was w/ the 3.25beta console w/ linux os.

anyway, i found that i have had to use the -advmethods flag to get gromacs for linux. why not have everyone use the flag to increase the odds of getting those gromacs wu's?

back to the percentage of tinkers processed 19% vs 1.9%- i believe that the -advmethods flag works! better than leaving things to chance. when the adv servers stop handing out wu's, then it'll be open to whatever type they want to hand out.

[Aussie]

aussie, wouldn't stopping, and restarting folding be sufficient to let the wu be analyzed, and discarded w/ o using the -delete x flag?

Not in my experience, after the incident that I wrote about here:-

http://www.motherboards.org/forums/viewtopic.php?t=33321

I finally got that WU to complete and send but from then on I had a problem with a WU that would not send and I suspect that it was the output from the WU that failed at 98%. For the next 3 or 4 WU's the client would do this:-

[20:30:38] Finished a frame (38 )
[20:35:32] Finished a frame (39)
[20:40:18] - Autosending finished units...
[20:40:18] Trying to send all finished work units
[20:40:18] + Sent 0 completed units to the server
[20:40:18] - Autosend completed
[20:40:23] Finished a frame (40)
[20:45:14] Finished a frame (41)

about every 6 hours until I eventually got sick of it and deleted the offending WU.


Aussie

[len444]

[20:30:38] Finished a frame (38 )
[20:35:32] Finished a frame (39)
[20:40:18] - Autosending finished units...
[20:40:18] Trying to send all finished work units
[20:40:18] + Sent 0 completed units to the server
[20:40:18] - Autosend completed
[20:40:23] Finished a frame (40)
[20:45:14] Finished a frame (41)

about every 6 hours until I eventually got sick of it and deleted the offending WU.

auto send every 6 hrs is normal behavior! i've had that behavior from day 1. if not processing the wu, then that would be a problem.

edit: not sending a wu is a definite problem. i've been lucky in that regard so far. you probably suspect correctly that there is some coding malformation (residual, or due to a wu), and sending in wu, completeing what's there, ask before send selected, and -send all flag, and deletion, and reinstallation of FAH executable would help things out. i think whiteboy has had some wu send in problems. perhaps getting them sent in, and uninstalling, and reinstalling folding is the best approach.

it's definitely in the area of correct educated guesswork, that things can get sorted out. takes some time, and rememberance of the variables encountered to get a feel for what works best.

anyway, we all have our perspectives from our experiences- we can help each other out, and be better in that regard at what we do. having an analytical process to help determine what's correct, and diligence in that regard is what will prove most constructive.

[Aussie]

auto send every 6 hrs is normal behavior!

I'm sorry but autosend every 6 hours is not normal behaviour UNLESS there is a completed WU in the queue waiting to be sent. If a server is off-line when a WU is completed that prevents that WU from being uploaded the client will keep that WU in the queue, download a new WU, start processing it and autosend will try every 6 hours to return the completed WU in the queue until it is successful.

If there is no completed WU waiting in the queue autosend every 6 hours does not occur.

Problems with autosend do seem to occur when the client crashes or a work unit stalls for some reason or other, I suspect that this is because the WU is not a completed or finished unit. When this occurs all you can do is try the -send x flag:-

http://folding.stanford.edu/console-userguide.html

-send x
Send result #x back to server. Exits after trying to send unit (successfully or unsuccessfully). Use "-send all" to send all results outstanding. If unit x is not a completed work unit then the client exits without doing anything.

If that doesn't clear the problem WU you only remaining option is the -delete x flag particularly if, as in Ladd's case, the stuck WU has caused the client to cease folding altogether.


Aussie

[len444]

i posted a question at FAH forums regarding the autosend feature that occurs at 6 hour intervals. this can be watched here:
http://forum.folding-community.org/viewtopic.php?t=6047