| Index | Recent Threads | Unanswered Threads | Who's Active | Guidelines | Search |
 |
World Community Grid Forums
Category: Support
Forum: Website Support
Thread: Workunit ID has been modified |
| No member browsing this thread |
|
Thread Status: Active Total posts in this thread: 9
|
|
| Author |
|
|
uplinger
Former World Community Grid Tech Joined: May 23, 2005 Post Count: 3952 Status: Offline Project Badges: 
|
Greetings,
We have modified the workunit id in the database to a lower number. For those of you who utilize the api, you will notice that work units have decreased by 2069000000. This is to help prevent the values from reaching the 2.14 billion value. Thanks, -Uplinger |
||
|
|
Sgt.Joe
Ace Cruncher USA Joined: Jul 4, 2006 Post Count: 7850 Status: Offline Project Badges: 
|
Interesting. This must have been the second time you have had to do this. I am curious as to why 2^31 was picked as a limit versus a higher number.
----------------------------------------Cheers
Sgt. Joe
*Minnesota Crunchers* |
||
|
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
|
||
|
|
adriverhoef
Master Cruncher The Netherlands Joined: Apr 3, 2009 Post Count: 2347 Status: Recently Active Project Badges:
|
Is it correct that my devices received Workunit IDs with a low number a few days before the announcement, even some before the move to IBM Cloud?
----------------------------------------App ModTime Exit Outc SentTime ReportDeadline ReceivedTime WorkunitId ResultId NameEDIT: - to answer myself - Yes, it is possible: We have modified the workunit id in the database to a lower number. For those of you who utilize the api, you will notice that work units have decreased by 2069000000. (Check the ModTime.)$ date -ud@1495212599 [Edit 2 times, last edit by adriverhoef at May 19, 2017 10:50:58 PM] |
||
|
|
Sgt.Joe
Ace Cruncher USA Joined: Jul 4, 2006 Post Count: 7850 Status: Offline Project Badges:
|
Interesting reading. That discussion dates from 2011. I know programming can be tough,but I am a little surprised a fix has not yet come about. I won't complain, because their work around allows the work units to keep flowing. Cheers
Sgt. Joe
*Minnesota Crunchers* |
||
|
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
Interesting reading. That discussion dates from 2011. I know programming can be tough,but I am a little surprised a fix has not yet come about. I won't complain, because their work around allows the work units to keep flowing. Cheers It so happens that I also stumbled a few weeks ago on the background of 2^31... Excel 32 bit only knows 'Long' integer up to 2.14 billion, precise 2147483648 as noted in the link, where in Excel 64 bit one can go a few factors further with 'LongLong'... is this what the restriction is about, dear techs... 32 bit progs? Why I got here, is because just converted from result name testing in the HT production version to ResultId testing which memontarily at 1562918641 which is about 584 million from the hard wall (with quorum redundancies probably closer 700,000,000). That would put us at 700m/2.5m about 275-300 days away from a needed retreat of that value. |
||
|
|
TPCBF
Master Cruncher USA Joined: Jan 2, 2011 Post Count: 2173 Status: Offline Project Badges:
|
It so happens that I also stumbled a few weeks ago on the background of 2^31... Excel 32 bit only knows 'Long' integer up to 2.14 billion, precise 2147483648 as noted in the link, where in Excel 64 bit one can go a few factors further with 'LongLong'... is this what the restriction is about, dear techs... 32 bit progs? Not necessarily. You would have the same problem in a 64bit program (which requires a 64bit OS, while a 32bit program will happily run on a 64 bit OS), if for that counter only a 32bit "wide" variable is being used. And you could prevent such an overflow even in a 32bit program if a proper 64bit counter variable would be used (the "long long" type you mentioned). Ralf |
||
|
|
SekeRob
Master Cruncher Joined: Jan 7, 2013 Post Count: 2741 Status: Offline |
It so happens that I also stumbled a few weeks ago on the background of 2^31... Excel 32 bit only knows 'Long' integer up to 2.14 billion, precise 2147483648 as noted in the link, where in Excel 64 bit one can go a few factors further with 'LongLong'... is this what the restriction is about, dear techs... 32 bit progs? Not necessarily. You would have the same problem in a 64bit program (which requires a 64bit OS, while a 32bit program will happily run on a 64 bit OS), if for that counter only a 32bit "wide" variable is being used. And you could prevent such an overflow even in a 32bit program if a proper 64bit counter variable would be used (the "long long" type you mentioned). Ralf The workaround in Excel 32bit VBA is dimming the large number vars as a double precision floating point (by some qualified as ill advised)... which is what I did as I do not know if any of [potential] hunting tool users have either. Tests are put up front if 32/64 so it uses the right routines, JIC Public MyTag$ #If VBA7 Then Public Declare PtrSafe Sub CopyMemory Lib "kernel32" Alias "RtlMoveMemory" (ByRef Destination As Any, ByRef Source As Any, ByVal length As Long) ... /ot |
||
|
|
TPCBF
Master Cruncher USA Joined: Jan 2, 2011 Post Count: 2173 Status: Offline Project Badges:
|
The workaround in Excel 32bit VBA is dimming the large number vars as a double precision floating point (by some qualified as ill advised)... which is what I did as I do not know if any of [potential] hunting tool users have either. Tests are put up front if 32/64 so it uses the right routines, JIC Well, that's probably one of the reasons why VB(A) has such a bad reputation...  As far as C goes, the "long long" integer data type (with a minimum data width of 64bits, and a range of at least −9,223,372,036,854,775,807 to +9,223,372,036,854,775,807) exists since the C99 specs (ISO since 1999, ANSI since 2000), though it didn't became a part of the C++ standard until C++11. But then pretty much all C++ compilers are also C compilers and likely supporting this data type well before that... The issue at hand, with the WU ID being only 32bit is AFAIK not a WCG specific thing but rather BOINC wide, so in order to change that, all BOINC clients/WUs out there need to be changed at the same time, as this is something that you can't implement (easily) with the necessary backwards compatibility to cover all of thousands of clients out there in BOINC land. IIRC, SETI had run into that issue a few years ago and needed to do a similar fix as Keith mentioned... Ralf |
||
|
|
|