2471 6/1/2018 18:04:14 New system time (1527890655) < old system time (1527890946); clearing timeouts

Any ideas why I am getting this message on my TR computer. I had a lot of problems with it and just got it back last night but this would indicate that something is wrong with the clock.
The computer is having problems filling its cache as it keeps saying that : Request for tasks too soon - 184 seconds, which does not make a lot of sense as I would think this action would be only triggered every 5 minutes.

I might be using too many cores and right now I can not remember where to reset that.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

There is some system contention there, as your CPU Run times are about 4 minutes longer then the CPU processing time.
Some people limit the number of cores they use.
I prefer to use all of them, but reserve some cores to support GPU crunching.

I use app_config.xml in the Seti project folder.

<app_config>
 <app>
  <name>setiathome_v8</name>
  <gpu_versions>
  <gpu_usage>1.00</gpu_usage>
  <cpu_usage>1.00</cpu_usage>
  </gpu_versions>
 </app>
 <app>
  <name>astropulse_v7</name>
  <gpu_versions>
  <gpu_usage>0.5</gpu_usage>
  <cpu_usage>1.0</cpu_usage>
  </gpu_versions>
 </app>
</app_config>

That will reserve 1 CPU core/thread for each GPU WU running. If you run out of GPU work (unlikely with your GPUs & CPU), those cores will be released & process CPU work till more GPU work is available.

I would suggest running Process Explorer and make sure there are no other processes other than the Seti CPU & GPU applications sucking up CPU time, and possibly interfering with system time keeping.
I would triple check you have your date (particularly the year & month), time, and time zone settings correct. When they are, re-sync with the Internet time to get it to the nearest second, then keep an eye on the time (every few hours) to see if it is gaining or losing over that period.

