Good Info, at least for me. I can stop testing my i3-pc, who had 11 not validated wu's in the last days and I was no longer shure: can I trust that pc?
The validator appears to be still running.
As it is at Albert@Home as well.
Also is this the same validation problem I am having over at Albert@Home as well?
With Win7 64 bit and Darwin 10.4.0 matched with Xeon processors not validating with my AMD processors and Win XP 32 bit or Linux 64 bit (they get the credit I miss out).
I have still many invalid and inconclusive tasks, ~10% of the total reported work per day.
It seems the invalidation never occurs when a task has been crunched by two AMD machines or by two Intel machines, it only occurs when the task was initially sent to one AMD and one Intel machine (the type of Intel CPU - Core2 Duo/Quad, Nehalem or Sandy/Ivy Bridge, desktop or Xeon - doesn't matter). But not all these task invalidated.
The core arithmetic is done in SSE, which shouldn't be that different between Intel and AMD CPUs.
The weird thing is that the code of the validator and the application is almost identical to that of the previous run S6LV1, where we didn't encounter such problems.
I am getting a lot of invalid's with my AMD machines too. I suspected it had something to do with AMD vs. Intel. I stopped running Einstein on those machines.
The SSE implementation is not different between them, but sometimes the OS system calls have different behaviour related to XMM registers.
For example I have a - fortunately graphic - algorythm, which uses XMM5, XMM6 and XMM7 registers to store predefined contstants for calculation. During this lenghty calculation it calls the Windows MsgWaitForMultipleObjects system call to get next piece of source data (produced by another thread). On AMD machines this system call clears the XMM0-XMM5 registers but leaves XMM6 and XMM7 registers untouched (on XP, XP x64, Windows7 x64), so the result image is corrupted: the solution is that after every call the program must reload the constant to XMM5 register. This behaviour has been seen on K7, K8 and K10 CPUs, but not on either Intel machines (P3, P4, Core2 and newer).
I don't know whether you use hand-written asm code, but maybe this helps.
Other wu´s which are validated a few days ago and no more seen under my account were often marked as "validation inconclusive"before the Validation was finished so a 3rd machine was often consulted.
S6BucketLVE validation
)
Good Info, at least for me. I can stop testing my i3-pc, who had 11 not validated wu's in the last days and I was no longer shure: can I trust that pc?
The validator appears to be
)
The validator appears to be still running.
As it is at Albert@Home as well.
Also is this the same validation problem I am having over at Albert@Home as well?
With Win7 64 bit and Darwin 10.4.0 matched with Xeon processors not validating with my AMD processors and Win XP 32 bit or Linux 64 bit (they get the credit I miss out).
Conan
We found a bug in the
)
We found a bug in the validator, fixed the bug and restarted the validator.
However it looks like that this bug wasn't causing the validation problems.
We'll continue to investigate.
BM
BM
I have still many invalid and
)
I have still many invalid and inconclusive tasks, ~10% of the total reported work per day.
It seems the invalidation never occurs when a task has been crunched by two AMD machines or by two Intel machines, it only occurs when the task was initially sent to one AMD and one Intel machine (the type of Intel CPU - Core2 Duo/Quad, Nehalem or Sandy/Ivy Bridge, desktop or Xeon - doesn't matter). But not all these task invalidated.
I hope this helps your investigation.
I'm afraid it doesn't. The
)
I'm afraid it doesn't.
The core arithmetic is done in SSE, which shouldn't be that different between Intel and AMD CPUs.
The weird thing is that the code of the validator and the application is almost identical to that of the previous run S6LV1, where we didn't encounter such problems.
BM
BM
RE: ... it only occurs when
)
Yes. Same here. My only AMD host produced to invalid tasks against an Intel. An other Intel CPU then validated agaist ther first Intel CPU
I am getting a lot of
)
I am getting a lot of invalid's with my AMD machines too. I suspected it had something to do with AMD vs. Intel. I stopped running Einstein on those machines.
The clue is "the code is ALMOST identical".
The SSE implementation is not
)
The SSE implementation is not different between them, but sometimes the OS system calls have different behaviour related to XMM registers.
For example I have a - fortunately graphic - algorythm, which uses XMM5, XMM6 and XMM7 registers to store predefined contstants for calculation. During this lenghty calculation it calls the Windows MsgWaitForMultipleObjects system call to get next piece of source data (produced by another thread). On AMD machines this system call clears the XMM0-XMM5 registers but leaves XMM6 and XMM7 registers untouched (on XP, XP x64, Windows7 x64), so the result image is corrupted: the solution is that after every call the program must reload the constant to XMM5 register. This behaviour has been seen on K7, K8 and K10 CPUs, but not on either Intel machines (P3, P4, Core2 and newer).
I don't know whether you use hand-written asm code, but maybe this helps.
....Yes. Same here. My only
)
....Yes. Same here. My only AMD host produced to invalid tasks against an Intel. An other Intel CPU then validated agaist ther first Intel CPU
Same here http://einsteinathome.org/account/tasks&offset=0&show_names=1&state=4&appid=22
Other wu´s which are validated a few days ago and no more seen under my account were often marked as "validation inconclusive"before the Validation was finished so a 3rd machine was often consulted.
I´m sorry link requires
)
I´m sorry link requires login just click on my name if you wanna look at this. :)