Exaggerated to completion estimation


Advanced search

Message boards : SZTAKI Desktop Grid : Exaggerated to completion estimation

AuthorMessage
Vampus
Send message
Joined: Dec 12 05
Posts: 4
Credit: 4,126
RAC: 0
Message 7048 - Posted 6 Jan 2008 17:57:03 UTC

    Hi Guys. I\'ve been boinc-ing for some time, but I\'m not very savvy on the technical side of it all. Currently, I\'m running NumSys Search 2.06, and it\'s giving me grossly exaggerated \"to completion\" estimations.

    I believe this self corrects, albeit very slowly? I seem to be getting consistent 40+hour estimates, which scale down as time goes on, for WU\'s which take no more than 2 hours to complete. Do these false estimates impact my ability to get more WU\'s from Sztaki and other projects? What causes this? How can I fix it? And how can I prevent it happening?

    Odysseus
    Avatar
    Send message
    Joined: Feb 27 06
    Posts: 212
    Credit: 221,397
    RAC: 0
    Message 7051 - Posted 7 Jan 2008 4:53:02 UTC - in response to Message 7048.

      Last modified: 7 Jan 2008 4:56:34 UTC

      I believe this self corrects, albeit very slowly?

      Yes. It’s based on the host’s RDCF for the project (which you can check on your computer-summary page, right at the bottom of the time stats: “Result duration correction factor”). This is multiplied by the project’s estimate of each task’s running time on a reference system and divided by the host’s relative benchmark performance (vaguely speaking: I don’t know the exact procedures involved) to produce the figure you see in the Tasks panel.

      BOINC is conservative in evaluating RDCF, meaning that it tries to avoid downloading work that won’t be completed on time. An unusually long-running task pushes the figure up much more than a short one brings it down. But it will eventually converge on a sensible value, given a consistent run of performance data.

      I seem to be getting consistent 40+hour estimates, which scale down as time goes on, for WU\'s which take no more than 2 hours to complete. Do these false estimates impact my ability to get more WU\'s from Sztaki and other projects?

      It will have no effect on other projects. (Check your host pages elsewhere: you’ll see they’re all different, depending in part on how apt a given CPU architecture is for the specific computational requirements of each science app, and how efficiently these were compiled for it.) All it means WRT this project is that you’ll take on less work at a time than your connection-interval and cache settings suggest. RDCF has no part in the debt calculations that determine how much time is spent on each project, according to your resource share, and a high score won’t inhibit BOINC from asking for at least one task at a time. At worst, your host will need to contact the servers more often than you’d expect: unless you’re on a dial-up connection that shouldn’t be an inconvenience.

      What causes this?

      See above. Although the most recent search application seems pretty well-behaved—touch wood!—earlier versions had wildly unpredictable running times. Your computer probably has ‘bad memories’ of some monster tasks it crunched here in the past. And the current tasks may still be variable enough to prolong the settling-down period.

      How can I fix it? And how can I prevent it happening?

      You can ‘hack’ the relevant XML files in your BOINC folder to restore a more realistic figure, but it’s not without risk to the stability of your BOINC client, and I wouldn’t recommend it unless you know exactly what you’re doing. I have a G4/400 Mac with a DCF of 65 or something—its tasks start out showing hundreds of hours to complete—but it’s crunching away nonetheless.


      ____________

      Vampus
      Send message
      Joined: Dec 12 05
      Posts: 4
      Credit: 4,126
      RAC: 0
      Message 7053 - Posted 7 Jan 2008 13:54:46 UTC - in response to Message 7051.

        Thanks for that Odysseus. So the only check and balance against \"Monster tasks\" is the slow readjustment? But that the only real negative side effect is less WU\'s downloaded at one time, and thus more connectivity? Would resetting the project also reset the RDCF? And for that matter, based on what you\'ve said, doe s it even matter?

        I believe this self corrects, albeit very slowly?

        Yes. It’s based on the host’s RDCF for the project (which you can check on your computer-summary page, right at the bottom of the time stats: “Result duration correction factor”). This is multiplied by the project’s estimate of each task’s running time on a reference system and divided by the host’s relative benchmark performance (vaguely speaking: I don’t know the exact procedures involved) to produce the figure you see in the Tasks panel.

        BOINC is conservative in evaluating RDCF, meaning that it tries to avoid downloading work that won’t be completed on time. An unusually long-running task pushes the figure up much more than a short one brings it down. But it will eventually converge on a sensible value, given a consistent run of performance data.

        I seem to be getting consistent 40+hour estimates, which scale down as time goes on, for WU\'s which take no more than 2 hours to complete. Do these false estimates impact my ability to get more WU\'s from Sztaki and other projects?

        It will have no effect on other projects. (Check your host pages elsewhere: you’ll see they’re all different, depending in part on how apt a given CPU architecture is for the specific computational requirements of each science app, and how efficiently these were compiled for it.) All it means WRT this project is that you’ll take on less work at a time than your connection-interval and cache settings suggest. RDCF has no part in the debt calculations that determine how much time is spent on each project, according to your resource share, and a high score won’t inhibit BOINC from asking for at least one task at a time. At worst, your host will need to contact the servers more often than you’d expect: unless you’re on a dial-up connection that shouldn’t be an inconvenience.

        What causes this?

        See above. Although the most recent search application seems pretty well-behaved—touch wood!—earlier versions had wildly unpredictable running times. Your computer probably has ‘bad memories’ of some monster tasks it crunched here in the past. And the current tasks may still be variable enough to prolong the settling-down period.

        How can I fix it? And how can I prevent it happening?

        You can ‘hack’ the relevant XML files in your BOINC folder to restore a more realistic figure, but it’s not without risk to the stability of your BOINC client, and I wouldn’t recommend it unless you know exactly what you’re doing. I have a G4/400 Mac with a DCF of 65 or something—its tasks start out showing hundreds of hours to complete—but it’s crunching away nonetheless.



        ____________

        Odysseus
        Avatar
        Send message
        Joined: Feb 27 06
        Posts: 212
        Credit: 221,397
        RAC: 0
        Message 7057 - Posted 8 Jan 2008 5:15:43 UTC - in response to Message 7053.

          Thanks for that Odysseus. So the only check and balance against \"Monster tasks\" is the slow readjustment? But that the only real negative side effect is less WU\'s downloaded at one time, and thus more connectivity? Would resetting the project also reset the RDCF? And for that matter, based on what you\'ve said, doe s it even matter?

          A reset will probably reinitialize the RDCF, but I’m not sure. If you want to try it, make sure you have no SDG work on your host (whether in progress or completed) because all the files in the project folder will be deleted.

          Myself, I don’t think it matters, in particular if a connection to the Internet is always available to the host.

          Profile JLDun
          Avatar
          Send message
          Joined: Apr 24 06
          Posts: 4
          Credit: 948
          RAC: 0
          Message 7064 - Posted 10 Jan 2008 11:29:14 UTC - in response to Message 7057.

            A reset will probably reinitialize the RDCF, but I’m not sure.

            From personal experience, a Project Reset (either Reset or Detach & Reattach) will reset the RDCF (Result Duration Correction Factor) to 1.000000

            If you want to try it, make sure you have no SDG work on your host (whether in progress or completed) because all the files in the project folder will be deleted.

            This doesn\'t matter in resetting the RDCF, but it does matter for resending Work Units (WU\'s); some projects consistently resends WU\'s (SETI@Home is a \'crap-shoot\' in my recent experience).
            ____________

            Profile JLDun
            Avatar
            Send message
            Joined: Apr 24 06
            Posts: 4
            Credit: 948
            RAC: 0
            Message 7066 - Posted 10 Jan 2008 11:46:41 UTC - in response to Message 7048.

              ...and it\'s giving me grossly exaggerated \"to completion\" estimations.

              I believe this self corrects, albeit very slowly?
              ...which scale down as time goes on, for WU\'s which take no more than 2 hours to complete.

              Each project has an initial estimate for WU\'s you receive; each individual WU may belong to a certain \"class\" which are expected to take a certain amount of time, assuming RDCF=1.000000. Each WU processed under the expected amount of time Reduces\' the expected-processing-time by 10%. (Example: You have three work units. Each one has an estimate of 3 hours processing time. Your computer can process each one in two hours. The third work unit, by the time it starts, will have an estimated completion time of .9 [Since 1st WU is less than estimate]*.9 [Since 2nd WU is less than estimate]*3Hours [3rd WU Initial Estimate]).
              The estimated times will have a minimum time- how long it takes the shortest WU (of that \'WU class\') to complete.
              ____________

              Vampus
              Send message
              Joined: Dec 12 05
              Posts: 4
              Credit: 4,126
              RAC: 0
              Message 7068 - Posted 10 Jan 2008 14:05:29 UTC - in response to Message 7064.

                A reset will probably reinitialize the RDCF, but I’m not sure.

                From personal experience, a Project Reset (either Reset or Detach & Reattach) will reset the RDCF (Result Duration Correction Factor) to 1.000000

                If you want to try it, make sure you have no SDG work on your host (whether in progress or completed) because all the files in the project folder will be deleted.

                This doesn\'t matter in resetting the RDCF, but it does matter for resending Work Units (WU\'s); some projects consistently resends WU\'s (SETI@Home is a \'crap-shoot\' in my recent experience).

                After finishing and reporting all the SZTAKI WU\'s, I reset, and it does indeed reset the RDCF. The figure still seems a little blown out, but it\'s a lot easier to recover from 10 hours than from 40 hours :) Thanks for the assist and info.
                ____________

                Profile Purple Rabbit
                Avatar
                Send message
                Joined: Jan 15 08
                Posts: 1
                Credit: 50,692
                RAC: 0
                Message 7082 - Posted 16 Jan 2008 23:26:42 UTC

                  Last modified: 17 Jan 2008 0:05:58 UTC

                  I\'m new here, but not to BOINC. It really looks like the initial estimate for the time to complete is way off. My first task on a 3.4 GHz (HT) P4 was listed as about 14 hours to complete. It did it in less than 1 hour. Subsequent tasks reduced the estimated completion time in BOINC as expected.

                  I\'m curious how the initial time to complete is determined for this project. BOINC takes the project estimate and adjusts it to the BOINC benchmarks of the host. That kind of tells me the original project estimate is high by a bunch!

                  I think my old DX2-486-100 could do the task in the time originally specified (well, maybe not quite that fast) :-) It\'s not a problem in the long run because BOINC will make everything turn out all right. I\'m just remembering my first impression a day ago when I first started and saw the estimate (gasp).

                  The point I\'m making is that the initial estimates to complete can create a false impression for new participants. If someone is used to tasks that run an hour or two, then this might put them off.

                  Clearly this isn\'t a big deal. It\'s more of a \"marketing\" issue for new participants.

                  6dj72cn8
                  Send message
                  Joined: May 27 06
                  Posts: 36
                  Credit: 8,504
                  RAC: 0
                  Message 7087 - Posted 18 Jan 2008 9:07:42 UTC - in response to Message 7082.

                    I\'m new here, but not to BOINC. It really looks like the initial estimate for the time to complete is way off. My first task on a 3.4 GHz (HT) P4 was listed as about 14 hours to complete. It did it in less than 1 hour. Subsequent tasks reduced the estimated completion time in BOINC as expected.


                    New participants have got it easy! Those of us who have been here longer had a high RDCF due to previous long-running work units. When this new batch began I got an estimated time to completion of 750 hours. It actually took 4 minutes.

                    I am not disagreeing with the point you are making, just pointing out that things could be worse. :-)

                    The thing about SZTAKI work units is that they are highly variable in processing time.

                    ____________

                    Profile Nightbird
                    Forum moderator
                    Avatar
                    Send message
                    Joined: Jul 12 05
                    Posts: 920
                    Credit: 114,924
                    RAC: 0
                    Message 7097 - Posted 22 Jan 2008 22:44:22 UTC

                      And you can always modify manually in the client_state.xml the value for the duration_correction_factor.
                      ____________

                      Post to thread

                      Message boards : SZTAKI Desktop Grid : Exaggerated to completion estimation


                      Home | My Account | Message Boards


                      Copyright © 2017 SZTAKI Desktop Grid