Message boards :
Number crunching :
Runnitme discrepancy
Message board moderation
Author | Message |
---|---|
Send message Joined: 5 Nov 11 Posts: 25 Credit: 1,450,603 RAC: 0 |
Hi, I had a few task, that were running, for example, for 30h. When validated, the time credited was only 32000 sec, which is less than 9h. Why is that? |
Send message Joined: 8 Jul 11 Posts: 46 Credit: 7,144,042 RAC: 0 |
Hi, Do you have a workunit number for these? The boinc manager measures the runtime and calculates the requested credit but we also print some times that we could cross check against. |
Send message Joined: 8 Jul 11 Posts: 1323 Credit: 410,725,298 RAC: 245,473 |
I think this WU is an example: http://numberfields.asu.edu/NumberFields/workunit.php?wuid=317391 The elapsed time the program measures inside the app is different from both the run time and the cpu time reported by the client, but it's much closer to the cpu time. Not sure what's causing the huge difference between run time and cpu time. |
Send message Joined: 3 Sep 11 Posts: 30 Credit: 7,913,349 RAC: 3,059 |
Nearly all work units that run on my machines and a number of others that I have checked show that the CPU time and the RUN time are nearly the same or very close. However I have found that the two computers listed as currently number 1 and number 3 don't appear to obey this. Both have massive benchmarks way beyond what you would think they could possibly be. This Host is currently number one, it is a Core i5 with 4 cores and is out producing the number 2 computer with 48 cores. It has huge RUN times but more normal CPU times and is able to output a large number per day which would be impossible with the quoted RUN Times. This Host is currently number 3, a QEMU 4 core CPU again with much larger RUN Times compared to CPU times but kept down to more reasonable levels compared to the Number 1 machine. I believe they should be looked at, particularly Host 1461. I am curious how the run times are so large but the cpu times are so low. Conan |
Send message Joined: 2 Sep 11 Posts: 57 Credit: 1,274,345 RAC: 0 |
I suspect they are faking the run times. It's easy to do. In fact it looks to me like the hosts in the top 3 positions (sorted by RAC) might all be bogus. In position #1, host 1461 : I could be wrong but I don't think that CPU can be overclocked enough to give the benchmarks it's reporting. The owner has either altered the true benchmarks reported by the client or he's running a custom client designed to report bogus benchmarks. The fact that his run times are that much higher than his CPU times suggests to me that he is altering the run times reported by the client. It's very easy to do that by manually editing a few files the client uses. The procedure is not convenient when applied to more than a few results so I would say he's automated the job with a clever script. I suppose the high run times might be due to a bug but I don't think the high benchmarks are. In position #2, host 1575 : Is this for real? A 48 core AuthenticAMD AMD Engineering Sample? The benchmarks look way too low but I doubt anybody would fake low benchmarks. I reserve judgement on this host. In postion #3, , host 2507 : The benchmarks seem a little high but since it's a virtual CPU it's hard to say. Again, the huge discrepancy between run time and CPU time might be a bug but I doubt it. I have a problem with my theory that #1406 and #2507 are faking the run times with a script. If I were to write such a script I would probably just multiply the CPU time by a number to get the run time and be done with it. The ratio of run time to CPU time would then be a constant. That's not the case with #1406 and #2507 so if the run times are the product of a script then it's a somewhat sophisticated script that generates a bound random CPU time multiplier. Or maybe the owner has a totally different method for arriving at the bogus run time. Or maybe he's not cheating at all. BOINC FAQ Service Official BOINC wiki Installing BOINC on Linux |
Send message Joined: 8 Jul 11 Posts: 1323 Credit: 410,725,298 RAC: 245,473 |
Thanks for investigating this. I was warned that cheaters would surface after I removed CreditNew. I wonder what's worse, cheaters or CreditNew? |
Send message Joined: 2 Sep 11 Posts: 57 Credit: 1,274,345 RAC: 0 |
Credits is all about competition. They exist to encourage competition because we all know none of us will do a bloody thing unless there is some competition involved. Altruism, charity and all that other nonsense never existed and never will. The problem is, competing for credits is as boring as listening to grass grow. If you feel like you're being walked all over on the playing field you go out and buy the fastest rig you can get, maybe just buy the parts and build your own so you can have 2 plus a smokin fast GPU for the price of 1, you plug it in and a week later you realize other than the thrill of pricing and plugging in some new hardware, you're still bored stiff with crunching. You realize all it takes is more silicon, not a lot of skill or finesse and there's so many guys out there who have their boss's big network on BOINC, you're never going to get close to the top anyway. So... what makes it interesting and competitive? Finding out how to cheat the system is what. See who can discover the back door and scoop a bunch of credits without being caught. That's competitive and it's not boring. And it's not stealing because credits don't cost projects anything anyway. Besides, some projects give out half a million of them for 10 seconds of CPU time so they're worthless and meaningless from the get go. Oh yes, I'll take cheaters before CreditNew any day. I admire their innovation, the research and work they put into it and the elegance of some of their methods. Hey, the community must have competition and that's exactly what it's got. I think cheaters should be graded and given little stars, gold for the year's best, red for second best and so on. I don't think CreditNew will stop a benchmark cheat but I could be wrong. I think the 2 aforementioned benchmark fudgers were cheating even before you turfed CreditNew. CreditNew does reduce the inflated run time cheat but doesn't totally eliminate it. My advice is neither cheaters nor CreditNew is as bad as a 20 ft. crocodile in your server closet so be happy. After the current round of fun plays out, Eric, the next step for you (if you want to be part of the fun and we won't hold it against you if you would rather not) is to write some complicated "fixed on the server" type of system, debug it, deal with all the complaints that it doesn't give enough credit or doesn't deal with X equitably from the same crew who are never satisfied with the credits and then watch that bit of work get cheated too. Those are your gold star cheaters. Those are the guys I truly admire. It will take them weeks, months even but they'll cheat you in the end. Why? Well, why not? Why climb Everest? So, Eric, are you down? BOINC FAQ Service Official BOINC wiki Installing BOINC on Linux |
Send message Joined: 19 Aug 11 Posts: 76 Credit: 2,002,860 RAC: 0 |
I have a problem with my theory... brilliant! what if host 1461 is a real machine which is hosting host 2507? and i am pretty sure that's it. and about that 48-core AMD: history! 64 core 1 HE blades are on stock... |
Send message Joined: 2 Sep 11 Posts: 57 Credit: 1,274,345 RAC: 0 |
They're both showing Linux as the OS but they have different kernel versions. Maybe QEMU somehow alters the kernel version for virtual CPUs? They could indeed be the same host. Maybe Eric can see the IP address and/or email address for both. BOINC FAQ Service Official BOINC wiki Installing BOINC on Linux |
Send message Joined: 8 Jul 11 Posts: 1323 Credit: 410,725,298 RAC: 245,473 |
They're both showing Linux as the OS but they have different kernel versions. Maybe QEMU somehow alters the kernel version for virtual CPUs? They could indeed be the same host. Maybe Eric can see the IP address and/or email address for both. I did look into this last night. I need to be careful with what I say though, because users expect their information to remain private. But I will say that there is some truth to what Frank says and these particular hosts don't appear to be cheating. Eric |
Send message Joined: 8 Jul 11 Posts: 1323 Credit: 410,725,298 RAC: 245,473 |
After the current round of fun plays out, Eric, the next step for you (if you want to be part of the fun and we won't hold it against you if you would rather not) is to write some complicated "fixed on the server" type of system, debug it, deal with all the complaints that it doesn't give enough credit or doesn't deal with X equitably from the same crew who are never satisfied with the credits and then watch that bit of work get cheated too. Those are your gold star cheaters. Those are the guys I truly admire. It will take them weeks, months even but they'll cheat you in the end. Why? Well, why not? Why climb Everest? So, Eric, are you down? I think I'll pass on creating my own fix for the credit problem. With the holidays coming, my full time job, and being admin for this project, I don't have much time to spare for much else. Sorry to disappoint you. :-) Eric |
Send message Joined: 2 Sep 11 Posts: 57 Credit: 1,274,345 RAC: 0 |
They're both showing Linux as the OS but they have different kernel versions. Maybe QEMU somehow alters the kernel version for virtual CPUs? They could indeed be the same host. Maybe Eric can see the IP address and/or email address for both. I suggested looking at their addresses but would never ask you to reveal user information. That wasn't my intention. A stock i5-2500K CPU @ 3.30GHz doesn't earn benchmarks like host 1461 reports and I doubt very much one can be overclocked high enough to produce those numbers. Then there's the fact his run times are so much higher than his CPU times. That's neither a bug nor a glitch. However, I couldn't care less if he's cheating or not. Other can press the point if they want to. BOINC FAQ Service Official BOINC wiki Installing BOINC on Linux |
Send message Joined: 8 Jul 11 Posts: 1323 Credit: 410,725,298 RAC: 245,473 |
I get 3.4 GFLOPS on my core i5-2500K @ 3.3GHz. Host 1461 gets 5.3 GFLOPS, a 56% increase. Overclocking by 56% does not seem unreasonable. And how accurate are the benchmark tests anyways? I know I don't get the same values every time I run the benchmarks. And then there's the question of linux vs. windows (my core i5 runs windows and host 1461 runs linux); in my experience, code built on linux is faster than the exact same code built for windows - so I wouldn't be surprised if benchmarks on a linux platform beat the benchmarks on a windows platform for the exact same type of CPU. In regards to run time versus cpu time, I have noticed big variations on my own hosts. On my core-i7, the variation seems to be the worst when boinc is using all 8 cpus and I am also running other computationally intensive tasks. The boinc tasks are running (not suspended) but are competing for the CPU resources and the elapsed time displayed in the boinc manager increases very slowly (this would suggest the manager is displaying cpu time, not run time??). I also remember reading somewhere that older boinc clients can report big differences between these two times. In summary, I can't say that host 1461 is cheating. Eric |
Send message Joined: 19 Aug 11 Posts: 76 Credit: 2,002,860 RAC: 0 |
I get 3.4 GFLOPS on my core i5-2500K @ 3.3GHz. Host 1461 gets 5.3 GFLOPS, a 56% increase. Overclocking by 56% does not seem unreasonable. And how accurate are the benchmark tests anyways? LOL! only bogomips are less accurate. I know I don't get the same values every time I run the benchmarks. And then there's the question of linux vs. windows (my core i5 runs windows and host 1461 runs linux); in my experience, code built on linux is faster than the exact same code built for windows - so I wouldn't be surprised if benchmarks on a linux platform beat the benchmarks on a windows platform for the exact same type of CPU. current boinc clients for linux64 are built with GCC and are much better optimized. my I5M running win32: Measured floating point speed 2601.5 million ops/sec Measured integer speed 6286.39 million ops/sec same machine running linux64: Measured floating point speed 2957.11 million ops/sec Measured integer speed 14869.31 million ops/sec if someone compiles his own version using GCC 4.6.x for a machine that supports AVX - go figure. |
Send message Joined: 8 Jul 11 Posts: 1323 Credit: 410,725,298 RAC: 245,473 |
Wow! Check out these run times: http://stat.la.asu.edu/NumberFields/workunit.php?wuid=623684 http://stat.la.asu.edu/NumberFields/workunit.php?wuid=606269 I wonder who this might be... |
Send message Joined: 2 Sep 11 Posts: 57 Credit: 1,274,345 RAC: 0 |
Yikes! Those are mine! Did you see the stderr? Says "we r anonymous all ur creds r belong 2 us free Julian Asange". Looks like that machine has been taken over by that Anonymous hacker group. I'll clean it up and beef up security. BOINC FAQ Service Official BOINC wiki Installing BOINC on Linux |
Send message Joined: 19 Aug 11 Posts: 76 Credit: 2,002,860 RAC: 0 |
Wow! Check out these run times: strike! you caught a fraggle - send him to report to Marjory.. ;) |