FahSpy questions and anomalies

A

APOLLO

[H]ard|DCer of the Month - March 2009
Joined
Sep 17, 2000
Messages
9,089
One of my machines is working on a WU I received yesterday (31st), but the issue date listed in FahSpy is the 29th of Aug. Consequently, the deadline stated is for the 2nd of September. Is this some FahSpy error, or do I genuinely have a late issued WU??

In addition, there's never a credit listed for any WU my machines are working on and I never have any PPH or PPD estimations. Is this also normal for FahSpy?

Note: I am working only on SMP WUs and the program version is 1.4.3. Thanks in advance.
 
APOLLO said:
One of my machines is working on a WU I received yesterday (31st), but the issue date listed in FahSpy is the 29th of Aug. Consequently, the deadline stated is for the 2nd of September. Is this some FahSpy error, or do I genuinely have a late issued WU??

In addition, there's never a credit listed for any WU my machines are working on and I never have any PPH or PPD estimations. Is this also normal for FahSpy?

Note: I am working only on SMP WUs and the program version is 1.4.3. Thanks in advance.
Click to expand...

SMP WUs does have such short deadlines and it's perfectly normal :)
 
There is a newer version 1.4.5. I would download that. I also use FahMon as well as FahSpy. There are features that I like on both. SMP work units do have short return times. The one that I am working on right now has a 4 day window.

 
OK thanks, I will DL both the newer version and FahMon. Hopefully the bizarre data displayed will be corrected and I will see the WU credits for the first time.
 
Jon855 said:
Aug 29, 30, 31, Sept 1, 2...
There you go, it's four :)
Click to expand...
Yes, but I DL it on the 31st, not the 29th. That is the initial reason I posted the question regarding FahSpy's error in reading issue dates, not deadlines.
 
This is the line from the log: [18:35:14] Working on Unit 00 [August 31 18:35:14]

However, FahSpy reports the issue date as the 29th. I assume it's some kind of error and will ignore it. I'll see if the newer version will display the proper date and post here.
 
The new version of FahSpy still reports the same issue date. FahMon reports the WU as DL 3.41 days ago, but the log file clearly states the 31st. Weird... :confused:
 
Could that be caused by a discrepancy between the clocks on different computers? Like one computer the time/date is off?
 
Was a long shot but I figured I'd throw that out there in case you overlooked it, that is weird though.
 
I use FahSpy 1.4.1 and it shows my PpD for all my SMP clients.
Did you update the database so that it can read the latest psummery.html file from Stanford.

As for the early date did the previous WU EUE ?
If so you may have been given the same WU to rerun.

Luck ......... :D
 
Tigerbiten said:
As for the early date did the previous WU EUE ?
If so you may have been given the same WU to rerun.
Click to expand...
You mean if the previous WU encountered an error and prematurely ended? Yes, there was an error that I never saw before, a 'FILE IO ERROR' or something like that. Would Stanford reissue the same WU to me and not revise the deadline? That doesn't not seem a likely scenario, but I don't have much experience with the SMP client.
 
APOLLO said:
You mean if the previous WU encountered an error and prematurely ended? Yes, there was an error that I never saw before, a 'FILE IO ERROR' or something like that. Would Stanford reissue the same WU to me and not revise the deadline? That doesn't not seem a likely scenario, but I don't have much experience with the SMP client.
Click to expand...

If it is giving the error code 7b, it is one of those anomalies that the SMP client still has. They do not know the cause of it. Here is some info about the error codes . Its useful to determine how close you need to watch the client.

 
Thanks for the info on the error codes.

FahSpy was indeed correct. I just received a message from the client that the WU has passed the deadline. I guess I'm going to have to monitor the clients more closely now, and that will be made all the more difficult since more clients will be coming online in a little while. If I see the same thing again, do I just delete the WU knowing I can't make the deadline?
 
APOLLO said:
If I see the same thing again, do I just delete the WU knowing I can't make the deadline?
Click to expand...

I think that would be a personal choice to make. I do believe that the data itself can still be of use but I do not know that for sure. I think you would also have to consider how much time you are willing to spend watching this. I hope that Standford is working on refining the client a bit.

I found the error codes to be of great use and you are welcome! :D

 
If you get an early end with an SMP work unit, Stanford will send you the same one twice more to see if you can finish it.
With FahSpy its easy to spot because the SMP client very rarely send an early end work unit back so it sits there unsent untill you 9 more work units then it gets overwriten.
And thats one thing FahSpy will show.

As for deleating them then it depends.

If it a p2652 then thats a buggy work unit which if it stops once then it will stop twice more.
So I now deleate the next two downloads untill I get a fresh work unit as a matter of course.

