LAR_Systems

Yeah, I was away from home for a week so of course that's when a UPS died in my rack because hardware always knows when I'm gone.
 
Back up as of yesterday, almost all services restored.

Yeah, I was away from home for a week so of course that's when a UPS died in my rack because hardware always knows when I'm gone.
 
Back up as of yesterday, almost all services restored.

New version selector for the web client has been installed and a "stable?" RC for 8.3.5 is now posted for you and everyone else to break lol
 
You can give my first crack at 8.3.5 RC at the new version selection page https://webclient.lar.systems/
 
Cheers

Depends on what version of 8 you are running.
 
F@H 8.5 beta requires much re-programming on my part, so if you have upgraded to their latest, I'm not there yet.
 
Mine is only compatible with their original V8.1 beta.
 
I'm working on it though... trying to get something stable up asap.

Yeah, I was away from home for a week so of course that's when a UPS died in my rack because hardware always knows when I'm gone.
 
Back up as of yesterday, almost all services restored.

Depends on what version of 8 you are running.
 
F@H 8.5 beta requires much re-programming on my part, so if you have upgraded to their latest, I'm not there yet.
 
Mine is only compatible with their original V8.1 beta.
 
I'm working on it though... trying to get something stable up asap.

Note:  it's definitely technology. It's always technology.
 
Thanks for all the hard work you do and the PITA technology you have to deal with on a daily basis 🤣

Yeah, I was away from home for a week so of course that's when a UPS died in my rack because hardware always knows when I'm gone.
 
Back up as of yesterday, almost all services restored.

Yeah, I was away from home for a week so of course that's when a UPS died in my rack because hardware always knows when I'm gone.
 
Back up as of yesterday, almost all services restored.

Yeah, I was away from home for a week so of course that's when a UPS died in my rack because hardware always knows when I'm gone.
 
Back up as of yesterday, almost all services restored.

Yeah, I was away from home for a week so of course that's when a UPS died in my rack because hardware always knows when I'm gone.
 
Back up as of yesterday, almost all services restored.

Yeah, I was away from home for a week so of course that's when a UPS died in my rack because hardware always knows when I'm gone.
 
Back up as of yesterday, almost all services restored.

Yeah, I was away from home for a week so of course that's when a UPS died in my rack because hardware always knows when I'm gone.
 
Back up as of yesterday, almost all services restored.

Yeah, I was away from home for a week so of course that's when a UPS died in my rack because hardware always knows when I'm gone.
 
Back up as of yesterday, almost all services restored.

Yeah, I was away from home for a week so of course that's when a UPS died in my rack because hardware always knows when I'm gone.
 
Back up as of yesterday, almost all services restored.

In Version 7 the JSON with the CPU slot PPD does not identify it other than it's a CPU and number of threads.  The work work around was needing to use the plugin/browser extension framework to get the actual CPU name, make, min/max threads etc.

In Version 8 they handle this correctly where all hardware is identified over the socket connection of the remote machine by the folding client and passed in the early connection data.
 
In Version 7, the default web interface and it's underlying code / APIs appeared to be an after thought with the focus on the trey application which reports all the correct full remote information via the logs etc.

This is a known pain in my ass when one of two things happen with the Folding@Home V7 client.
 
2 things can cause this.
 
The first is unicorn work units, if you go to the bottom of the page you will see some work units / projects might report some massive anomaly of PPD for a project that drags the average up on a device well beyond how it would perform on the majority of projects.
 
The other is some people will port forward the web client to a remote machine so they can monitor that machine... but the V7 Client does not report back the real CPU running on the slot as part of the remote data, it ends up reflecting the local machine the client is viewed on CPUs.

So if you have someone with a Xeon / Epic nasty CPU server, but they view it on some old i3 POS laptop... the I3 might get recorded as having awesome stats... there is no way for me to tell that's happening automatically, all I can do is sweep moderate records that don't make sense from time to time.

The good news... the new V8 F@H Client Beta reports the real CPU on a local or remote machine removing the bulk of these issues... as I see I more users start using the V8 Beta Client for my system, I will remove CPU reporting completely from the V7 version to have better data overall.
 
Thank you for attending my Ted Talk.
 
Edit:  Investigated, this particular CPU seems to be someone remoting in to something bigger, I just searched by the irregularities and they are all grouped.  Thanks for the report.
 

It's a Monthly Active day count, and it's December, 1st 😉  The GUI is probably cached on the word November and will reset shortly based on your location / timezone.
 
Edit: Pushed so much new stuff this year, I will be bug squashing most of next year.

It's a Monthly Active day count, and it's December, 1st 😉  The GUI is probably cached on the word November and will reset shortly based on your location / timezone.
 
