• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

8101 TPF Increasing....

4

402blownstroker

[H]ard|DCer of the Month - Nov. 2012
Joined
Jan 5, 2006
Messages
3,257
Is it just me or are the TPF been increasing on the 8101 WUs. About a week ago, the 6166HE rig was getting around 14m20s TPFs and over the last 7 WUs has increased to 15m45s TPFs. Points have drop proportionately :( Same setup, no changes, no reboots or interruptions......
 
When they first came out I noticed a wide variation in TPF on the 8101's I have also noticed in the last couple of days that 1 of my rigs has been running some that are taking about 1 min 10 sec TPF longer avg than most of the ones I am used to running.
 
8101 TPFs are varying occasionally from what I'm seeing. After recently building my 4P (6180), for the first few days, TPFs for 8101s were ~12:40 (give or take a couple secs either way). Then, an 8101 came along (with no rebooting and dedicated Folding) that ran 14:13. That was followed by another 8101 that went back to 12:34. All I can figure is that there must be some variation in the 8101s. Still haven't seen one of the 8102s after completing (9) 8101s in a row now. It will be my luck that I'll get the first 8102 the moment after PG adjusts the points downward.:rolleyes:
 
So is it official yet? That the 8101 is worse than the 2684? The worst bigadv to ever be conceived, and possibly the worst unit ever that are being forced down our throat.
 
Untitledone said:
So is it official yet? That the 8101 is worse than the 2684? The worst bigadv to ever be conceived, and possibly the worst unit ever that are being forced down our throat.
Click to expand...

It isn't offical but its widely known that tpf sux, isn't constant, fluctuates all over the place, causes your system to run hotter than with previous BA units, has such a short deadline that most current generation dual hex core machiners can't run it and is the only BA available in quantity.

I think that covers it

Basically, its shite. 764x is not much better for SMP - thats lokking like the new 6701:eek:
 
Untitledone said:
That the 8101 is worse than the 2684? The worst bigadv to ever be conceived, and possibly the worst unit ever that are being forced down our throat.
Click to expand...

I can think of no other way to say or spell 'Yes'.

I just hope the 8101 WUs do not have the same life span as the 690x WUs. I could tollerate a couple months of them, but certainly not a couple of years :(
 
My 2P E5-2630 box is crunching through a terrible 8101 right now. Down to about 115K ppd :(
 
I have found several times now that when I see what looks like a "slow" 8101, if I reboot, the time per frame drops 1-2 minutes. Restarting without a reboot did not help. This is on a dual E5 box running Ubuntu 12.04 LTS with thekraken. I have not seen the same type of behavior on any of the other bigadv projects.
I haven't been able to track down any issues with rogue processes or memory leaks. It would be interesting to see if anyone else can reproduce this.
 
Range I see over the last few WU's is about ~9:50 - ~10:50

Am rebooting this system for giggles and seeing if what Punchy says holds true. Will report back later.
 
My 8101 TPF have stayed pretty consistent from 11:30 to 11:45 since moving over to the TYAN board back in early July.
 
I call it "TPF Creep". The phenomenon with growing TPFs over time until a hard reboot was a regular event on my 980X when we could do the 6904s. It would take about 4 of them back-to-back and then you could start seeing the TPF gradually increase with each WU. My rule of thumb was to do a reboot after every 4th 6904 and I stopped having the problem. Maybe it is a similar thing with 8101s...
 
Before rebooting
Code: 
[19:01:37] Completed 32500 out of 250000 steps  (13%)
[19:11:45] Completed 35000 out of 250000 steps  (14%)
[19:21:52] Completed 37500 out of 250000 steps  (15%)
[19:31:58] Completed 40000 out of 250000 steps  (16%)
[19:42:06] Completed 42500 out of 250000 steps  (17%)
[19:52:13] Completed 45000 out of 250000 steps  (18%)
[20:02:18] Completed 47500 out of 250000 steps  (19%)
[20:12:25] Completed 50000 out of 250000 steps  (20%)
[20:22:34] Completed 52500 out of 250000 steps  (21%)
[20:32:40] Completed 55000 out of 250000 steps  (22%)
[20:42:50] Completed 57500 out of 250000 steps  (23%)
[20:52:59] Completed 60000 out of 250000 steps  (24%)

Folding@Home Client Shutdown.

After rebooting
Code: 
[21:09:24] Project: 8101 (Run 26, Clone 3, Gen 26)
[21:09:24] 
[21:09:24] Assembly optimizations on if available.
[21:09:24] Entering M.D.
[21:09:30] Using Gromacs checkpoints
[21:09:32] Mapping NT from 64 to 64 
[21:10:22] Resuming from checkpoint
[21:10:23] Verified work/wudata_00.log
[21:10:24] Verified work/wudata_00.trr
[21:10:24] Verified work/wudata_00.xtc
[21:10:24] Verified work/wudata_00.edr
[21:10:24] Completed 59295 out of 250000 steps  (23%)
[21:13:21] Completed 60000 out of 250000 steps  (24%)
[21:22:53] Completed 62500 out of 250000 steps  (25%)
[21:32:26] Completed 65000 out of 250000 steps  (26%)
[21:42:00] Completed 67500 out of 250000 steps  (27%)
[21:51:31] Completed 70000 out of 250000 steps  (28%)
[22:01:04] Completed 72500 out of 250000 steps  (29%)
[22:10:36] Completed 75000 out of 250000 steps  (30%)
[22:20:07] Completed 77500 out of 250000 steps  (31%)
[22:29:40] Completed 80000 out of 250000 steps  (32%)
[22:39:11] Completed 82500 out of 250000 steps  (33%)
[22:48:43] Completed 85000 out of 250000 steps  (34%)
[22:58:16] Completed 87500 out of 250000 steps  (35%)
[23:07:45] Completed 90000 out of 250000 steps  (36%)
[23:17:17] Completed 92500 out of 250000 steps  (37%)
[23:26:48] Completed 95000 out of 250000 steps  (38%)
[23:36:29] Completed 97500 out of 250000 steps  (39%)
 
Me no likey!!!!!!!!

I rebooted the box and the TPF fell right back to 14m20s from 16m10s. One more reason these WUs suck sweaty monkey balls. Now the machines need more maintenance with more frequent reboots. I would love to know what causes this to happen. I can not think of a single reason off hand why the reboot would increase/reset the performance :confused:
 
thinklet said:
Maybe a -oneunit xx with a switch would make it easier. Best regards, Charlie
Click to expand...

How about retiring the buggy pile of crap 8101 WUs? I am getting more and more tempted just to switch over to smp WUs until these 810x POS WUs are gone.
 
A strange thing for sure. I saw TPF Creep many times on my 980X with Bigadvs (running Ubuntu 11.04) and a reboot fixed it every time the TPFs crept up into a noticeably slow time-frame. Even though I was running Ubuntu, I'd guessed that it had something to do with memory leaks like we saw with Windows for years, but never knew for sure.

With the 4P, my experience has been that the 8101 WU itself has fluctuation. I've had ~ a couple minutes poorer TPF performance on a given WU, only to be followed by normal TPF performance on the next 8101 WU. That would seem (to me) to be tied to a specific 8101. The next time I get one that increases TPF well over norm, I'll try the reboot to see if it has any effect.
 
Could it be a memory leak that can only be cleared by reboot?
 
It's really interesting. One of my friend's dual E5-2690 is encountering just the same issue as yours. His avg TPF (of p8101) before rebooting was 15m32s, while after rebooting the TPF turned to 17m35s, and this TPF change could be reproduced well with high precision.
Should be noted that E5-2690's stock and all-core-TB frequncies are 2.9 and 3.3GHz, respectively, and we can see that 2.9GHz/3.3GHz=0.879 is quite close to the value of (15m32s)/(17m35s)=0.883.
I believe there must be some intrinsic relations between them.

Punchy said:
I have found several times now that when I see what looks like a "slow" 8101, if I reboot, the time per frame drops 1-2 minutes. Restarting without a reboot did not help. This is on a dual E5 box running Ubuntu 12.04 LTS with thekraken. I have not seen the same type of behavior on any of the other bigadv projects.
I haven't been able to track down any issues with rogue processes or memory leaks. It would be interesting to see if anyone else can reproduce this.
Click to expand...
 
Last edited:
I use FCI as well as HFM to track my stuff and looking at the last ten WU, all 8101s, there isn't much variation. You can see the TFP graph for the current WU and see the variation through the WU. This is a dedicated 4P 6176SE OC to 230 running U10.10 and the Kraken. Server5
 
rhavern said:
I use FCI as well as HFM to track my stuff and looking at the last ten WU, all 8101s, there isn't much variation. You can see the TFP graph for the current WU and see the variation through the WU. This is a dedicated 4P 6176SE OC to 230 running U10.10 and the Kraken. Server5
Click to expand...

Hi, Noob question: Can you provide a link to the information that comes from FCI, I did not even know this existed. Best regards, Charlie
 
You must log in or register to reply here.
Back
Top