Here's a link to the wu 104183560. It finally finished.
Gundolf - yes, I do have my machine set up to synch for time. Looks like I'm using time.windows.com instead of using time.nist.gov. And it's scheduled to happen once a week. I don't think the timing of the corresponds to what I'm seeing in messages (because it happened on different days - like 24 hrs later). Digging through the messages, it looks like it happened on Saturday, Sunday and Monday. But I haven't seen it resurface since.
Guess I won't worry about it. But I've noticed on several boards that people are seeing this.
I think that was Gundolf's point. The Windows Time Service for standalone workstations is set to contact the time server once a day by default, and doesn't really tell you anywhere what that time will be. It might be quasi-random but don't recall offhand.
Also, I read on MS TechNet that if you use a third party time setting utility, they recommend disabling Windows Time Service to avoid apparent 'strangeness' when the two get into 'fights' over who's got authority to set the timer the OS uses for it's clock and the RTC as well.
IIRC, if you look in Event Viewer there should be a message when W32time made the adjustment and a rough idea of how big it was. Maybe you can correlate that to some of the lost heartbeat events.
...
The Windows Time Service for standalone workstations is set to contact the time server once a day by default, and doesn't really tell you anywhere what that time will be. It might be quasi-random but don't recall offhand.
...
In XP, when you double click the clock in the status bar, the opening admin window has three tabs, the last of which is labelled "Internet". There you are told about the where and when of the last/next connection to a time server.
I found that by chance, after crawling for hours through the registry and the Internet to set my computer to connect twice a day :-)
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
In XP, when you double click the clock in the status bar, the opening admin window has three tabs, the last of which is labelled "Internet". There you are told about the where and when of the last/next connection to a time server.
Before anyone gets confused, that third tab is only visible on home (non-networked) or workgroup computers.
If an XP computer is attached to a domain (so we're only talking XP Pro here), the third tab is hidden, and the workstation gets its time synch from the domain controller - something like once every 15 minutes, IIRC, so the zero status error is unlikely to occur (at least, for this reason) on domain-joined workstations.
There's a new BOINC API available that the application can be built with. For the heartbeat mechanism it doesn't use the time of day clock, it just counts interrupts.
Trouble is that it needs the application to be rebuilt.
Not a CC, never a CC. The application built against the new fix should be capable to handle it.
I just re-read David's email on it though and I missed something the first time. He has changed this a couple of months ago, so the EAH app is already using it. Now it's no longer losing the heartbeat, instead it's losing the lockfile. And doing so 100 times before exiting.
I sent it back to the devs (added a couple as well). ;-)
Not a CC, never a CC. The application built against the new fix should be capable to handle it.
I just re-read David's email on it though and I missed something the first time. He has changed this a couple of months ago, so the EAH app is already using it. Now it's no longer losing the heartbeat, instead it's losing the lockfile. And doing so 100 times before exiting.
I sent it back to the devs (added a couple as well). ;-)
You're right, I was tired and didn't put 2 and 2 together! :-O
So is the verdict that tasks, that get the message this thread is about, will continue on to completion just fine? I got a bunch of the messages today but the tasks seem to be running still. My DSL connection may have been down because when I looked at BOINC it had the "need a network connection" window up.
RE: Here's a link to the wu
)
I think that was Gundolf's point. The Windows Time Service for standalone workstations is set to contact the time server once a day by default, and doesn't really tell you anywhere what that time will be. It might be quasi-random but don't recall offhand.
Also, I read on MS TechNet that if you use a third party time setting utility, they recommend disabling Windows Time Service to avoid apparent 'strangeness' when the two get into 'fights' over who's got authority to set the timer the OS uses for it's clock and the RTC as well.
IIRC, if you look in Event Viewer there should be a message when W32time made the adjustment and a rough idea of how big it was. Maybe you can correlate that to some of the lost heartbeat events.
Alinator
RE: ... The Windows Time
)
In XP, when you double click the clock in the status bar, the opening admin window has three tabs, the last of which is labelled "Internet". There you are told about the where and when of the last/next connection to a time server.
I found that by chance, after crawling for hours through the registry and the Internet to set my computer to connect twice a day :-)
Gruß,
Gundolf
Computer sind nicht alles im Leben. (Kleiner Scherz)
RE: In XP, when you double
)
Before anyone gets confused, that third tab is only visible on home (non-networked) or workgroup computers.
If an XP computer is attached to a domain (so we're only talking XP Pro here), the third tab is hidden, and the workstation gets its time synch from the domain controller - something like once every 15 minutes, IIRC, so the zero status error is unlikely to occur (at least, for this reason) on domain-joined workstations.
LOL... Yep, you would
)
LOL...
Yep, you would think that setting the clock would be a straightforward kind of thing.
You rapidly find out that for computers it is far from simple! ;-)
Alinator
There's a new BOINC API
)
There's a new BOINC API available that the application can be built with. For the heartbeat mechanism it doesn't use the time of day clock, it just counts interrupts.
Trouble is that it needs the application to be rebuilt.
I know they have been banging
)
I know they have been banging away on that for 6x for a while. Any word on what CC version we'll see that in yet?
Alinator
Not a CC, never a CC. The
)
Not a CC, never a CC. The application built against the new fix should be capable to handle it.
I just re-read David's email on it though and I missed something the first time. He has changed this a couple of months ago, so the EAH app is already using it. Now it's no longer losing the heartbeat, instead it's losing the lockfile. And doing so 100 times before exiting.
I sent it back to the devs (added a couple as well). ;-)
RE: Not a CC, never a CC.
)
You're right, I was tired and didn't put 2 and 2 together! :-O
Sheeesh!! Duhhhh.... Alinator!
RE: Now it's no longer
)
So is the verdict that tasks,
)
So is the verdict that tasks, that get the message this thread is about, will continue on to completion just fine? I got a bunch of the messages today but the tasks seem to be running still. My DSL connection may have been down because when I looked at BOINC it had the "need a network connection" window up.