Edit: Pushed so much new stuff this year, I will be bug squashing most of next year.

In Version 7 the JSON with the CPU slot PPD does not identify it other than it's a CPU and number of threads.  The work work around was needing to use the plugin/browser extension framework to get the actual CPU name, make, min/max threads etc.

In Version 8 they handle this correctly where all hardware is identified over the socket connection of the remote machine by the folding client and passed in the early connection data.
 
In Version 7, the default web interface and it's underlying code / APIs appeared to be an after thought with the focus on the trey application which reports all the correct full remote information via the logs etc.

This is a known pain in my ass when one of two things happen with the Folding@Home V7 client.
 
2 things can cause this.
 
The first is unicorn work units, if you go to the bottom of the page you will see some work units / projects might report some massive anomaly of PPD for a project that drags the average up on a device well beyond how it would perform on the majority of projects.
 
The other is some people will port forward the web client to a remote machine so they can monitor that machine... but the V7 Client does not report back the real CPU running on the slot as part of the remote data, it ends up reflecting the local machine the client is viewed on CPUs.

So if you have someone with a Xeon / Epic nasty CPU server, but they view it on some old i3 POS laptop... the I3 might get recorded as having awesome stats... there is no way for me to tell that's happening automatically, all I can do is sweep moderate records that don't make sense from time to time.

The good news... the new V8 F@H Client Beta reports the real CPU on a local or remote machine removing the bulk of these issues... as I see I more users start using the V8 Beta Client for my system, I will remove CPU reporting completely from the V7 version to have better data overall.
 
Thank you for attending my Ted Talk.
 
Edit:  Investigated, this particular CPU seems to be someone remoting in to something bigger, I just searched by the irregularities and they are all grouped.  Thanks for the report.
 

It's a Monthly Active day count, and it's December, 1st 😉  The GUI is probably cached on the word November and will reset shortly based on your location / timezone.
 
Edit: Pushed so much new stuff this year, I will be bug squashing most of next year.

This is a known pain in my ass when one of two things happen with the Folding@Home V7 client.
 
2 things can cause this.
 
The first is unicorn work units, if you go to the bottom of the page you will see some work units / projects might report some massive anomaly of PPD for a project that drags the average up on a device well beyond how it would perform on the majority of projects.
 
The other is some people will port forward the web client to a remote machine so they can monitor that machine... but the V7 Client does not report back the real CPU running on the slot as part of the remote data, it ends up reflecting the local machine the client is viewed on CPUs.

So if you have someone with a Xeon / Epic nasty CPU server, but they view it on some old i3 POS laptop... the I3 might get recorded as having awesome stats... there is no way for me to tell that's happening automatically, all I can do is sweep moderate records that don't make sense from time to time.

The good news... the new V8 F@H Client Beta reports the real CPU on a local or remote machine removing the bulk of these issues... as I see I more users start using the V8 Beta Client for my system, I will remove CPU reporting completely from the V7 version to have better data overall.
 
Thank you for attending my Ted Talk.
 
Edit:  Investigated, this particular CPU seems to be someone remoting in to something bigger, I just searched by the irregularities and they are all grouped.  Thanks for the report.
 

This is a known pain in my ass when one of two things happen with the Folding@Home V7 client.
 
2 things can cause this.
 
The first is unicorn work units, if you go to the bottom of the page you will see some work units / projects might report some massive anomaly of PPD for a project that drags the average up on a device well beyond how it would perform on the majority of projects.
 
The other is some people will port forward the web client to a remote machine so they can monitor that machine... but the V7 Client does not report back the real CPU running on the slot as part of the remote data, it ends up reflecting the local machine the client is viewed on CPUs.

So if you have someone with a Xeon / Epic nasty CPU server, but they view it on some old i3 POS laptop... the I3 might get recorded as having awesome stats... there is no way for me to tell that's happening automatically, all I can do is sweep moderate records that don't make sense from time to time.

The good news... the new V8 F@H Client Beta reports the real CPU on a local or remote machine removing the bulk of these issues... as I see I more users start using the V8 Beta Client for my system, I will remove CPU reporting completely from the V7 version to have better data overall.
 
Thank you for attending my Ted Talk.
 
Edit:  Investigated, this particular CPU seems to be someone remoting in to something bigger, I just searched by the irregularities and they are all grouped.  Thanks for the report.
 

It's a Monthly Active day count, and it's December, 1st 😉  The GUI is probably cached on the word November and will reset shortly based on your location / timezone.
 
Edit: Pushed so much new stuff this year, I will be bug squashing most of next year.