Folding Forum

STATS have resumed.

My logs are showing five duplicate timestamps.
Last valid update was Mon Mar 08 03:25:17 GMT 2021

Timestamps, since the restart, have drifted about 3 minutes, settling in at 52:25 initially, currently 55:09.
So, it appears, the drift of ~3.6min/day that I was seeing, is still occurring.

Timestamps, since the restart, have drifted about 3 minutes, settling in at 52:25 initially, currently 55:09.
So, it appears, the drift of ~3.6min/day that I was seeing, is still occurring.
But, that is a different thread. The stall is fixed.

Yes. Happy to see the new page project recovered gracefully, showing the combined daily stats for the missing EOD end-of-day. This was the result of the decision to retain each hourly update, seemed like a good idea at the time... now I see the 'why'.

I was working on the tracker to follow the shifting updates. Inspired to utilize the hourly updates, I wrote a fast updater. Fast & phone friendly.. no ads, no graphics, no trackers. Hopefully, they don't revert to the old 3hr cycle. If people are interested, I'll upload the reduced active data ...

Stat feeds have stalled... output from my feed timestamp tracker log.
20210227-010001
Sat Feb 27 04:04:26 GMT 2021
TimeStamp FAIL: EXITING

Well, the updates have stalled again. They were gaining ~3.6min/day based on the data from the timestamp tracker I built. I know they had switched to a 3hr update somewhere in the past and I was excited to see them updating hourly. I even build a nice phone-friendly page around the opportunity to ha...

The stats download timestamp and update times appear to be in a constant state of drift.
It's now Wed Feb 24 23:57:53 GMT 2021

These should be occurring at a relatively fixed period, right?

I happened to notice that the Time Header on the User Donor Stats has shifted. Change occurred 2/10 Was there a reason for the change? +6 would match CST, but +5 would be EST for the US EOD (end-of-day) Stats Timestamp Shift 1.6M team-20210208-011001.bz2 57M user-20210208-011001 Mon Feb 08 06:04:40 ...

Hope this post helps visualize which WS/CS process their WUs, and which don't/didn't, and since when. It can be seen that two CS/WS are still backlogged, even after the latest "drop" 8 hours ago: 129.32.209.201 (vav18.fah.temple.edu | voelz) 155.247.166.219 (vav3.ocis.temple.edu | voelz) ...

17M points arrived. Currently running at 14MPPD 14/8~1.75M is current production ============================================ I guess the only way to effectively monitor this is to finish building my own client logger & catch discrepancies earlier. Critical test is to validate that WU count matc...

Bruce, Yes, they need to pick their battles, host resolution appears to be a good candidate for a patch. Creating 'A' records for critical servers & migrating code to name resolution would be a doable plan. Even 'foreign' servers can have managed 'A' records in the native domain (I just tested t...

It appears that the current Linux client 7.6.21, ignored the specified collection server & returned work to the errant 206.223.170.146.
The PRCG showed 'not found'.

Update:

Watched another WU with same results for: project:17431 run:0 clone:1731 gen:105

Hi Neil-B, Good to hear from you. It appears to be a hard-coded address issue, from the view of an engineer that was often forced to deal with the vagaries of IT organizations. I heard mention of server transitions. Perhaps "BIND" could be an appropriate pun to apply for symptoms like this...