If after powering the system down the date & time reset completely, it would indicate the BOIS battery is dead (but given the age of the system, you'd have to be extremely unlucky for that to be the case). The BIOS time being correct, and the system losing time indicate a software issue- either a driver issue, or a programme affecting the OS time keeping.
It might be worth going in to the BIOS & checking that HPET (High Precision Event Timer) is Enabled. This is a better way of keeping the system time accurate than the much older methods.

---

Grant
Darwin NT

Did you change to enable the HPET clock by chance? What does bcedit /enum say?

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

And i'm not sure what all those errored WUs are about.

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x75D71A39 read attempt to address 0x00000000

Tail end of my GPU result file,

CPU affinity adjustment enabled
Priority of worker thread raised successfully
Priority of process adjusted successfully, high priority class used
OpenCL platform detected: Intel(R) Corporation
OpenCL platform detected: NVIDIA Corporation
GPUlock enabled. Use -instances_per_device N switch to provide number of instances to run if BOINC is configured to launch few tasks per device.
BOINC assigns device 1, slots 1 to 1 (including) will be checked
Used slot is 1;	Info: BOINC provided OpenCL device ID used
Info: CPU affinity mask used: 2; system mask is fff

Yours-

CPU affinity adjustment enabled
Priority of worker thread raised successfully
Priority of process adjusted successfully, high priority class used
WARNING: boinc_get_opencl_ids failed with code -1
Error: Getting Platforms. (clGetPlatformsIDs)
GPUlock enabled. Use -instances_per_device N switch to provide number of instances to run if BOINC is configured to launch few tasks per device.
BOINC assigns device 0, slots 0 to 0 (including) will be checked


Unhandled Exception Detected...

- Unhandled Exception Record -
Reason: Access Violation (0xc0000005) at address 0x75D71A39 read attempt to address 0x00000000

Followed by the debugger dump.

For some reason, the application is crashing at the point where it goes to check the device allocated to process the work.
Changed Drivers recently, AV update? OS update? There is no indication of the OpenCL platform being detected, which it needs to run the OpenCL SoG application.

I'd suggest downloading from Nvidia a driver earlier than the current one, and do a clean install and see if that sorts things out. v391.35 is working OK for me on my Win10 64bit Pro system.

EDIT-
Or have you already done that? I found some more recent WUs that haven't errored out.

---

Grant
Darwin NT

Also CPU runtimes are also longer than I would have expected.
You have 32GB of RAM, how many modules have you used for that?
Ideally, 8*4GB DIMMs. If it's 4*8GB DIMMs, you need to check you have them in the correct slots for best memory performance (also for 2*16GB DIMMs). Different number of memory modules, different slots should be used for best memory throughput.

---

Grant
Darwin NT

Also CPU runtimes are also longer than I would have expected.
You have 32GB of RAM, how many modules have you used for that?
Ideally, 8*4GB DIMMs. If it's 4*8GB DIMMs, you need to check you have them in the correct slots for best memory performance (also for 2*16GB DIMMs). Different number of memory modules, different slots should be used for best memory throughput.

Grant, thanks for all the hints. I really appreciate them.
My memory in 4 X 8 and they are in the correct slots. My run times seem to me to be consistent with what they were.

Basically I had to reinstall Lunatics and the drivers to get it working. Still had clock problems but it seemed to be working. I had almost no time to devote to the computer but seemed to be forced into it by a power hit. The computer kept running on battery but I had a bit of free time so I started with a reboot and BIOS reset to DEFAULT. On that reboot the W10 update decided to install so that blew me away for another day as I was again out. Finally managed to again reload the drivers after the update installed and the system seems to be running OK now. I am certain that the video drivers were somehow blown up several times and the system would come up and start running and then all of a sudden the drivers would be gone.

I am going to let things run for awhile before I go back in and play with clock speeds.

Again thanks, I checked everything you suggested.

My app_comfig is the same as yours.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

And i'm not sure what all those errored WUs are about.


EDIT-
Or have you already done that? I found some more recent WUs that haven't errored out.

Those might have been happening when the system might have overheated on a warm day when I was not at home to cool things down. Just do not know.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

Did you change to enable the HPET clock by chance? What does bcedit /enum say?

No, no changes there. (and is that a RUN command, I have not tried it, remember I am on W10)

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

Yes that is a Windows Terminal command line entry.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Basically I had to reinstall Lunatics and the drivers to get it working. Still had clock problems but it seemed to be working. I had almost no time to devote to the computer but seemed to be forced into it by a power hit. The computer kept running on battery but I had a bit of free time so I started with a reboot and BIOS reset to DEFAULT. On that reboot the W10 update decided to install so that blew me away for another day as I was again out.

If there were a whole bunch of updates (or you got one the major updates finally happening) being downloaded & setup for installation, that might account for some of those WUs showing much longer runtimes than usual, with Windows update sucking up a lot of CPU resources.
I had to disable Windows Update on my old C2D Vista system because it would use a whole CPU core for hours on end. My Win10 system hasn't got to that point (yet).
And scrambled video drivers would probably account for the errored WUs. Running Win10 pro you can use the Group Policy Editor to stop Windows Update from doing any driver updates.
How to stop Windows Update from updating drivers.

---

Grant
Darwin NT

Another thought to put into the melting pot...
A few years ago I had an overclocked computer that would periodically loose track of "clock face" time. The description in your first post is very much the same as I was seeing, PC time was skipping around and causing things to happen in the future or past in a fairly random manner. In your case you are seeing automatic calls for work going out from your computer far too soon (184 seconds instead of >500 seconds). The annoying thing in tracking this problem down is that it is neither consistent nor permanent - I didn't know exactly what was going on until I was at the PC when the displayed time dropped back by a couple of minutes, then a few minutes later jumped ahead of itself.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Another thought to put into the melting pot...
A few years ago I had an overclocked computer that would periodically loose track of "clock face" time. The description in your first post is very much the same as I was seeing, PC time was skipping around and causing things to happen in the future or past in a fairly random manner. In your case you are seeing automatic calls for work going out from your computer far too soon (184 seconds instead of >500 seconds). The annoying thing in tracking this problem down is that it is neither consistent nor permanent - I didn't know exactly what was going on until I was at the PC when the displayed time dropped back by a couple of minutes, then a few minutes later jumped ahead of itself.

Yes Rob, but how did you fix it. Do you remember?

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

And scrambled video drivers would probably account for the errored WUs. Running Win10 pro you can use the Group Policy Editor to stop Windows Update from doing any driver updates.
How to stop Windows Update from updating drivers.

I had done this in the past when I set up the computer but apparently it got changed along the way. Thanks for reminding me again. I would like to say that I always reload the NVidia drivers after each update, just to be on the safe side. This computer is on the normal update path. I do have two other computers which are on the Fast Track.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

Reduced the overclocking (from memory)

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

Sounds good and likely.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

This computer is on the normal update path. I do have two other computers which are on the Fast Track.

I've got mine set for Semi-Annual, Feature updates delayed 90 days, Quality updates delayed 30 days. Gives them time to sort out any issues.

---

Grant
Darwin NT

Sorry for this late reply, but I have been busy elsewhere.

Recently, I had one computer with a similar problem of the clock randomly jumping forward or back, and not just a few minutes but years. It turned out that my CMOS battery had given out, and even though power was being supplied 24/7, the clock wasn't getting any of it. Replaced the battery and the problem stopped.

By the by, it was a stock configuration, no OC.

Sorry for this late reply, but I have been busy elsewhere.

Recently, I had one computer with a similar problem of the clock randomly jumping forward or back, and not just a few minutes but years. It turned out that my CMOS battery had given out, and even though power was being supplied 24/7, the clock wasn't getting any of it. Replaced the battery and the problem stopped.

By the by, it was a stock configuration, no OC.

That would be doubtful as the system is less than a year old.
Thanks for thinking of me.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

Sorry for this late reply, but I have been busy elsewhere.

Recently, I had one computer with a similar problem of the clock randomly jumping forward or back, and not just a few minutes but years. It turned out that my CMOS battery had given out, and even though power was being supplied 24/7, the clock wasn't getting any of it. Replaced the battery and the problem stopped.

By the by, it was a stock configuration, no OC.

That would be doubtful as the system is less than a year old.
Thanks for thinking of me.

That's not as silly as you may think Bill as I've had a couple of brand new boards here over the years here that have had faulty batteries installed, mind you that would be well less than 1% of those handled (but is possible if the overclock isn't the problem).

Cheers.

I agree it is possible.
However since that brief incident it has not happened again. I am in fact thinking about trying to up the clocks a bit to performance settings and see what happens.
And again, HOWEVER, temps are rising here and I am afraid to do so. I have the A/C running in the small passageway that the computers are in but it is not that good a unit and it was built in when I had the garage and mud room built.
So for now I will be happy that all it running well.

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours