Closed P5-133XL closed 10 years ago
I don't think that would really solve the issue. It would be better to just smooth out the estimation. I.e. don't let it change so quickly.
That was my purpose for masking the suggestion.
There are 60 seconds vs 10 tenths so there would be less change.
Perhaps rounding to the nearest 10 seconds is easier than smoothing. If the estimates change from 19 minutes 20 seconds to 19 minutes 30 seconds to 19 minutes 10 seconds any newbie can figure out that the units digit is always zero and changes of +-10 seconds will be less frequent, making them more readable.
10ths of a minute is fine with me, too, but perhaps more difficult for the newbie since it's a non-standard unit.
I think there's actually more to this than just smoothing or fewer calculations per interval. Currently the seconds seem to be random digits. and the minutes, sometimes alternate back and forth. If the calculations for ETA were just too fast/many then there would be a smooth progression of minutes and the seconds would just be fast but still be sequential and that is not what I'm seeing.
While the % completed bar graph seems totally smooth in its progression.
BTW, this same issue (incorrect ETA) happens when NaCl is trying to re-upload the WU when my internet connection goes down. The progress bar is smooth and constant but ETA is all over the place.
BTW, is anyone else bothered that the percentage bar keeps moving left with increase of progress instead of being centered?
I thought the sliding percentage was a feature. It is easier to read when not half blue and half white.
I would like to see the percentage number centered on the blue area of the bar, not sliding along on the right edge. That way, when the WU is finished, the number is truly centered.
I installed the client for the first time from the Chrome Store. The ETA estimation was absolutely wild before it downloaded the WU. Things calmed down after it had completed this step, but the ETA is still fluctuating quite a bit, with the range of about a minute. I would highly recommend some sort of moving average and to reduce the precision of the ETA to 30 seconds. Once the value gets less than 30, just say "less than 30 seconds" or similar.
Actually, you could just remove the seconds indication altogether until the ETA is under a minute.
I would rather never see seconds. Just "about a minute" and "a few seconds" when less than 10.
Installed Chrome 33.0.1750.117 cleared out the cache and other stuff (only kept cookies) and upon starting NaCl, it downloads client(? this is before the WU downloads) and I get an ETA that is impossible and could put off new donors:
Console messages (initial section only):
DEBUG: Config: user = PantherX main.js:73
DEBUG: Config: team = 69411 main.js:73
DEBUG: Config: passkey = **** main.js:73
DEBUG: Config: power = medium main.js:73
DEBUG: NaCl module loading main.js:73
DEBUG: Status: downloading: Downloading the Folding@home software in your Web browser. On your first visit this can take awhile. main.js:73
Invalid gadgets.rpc token. 32709660 vs 26545098 cb=gapi.loaded_0:104
Uncaught Error: mI0_1393226883412 cb=gapi.loaded_0:131 DEBUG: load progress: 0.0% (0 of 18000000 bytes) main.js:73 DEBUG: stats: {"team_rank":46,"earned":54213634,"url":"http://fah-web.stanford.edu/cgi-bin/main.py?qtype=userpage&username=PantherX","contributed":54213634,"team_url":"http://www.guru3d.com/index.php?page=folding","team_urllogo":"http://www.guru3d.com/folding/foldingathome.jpg","team_name":"guru3d","team_total":1510787167} main.js:73 DEBUG: load progress: 0.0% (0 of 18446744073709552000 bytes) main.js:73 DEBUG: load progress: 0.0% (112708 of 18446744073709552000 bytes) main.js:73 Invalid gadgets.rpc token. 649983679 vs 288187212 cb=gapi.loaded_0:104 Uncaught Error: m
oauth2relay644205221 cb=gapi.loaded_0:131
DEBUG: load progress: 0.0% (155157 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (201891 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (263586 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (310724 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (357752 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (406368 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (448434 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (499421 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (556590 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (620167 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (626918 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (705040 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (761565 of 18446744073709552000 bytes) main.js:73
DEBUG: load progress: 0.0% (788118 of 18446744073709552000 bytes) main.js:73
event.returnValue is deprecated. Please use the standard event.preventDefault() instead.
DEBUG: load progress: 0.0% (793375 of 18446744073709552000 bytes) main.js:73
First time it happened (something was being downloaded as I had network activity), I closed the browser after a minute or so thinking that it was some kind of glitch. Restarted and the same thing happened so I exited it again. Third time, I started and simply decided to wait until something "goes wrong". After few minutes, it finished downloading the WU and it was back to normal. I can reproduce it by using CCleaner to clear out Google Chromes; Internet Cache, Internet History, Download History, and Compact Database.
@jcoffland I would also strongly recommend updating the ETA estimation every second instead of the current very fast speed. This would really help in calming the estimation, but you'd still need an additional smoothing technique to cut the fluctuation. Updating once per second also reduce the flickering that happens when one highlights the ETA string.
@jcoffland, let's close this issue, I think it's been sufficiently addressed.
With the ETA, the seconds flash all over the place making them useless and I am not using a particularly high performance CPU. If you went to a decimal format for the minutes then there would be 1/6 of the change in the seconds (to the right of the decimal place) and therefore possibly more usable.
The alternative would be to just get rid of the seconds...