• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

Hey Russ, or whoever makes the client disks for ta cube

cpars

Golden Member
:|There has been a few times I forgot to start the pproxy I have my clients pointed to,:| and last night the power blinked a few times and caused machines to reboot.:| dnet was in startup but not pproxy so during the night the clients updated without my pproxy so I have no credit for them.:| Where the hell did they go!!!!!!!!!!!!:|

this has happened a few times now probably lost 2000-3000 blocks wtf :|:|:|:|:|

And yes before anyone tells me to, Im gonna up the buffers so they dont auto update :|
 
cpars,

Your blocks probably went to Dnet if Russ hasn't disabled the auto fallback feature... it doesn't sound like he has tho' since your clients flushed and if they have the fallback disabled they simply won't flush.

With love and respect your fellow TA member

Two-Face
My stats:
RC5
OGR-25
Seti
Gamma Flux
 
CPARS,
Hopefully you have logging turned on. If you do, open the log file using notepad, and go to the bottom and look through to see if it's flushed/fetched. it will tell you what proxy was used.

Usually, if a client cannot get to a proxy, it will either get stuck trying to connect, or most of the time it will keep cracking and try to connect, and the cracked blocks will be in it's buff-out file until it can connect again.

This is what the client log file would look like:

[Feb 13 14:08:46 UTC] 0 RC5 packets (0 work units) remain in buff-in.rc5
[Feb 13 14:08:46 UTC] 1 RC5 packet (30 work units) is in buff-out.rc5
[Feb 13 14:08:47 UTC] The perproxy says: "Personal Proxy!"
[Feb 13 14:08:47 UTC] Retrieved 1 RC5 packet (30 work units) from server
[Feb 13 14:08:47 UTC] Sent 1 RC5 packet (30 work units) to server
[Feb 13 15:12:57 UTC] Completed RC5 packet 0D91B48B:80000000 (30*2^28 keys)
0.01:04:10.66 - [2,091,345.24 keys/sec]
[Feb 13 15:12:57 UTC] Loaded RC5 30*2^28 packet 0D91B4AF:00000000
[Feb 13 15:12:57 UTC] Summary: 18 RC5 packets (540*2^28 keys)
0.18:19:50.76 - [2.08 Mkeys/s]

The only thing I can think of that would lose blocks would be if you were running Klinux, storing blocks in memory, it couldn't flush, and you took a power hit. Then you would lose blocks that had been cracked. 🙁
 
cpars,

The disks fall back to the dnet keyservers if they don't find the keyserver listed in the ini.

Russ, NCNE
 
well i guess TA got them anyway, but sure didn't help my stats🙁

I have added pproxy to startup and changed ini to fetch-workunit-threshold=5000 that should fix my woes. Sh!t happens I guess.

:Q
[Feb 13 19:20:33 UTC] Summary: 206 RC5 packets (391*2^28 keys)
0.05:50:34.74 - [4.98 Mkeys/s]
[Feb 13 19:20:33 UTC] 266 RC5 packets (4464 work units) remain in
buff-in.rc5
[Feb 13 19:20:33 UTC] Projected ideal time to completion: 2.17:43:12.00
[Feb 13 19:20:33 UTC] 235 RC5 packets (475 work units) are in buff-out.rc5
:Q
 
Back
Top