Gamma-ray pulsar search @2 1.10 take a while... No ?

jimmy
jimmy
Joined: 11 Jul 13
Posts: 5
Credit: 3580606
RAC: 0
Topic 197125

Hi !

I just want to know if is it normal...
It take about 24-25 hours to calculate the Gamma-ray pulsar search @2 1.10.

I have a I7-3770 with 8 Go of RAM...

Tanks.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5872
Credit: 117289301685
RAC: 36025458

Gamma-ray pulsar search @2 1.10 take a while... No ?

I can't find any FGRP2 tasks in your tasks list that have taken 25 hours to crunch.

Maybe they are estimated to take that long and will actually take a lot less when they finally get done??

I have an i5-3570K which does FGRP2 tasks in a little over 10 hours. When first downloaded, they are estimated to take over 30 hours. The reason for this is that the machine also crunches BRP5 tasks (3 at a time) and these take longer than estimated. With a single DCF (duration correction factor) to correct the estimate, BOINC doesn't stand a chance of getting it right with the two different apps 'pulling strongly in opposite directions' so to speak! :-).

Cheers,
Gary.

Holmis
Joined: 4 Jan 05
Posts: 1118
Credit: 1055935564
RAC: 0

I'm also running an i7-3770,

I'm also running an i7-3770, I have the k version and have overclocked it to 4.2 GHz and have HT on so 8 "cores".

My times for FGRP2 tasks seems to be about what you see, 23 - 27 hours.

So I would say that's normal if your running with HT on.

jimmy
jimmy
Joined: 11 Jul 13
Posts: 5
Credit: 3580606
RAC: 0

Mmmm... Gary I don't know

Mmmm... Gary I don't know where you look but I see 5 task that it took about 85 000 sec (23 hours) and more... And it's not the estimation, but the real time.

Ok Holmis, I think is normal..

Just another thing, if I look in the FGRP2 tasks, I can see some task that it took only 2 hours, 3 week ago (19 July)... So !?

Tom*
Tom*
Joined: 9 Oct 11
Posts: 54
Credit: 366729484
RAC: 0

RE: So? Last modified: 4

Quote:
So?

Last modified: 4 Jul 2013 20:37:37 UTC

Quote:
We found a bug in the new App version 1.09 when processing the old, short tasks (name = "LATeah0026U...") are not affected, and the bug is fixed in App version 1.10 (out today).

That seems to explain the short vs long LAT tasks however your wingperson on workunit http://einsteinathome.org/workunit/171907436

only took 2369 runtime secs while you took 97,098 secs.
Your other "LONG" workunits are ok and match your wingperson.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5872
Credit: 117289301685
RAC: 36025458

RE: Mmmm... Gary I don't

Quote:
Mmmm... Gary I don't know where you look ...


Yes you do, because I gave you a link :-).

Quote:
but I see 5 task that it took about 85 000 sec (23 hours) and more... And it's not the estimation, but the real time.


Of course everybody can see them now, but at the time I looked at that list and then posted about it, they were all still 'in progress'. The first wasn't reported until quite a few hours after that. My problem was that I wasn't smart enough to think immediately about HT as a possible explanation and then check if you were using it or not.

Quote:
Just another thing, if I look in the FGRP2 tasks, I can see some task that it took only 2 hours, 3 week ago (19 July)... So !?


The 'size' of FGRP2 tasks was increased by a factor of 11 quite some time ago. There was also a batch of old, 'short' tasks (LATeah0016U*) released more recently which took more than a week to get completely issued. The tasks you refer to were part of that batch.

I still see the occasional short task being resent from that lot. However, this has become rather infrequent now.

Cheers,
Gary.

Gary Roberts
Gary Roberts
Moderator
Joined: 9 Feb 05
Posts: 5872
Credit: 117289301685
RAC: 36025458

RE: ... your wingperson on

Quote:

... your wingperson on workunit http://einsteinathome.org/workunit/171907436

only took 2369 runtime secs while you took 97,098 secs.
Your other "LONG" workunits are ok and match your wingperson.


The time of 2369 seconds is not the total run time for that task.

I've seen on many occasions, that some machines do not record the proper time when a task is stopped (perhaps due to a crash for example) and then restarted from a saved checkpoint. After the restart, the run time starts from zero again, even though the task may already be more than 90% complete. Obviously, something like this has happened in the example you give.

Cheers,
Gary.

jimmy
jimmy
Joined: 11 Jul 13
Posts: 5
Credit: 3580606
RAC: 0

Oh ok tanks everybody!

Oh ok tanks everybody!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.