Folding Forum

Frametimes written to fahlog correspond with the host's clock but I admit I'm not exactly sure what you mean with drifted and how it would affect fahmon. I remember that notfreds sometimes outputted allot of frames at a time, but since that's fixed somehow I never had issues with vm's ( though I only run one here, and one on another pc ).

bollix47 wrote:Also, there is a version 2.3.4 now .... maybe try updating?

Didn't see that edit sorry, I checked for updates through fahmon itself, it didn't report any



Care to show me where it is? This is the latest public build from his site, don't lecture me when you're not even right on the facts

lol .... I'm using "Bleeding edge code" via svn which is where I got 2.3.4 from and it's actually an older version that was downloaded some time ago ... sorry for any confusion

I'm using 2.3.99.1 on another computer and do have a couple notfred clients running and haven't seen this problem but they are not running in a vm.

I've seen reports where the time in the vm somehow changed from the host time and caused problems but as you've said the fahlog is showing the same time as the host so time drift is probably not happening.

By the look of your frame times you're using 4 cores in your vm. What vm are you using?

It's ok I was confused abit as well, I just looked on the xp machine and fahmon greeted me with a 'there is an 2.4.0 version, do you want to download it?', click yes, go to the same page with 2.3.99.1

I'm using vmware 6.4.2, installed a trail version so I can run four cores, but when that finishes I will give vbox a try since it's free and gives four core support.

Fahmon corrected itself just now after it got to 18%



I'm confused, but atleast it's measuring correct again. I do notice the vmware network is really slow here, I have to wait minutes before the vm's show up in my network places.. Can that have anything to do with it?

Fahmon corrected itself just now after it got to 18%

I'm unsure what the problem might be but I suspect the vm somehow is messing things up.

Fahmon is still showing wrong projections only now they are much shorter than they should be.

lol ... I would love to be able to get 46,080 PPD on a regular SMP project.

Just an observation but your UTC time in your log seems to be around 2 hours later than the time in my logs.

Shouldn't UTC time be the same no matter where you live?

Well there definetly is a timeing issue going on...



It went from slow to fast pretty quickly :e

I agree. Please check the time being used in your vm guest. It should be configured something like GMT +1 or probably +2 depending on your time difference.

Also, take a look at your gpu logs to see if they're 2 hours different than your notfred log. If they are then there's something wrong with the time on your vm guest. If not, then the time on your host is wrong.

Gpu and VM have a two hour time diffrence as they should, my system time is two minutes after my phone so I think it's ok as well. The vm seems to consistently have the same time diffrence with my host when I look at the frame times reported ( interval keeps the same doesn't it ).

At time of post, vm says it's 15:11:07 UTC which is correct.

Idk...

At time of post, vm says it's 15:11:07 UTC which is correct.

That would be your local time .... not UTC. i.e. the time on your vm guest is not configured for GMT +2 .... after changing that you will probably have to adjust the local time manually unless you're syncing to a time server

My logs are showing current UTC time as 13:19

http://www.worldtimeserver.com/current_time_in_UTC.aspx

bollix47 wrote:

At time of post, vm says it's 15:11:07 UTC which is correct.

That would be your local time .... not UTC. i.e. the time on your vm guest is not configured for GMT +2 .... after changing that you will probably have to adjust the local time manually unless you're syncing to a time server

Code: Select all

[13:02:49] Completed 212500 out of 250000 steps  (85%)
[13:09:21] Completed 215000 out of 250000 steps  (86%)

My logs are showing current UTC time as 13:19

http://www.worldtimeserver.com/current_time_in_UTC.aspx

When in bash, Date gives me UTC as two hours later as your reported time. But NotFred doesn't accept ntpdate nor rdate ( not that I know rdate but it was another suggestion I found ).

How do I change the date then? Date mm-dd-yyyy hh:mm:ss doesn't work either ( linux n00bie I guess ).

Though still, NF has been that way since last boot I imagine and previous wu read correctly so I'm still not convinced it's due to time shift ( also ,the 2h diffrence was steady along the timeperiod in the log ).

It seems you are not alone.

Have a look at the following post and it's previous post:

http://www.techreport.com/forums/viewto ... re#p961982

Thanks for the link, but I'm not convinced 100% the error in ppd is due to Notfred's. Reason is that the ppd is calculated from frametimes diffrence ( eg 14:26:05 to 14:36:05 is a 10 minute frame ) and it should only take into account the time stamp on the last frame for ETA.

Atleast I don't have fahmon's source infront of me but that is the way I would do it, and from previous talks with Andrew in the past I got the impression it's also how fahmon works. That's why I wasn't convinced ( still not ) it's the timeshift, as it's not shifting during processing but it's a 2h diffrence which doesn't change during processing. Am I making sence?

Edit:

Issue solved by Jevans, he noticed my download times also shifting, and while I was telling/typing it shouldn't matter unless you measure 'effective' rate I realised... I was measuring effective rate, not based on the last (3) frame(s).

So it's got nothing to do with fahMon, sorry Andrew for the confusion, needed someone else to state the obvious

Edit2 hours and hours later.. relaxing, suddenly a hunch.. went to look at that link I glanced over I noticed two things, one it was something I already read and b> it indeed has been so long ago I almost forgot ( 04!! ). Still thanks I guess

In order to decide if the client is hung, FahMon subtracts the beginning of the last from from "now" If the system clocks are not synchronized, then the duration of the current frame can be miscalculated. A two hour difference might add 2 hours or it might add 22 hours, depending on the sign of the difference. (The dates are both assumed to be "today".)

Thanks for the explanation Bruce I needed, wurse I might need it again..

This should not happen I think, I understand the mechanism to check for hung clients but the last frame calculation should not be changed by a hung status it should still be the time between the last checkpoints it can find. The two are in my view not related?

Assume the following: Current time: 11:18:00.

The last two frame times are
00h07m32s
00h07m32s

and the current frame duration is
22h01m07s
and the client is "hung"

Are you sure that the 3 frame method doesn't count all three?

The other methods probably understand that the date must have changed, too.