With the other protien it dependes on where it ended.
First 10-20 frames I will give it another shot.
If the second go fails then I deleate the third attempt.
After 50 frames I tend to deleate untill I get a fresh work unit.
Between 20-50 is more iffy. Sometimes I run then & sometimes I dont.
It depends on if I'm going to be around when it ends again.

I dont mind doing bad work unit but what does bug me is doing bad work units for zero points because theres no way to send the part work back in.

Also if I'm shutting a part done work unit down then I always make a copy of it.
That way, when it fails to restart properly, I've got a backup to try again with.

Luck .......... :D
 
I have another question concerning FAHSpy. In the Run Clone-Gen column, two of my machines are running a WU that is colored in bold red and they happen to be identical types. In this case, the WU(s) in question is a 2653 (18-64-5) and run on two machines. Is there a significance why these two WUs are displayed in bold red?
 
Have they just upload work ?
If the have then FahSpy complains that some files don't get deleted.

[18:49:55] ... Done.
[18:49:55] - Failed to delete work/wudata_08.sas
[18:49:55] - Failed to delete work/wudata_08.goe
[18:49:55] Warning: check for stray files
[18:49:55] - Shutting down core

Just click on them & check the log file that this is the reason and not a b7 error.

Its an easy way to see whats uploaded since you've last checked that everything is working.

One thing I also do is run down each client and check the time shown when the last frame finished is about correct.
That way you can pick up if a client has frozen.

If it shows up in blue then the client has been shut down.

Luck ........... :D
 
Tigerbiten said:
Have they just upload work ?
If the have then FahSpy complains that some files don't get deleted.

[18:49:55] ... Done.
[18:49:55] - Failed to delete work/wudata_08.sas
[18:49:55] - Failed to delete work/wudata_08.goe
[18:49:55] Warning: check for stray files
[18:49:55] - Shutting down core

Just click on them & check the log file that this is the reason and not a b7 error.
Click to expand...
There's nothing unusual that I could find in the logs, and the machines didn't upload anything today.

Thanks for the tips just the same.
 
Due to the thread title I'll post here -

Yesterday FAHSpy predicted the SMP WU I was working would end yesterday at about 20:00,it kept predicting that till I went to bed at 23:00.

This morning the hour/min/sec were the same, but the day changed to today, and it looks like that's about the time the WU will end.

Has anyone seen this before?

 
The only time I've seen something like that was when the time/date was wrong in Windoze.
Check your setting but remember if you alter the date forward any, F@H may think the last work unit has passed the last deadline so it will delete all work done so far on that work unit.
Classic mistake due to a wrong date.

Luck ............ :D

 
FahSpy does that on my system also; it's not because of a wrong time or date. It's a program error. It happens very frequently, but once the actual time passes midnight, the predicted time of WU completion corrects itself.
 
APOLLO said:
FahSpy does that on my system also; it's not because of a wrong time or date. It's a program error. It happens very frequently, but once the actual time passes midnight, the predicted time of WU completion corrects itself.
Click to expand...
Thanks, it was making me wonder.


 
The main problem I've had with FahSpy is that it does not track my Linux SMP client correctly. It gets the predicted date and protein information correctly as well as the PPD and PPH. However, it does not like to actually add the PPD and PPH into the total. It does add the overall WU point totals together for all connected clients. I'm running FahSpy on my single WinXP box with monitoring for my Linux SMP box. Only once that I can recall has it included it into the totals for all clients.

It has never had a problem with tracking Windows clients on other boxen. For the Linux SMP client it just shows the stats as stopped. I have not tried to monitor the WinSMP client mainly because I would never be able to finish an SMP unit in time with the little time I spend in Windows on my only SMP machine.

I'm not sure what the problem is. It does keep up with the percentage completed on the WU just fine and there was the one instance when it did track everything correctly. I know it's a different program, but I know that EMIII was able to track the Linux regular client just fine since I ran a Foldix box for a long time being tracked by EMIII.

This isn't really a huge deal for me (despite the little essay I have written here). It's just an annoyance I was wondering if anyone else has had a problem with. Also, if someone has run into this and knows how to fix it, I would appreciate it.

I'm using Samba for filesharing access and FahSpy does have correct access and permissions set to monitor the Linux SMP client.

 
Well it happened again this a.m.
fahspyerror.bmp


As you can see the I folder is predicted 7 Oct 20:34:04, and the SMP was issued 7 Oct 20:43:34.

Plus for some reason the crap doesn't save my settings and I'm having to add the other drives again.
 
At the top of the Completed coloum it shows the the max completed client.
At the top of the Predicted coloum it shows the date-time of the first one to finish.
At the top of the Deadline coloum it shows the date-time of the first one to expire.

Hope that helps.

Luck ............. :D
 
You must log in or register to reply here.
Back
Top