Wow. The newest firmware from KnC (0.97) makes their miners work FLAWLESSLY with p2pool! The difference is staggering. Before p2pool was literally unusable with my Saturn - but now I am getting close to max hashrate  |
|
|
|
Maybe you mean you saw a power supply spin it's OWN fan and shut down? That would be different, and certainly possible - but that is not the scenario the poster described.
Not to belabor the issue but that is the scenario described. Nope, read again: Hey,
Thanks for the tip.
Repeat of the same.
On just the PS with the mb cable jumped - I get 1-4 revs of the PS fan, then nothing. It's like something clicks off in the PS as soon as it ramps up.
On the PS with one board attached - I get 1-4 revs of the PS fan, the board fan, and the two case fans, then nothing. Same kind of behaviour, almost like something clicks inside the PS as soon as it begins to ramp up.
Repeat for all boards.
|
|
|
|
my vote is that the paper clip's in the wrong spot. Wrong cable maybe? How about a pic?
He said the fans spin up, then go back off. If the paper clip was in the wrong place, the fans would not spin at all, as the power supply would be off. I've seen power supplies that behave exactly as he describes when powered up while attached to nothing. The fans on the miner require power to spin. If the power supply is off, i.e., the paper clip is in the wrong place, those fans have no power available to spin them. Maybe you mean you saw a power supply spin it's OWN fan and shut down? That would be different, and certainly possible - but that is not the scenario the poster described. He would get that if the PS protection kicks in ^ shuts the PS down. The fan would spin up & stop. Waiting a few mins will kick the protection out again. Yep - but it would certainly mean he did not have the paperclip in the wrong place. |
|
|
|
my vote is that the paper clip's in the wrong spot. Wrong cable maybe? How about a pic?
He said the fans spin up, then go back off. If the paper clip was in the wrong place, the fans would not spin at all, as the power supply would be off. I've seen power supplies that behave exactly as he describes when powered up while attached to nothing. The fans on the miner require power to spin. If the power supply is off, i.e., the paper clip is in the wrong place, those fans have no power available to spin them. Maybe you mean you saw a power supply spin it's OWN fan and shut down? That would be different, and certainly possible - but that is not the scenario the poster described. |
|
|
|
my vote is that the paper clip's in the wrong spot. Wrong cable maybe? How about a pic?
He said the fans spin up, then go back off. If the paper clip was in the wrong place, the fans would not spin at all, as the power supply would be off. |
|
|
|
BTW - with .97 P2Pool works like a charm.
That is great to hear!  |
|
|
|
Hey, I have more hashing power on the table now (about 65GH/s total) my difficulty keeps jumping around now from 16 to 32 at one point it was 4 for a long time but my hash rate is fairly consistent. Is this expected and if not let me know what your thoughts are.
Yeah, mine jumps around a lot too. Maybe there should be a little more hysteresis added to the formula for switching difficulties? I asked awhile back how the pool determines a miners difficulty, below is wizkid057's response. I just didn't expect it to jump around so much. Now that I know it's not just me I'm sure it's expected.
The pool targets 32 shares per minute. So, sticking with that...
(hashrate_in_hashes_per_second/4294967296)*60 = difficulty_1_shares_per_minute
Difficulty 2 would be triggered at 64 shares/min, Diff 4 @ 128, Diff 8 @ 256, etc.
So for you,
(10,000,000,000/4294967296)*60 = ~140 difficulty 1 shares/min
Then divide by 32 to get difficulty ~4.36 for 32 shares/min. Round down to the nearest power of two >= 1, and you get difficulty 4.
Yeah, I expected a calculation like that. Since the hashrate seen by the pool varies, though, you can find yourself straddling a 'border', so to speak, so you keep switching back and forth between two difficulties. For example, if you are hashing pretty close to exactly 512 shares per minute, you will probably find yourself switching between diff 16 and diff 8 if your shares-per-minute varies from say 495 to 530 spm. This could be changed such that you need to get to 512 spm to get diff 16, but after that you won't switch back to diff 8 unless you go below some threshold, say 480 spm. That way you don't oscillate back and forth. This is done in lots of devices you are familiar with, like thermostats, for example. If your furnace was set to keep the temperature at exactly 70 degrees, it would just turn on and off constantly when the temperature gets to 70 degrees. Hysteresis prevents this. |
|
|
|
Hey, I have more hashing power on the table now (about 65GH/s total) my difficulty keeps jumping around now from 16 to 32 at one point it was 4 for a long time but my hash rate is fairly consistent. Is this expected and if not let me know what your thoughts are.
Yeah, mine jumps around a lot too. Maybe there should be a little more hysteresis added to the formula for switching difficulties? |
|
|
|
recommended. not required.
Your miners were working very well before yet you still decided to tinker with it anyway by updating the firmware.
The main rule of thumb when updating any drivers/firmware for anything is that things can break or go wrong.
This. If ain't broken... I certainly understand taking a conservative approach, especially when money is involved - but in this case, it is literally a less-than-30-second job to revert to your old firmware if you don't like the new stuff, so why not just try it? So far, it looks to me like the flushwork improvement in 0.97 is worth the effort. |
|
|
|
The old cgminer (or is it some other task running in background?) is disabling (and enabling) cores with too many HW errors.
This can be visualized using that BertMod utility.
bfgmiger is now doing this task by its own. You can see the number of active cores (2*4*48=384 for a Saturn) in the status
line. It looks like you can manually "enable" disabled cores. Will they also be enabled over time automatically again?
Is it possible that the BertMod statistics don't match the status of bfgminer? BFGMiner only scans the core state at startup, and doesn't yet support enabling or disabling them, either manually or automatically. Is it possibly to permanently "break/destroy" a core that drops many HW errors and that is not disabled? I don't think the miner has anything to do with enabling/disabling cores... I'm pretty sure that is done by the program called 'asic_test' that is run at startup, and saves its output in /config/asic_test. I could be wrong. For a lot of good under-the-hood info, check out this thread: https://bitcointalk.org/index.php?topic=313978.0 |
|
|
|
|
Would it make sense to create a simpler, less featureful stats page, that could be used as a backup when the main stats page is not working? I love all the real time graphs and such, but when it's not working, it would be nice to still be able to see basic info about my balance, average hash rate, payout queue, and maybe blocks found.
|
|
|
|
"Difficulty has nothing to do with WU."
Sure it does. The miner has to work harder to do the calcs and is therefore less efficient.
How do you explain that WU has an inverse relationship for me then? WU always starts
greater than 4K and drops to as low as 3.6K
WU is just a ratio of accepted shares to rejected shares. It depends only on your hash rate and (effectively) how many difficulty 1 shares you submit that get accepted. Difficulty is not part of the calculation, and doesn't affect any of the factors that are. Are you saying that your WU changes when difficulty changes? It sounds like you are saying that your WU varies over time even with no difficulty change, so I don't understand where you are deriving the relationship to difficulty. Diff only changes once ever 2016 blocks. The difficulty from this pic:(ALWAYS starts low and rises constantly with time. WU starts high, and lowers over time)  That number is just the number of shares you have had accepted at the current difficulty, not the actual mining difficulty itself. |
|
|
|
"Difficulty has nothing to do with WU."
Sure it does. The miner has to work harder to do the calcs and is therefore less efficient.
How do you explain that WU has an inverse relationship for me then? WU always starts
greater than 4K and drops to as low as 3.6K
WU is just a ratio of accepted shares to rejected shares. It depends only on your hash rate and (effectively) how many difficulty 1 shares you submit that get accepted. Difficulty is not part of the calculation, and doesn't affect any of the factors that are. Are you saying that your WU changes when difficulty changes? It sounds like you are saying that your WU varies over time even with no difficulty change, so I don't understand where you are deriving the relationship to difficulty. Diff only changes once ever 2016 blocks. |
|
|
|
Interesting... applied 9.6.1 and it still shows 9.6 and initially everything was worse than 9.6 So I applied enablecores again and too early to say for sure, but looking very good. I've also noticed an interesting phenomena of "bad boots". Sometimes after a restart things are not up to par, but if you keep trying you will hit a "golden boot" that works much better. I recommend for people having trouble to try this! Never seen this much speed before, but too early to say how it will stabilize: https://dl.dropboxusercontent.com/u/40920348/KNC961EC.jpgyour WU is very good. I've 7475 for my jup. Right now, but what happens is that the difficulty keeps going up to over 4 mill and the WU drops to 3700ish. We will see what happens. Going to let it ride without screwing around with it any further for awhile. lol Difficulty has nothing to do with WU. |
|
|
|
and here I thought I was getting paid per share...
Since a share = 2^32 hashes, the two are interchangeable. SharePerUnitTime = HashesPerUnitTime/2^32, thus SharePerUnitTime*2^32 = HashesPerUnitTime a.k.a Hashrate if UnitTime= 1s (as seen by the pool via valid submitted shares) I know you were joking but some people don't seem to grok this so figured I'd spell it out for those folks who might be trying to figure this out for the first time. I don't think this is strictly true. If I recall correctly, a share of difficulty 1 is defined as a share with 32 leading zeros - which should, on average, require 2^32 hashes to generate, but will, in reality, vary from share to share. on an individual share, yes you are correct..but over time it converges to 2^32 thus that's what all of the various software stats use for the conversion when they determine how much to pay for a share. Instead, the "fast" or "lucky" share is represented as if your hashrate momentarily spiked so that the math of a share = 2^32 hashes is preserved on the back end. So think of it as your "effective hashrate" which is seen by the pool that goes into those calculations. Yeah, I understood your point - I just felt challenged to try to match your pedanticism.  |
|
|
|
and here I thought I was getting paid per share...
Since a share = 2^32 hashes, the two are interchangeable. SharePerUnitTime = HashesPerUnitTime/2^32, thus SharePerUnitTime*2^32 = HashesPerUnitTime a.k.a Hashrate if UnitTime= 1s (as seen by the pool via valid submitted shares) I know you were joking but some people don't seem to grok this so figured I'd spell it out for those folks who might be trying to figure this out for the first time. I don't think this is strictly true. If I recall correctly, a share of difficulty 1 is defined as a share with 32 leading zeros - which should, on average, require 2^32 hashes to generate, but will, in reality, vary from share to share. |
|
|
|
seems like shares are still being accepted though. I assume that the shares are still being counted and payouts are happening as normal?
Or should I switch to another pool until the DDOS stops?
The pool is mining just fine. Just got another block, actually. |
|
|
|
eligius under DDOS
I can't seem to pull up the website with stats but my miner shows it's getting shares accepted. New to Eligius, assuming this is par for the course? same here! If the pools were all ddos'd before a difficulty change, could that mess with the adjustment and keep it lower than it should? I don't think so. The diff change is calculated based on how fast the last 2016 blocks were generated, right? So unless you DDOS them for the whole 2016 block run, it won't make much difference. |
|
|
|
Anyone else seeing this kind of reoccurring drop in hashing, I suspect it's got something to do with cgminer restarts or the like? I have other miners running so the graph doesn't hit zero but the new KNC miner does completely go offline for long enough that the graph picks it up....  I see that kind of thing on Eligius when someone is trying to DDOS the pool. It's been happening off and on quite a bit lately. |
|
|
|
Nice. Guess I need to go read up on this cgi you speak of... I'll speed you up, but I am more of a hack than a polished programmer so rather just give tips to what I did the fields that are already constantly being updated and outputted for use are: STATUS=S,When=1382207241,Code=11,Msg=Summary,Description=cgminer 3.4.0|SUMMARY, Elapsed=310,MHS av=450396.80,Found Blocks=0,Getworks=17,Accepted=102,Rejected=2, Hardware Errors=7707,Utility=19.77,Discarded=26,Stale=0,Get Failures=0,Local Work=45860, Remote Failures=0,Network Blocks=3,Total MH=139401753.5263,Work Utility=6997.99, Difficulty Accepted=26112.00000000,Difficulty Rejected=512.00000000,Difficulty Stale=0.00000000, Best Share=468225,Device Hardware%=17.5935,Device Rejected%=1.4183,Pool Rejected%=1.9231,Pool Stale%=0.0000| You can use any of these but will have to change two files: /www/tmpl/mining_stat.html_tmpl that one will do the formatting and I make a new one and call it mining_stat.html_tmpl2 the one that does the real work is /www/pages/cgi-bin/fetch_mining_stat.cgi when you look inside these two files you will see how to add more fields and just stick with it's naming conventions to pass the values since I changed the name of the other file, make sure to point to the new named one in this file like: s!#%#ASIC_STATUS#%#!'"$asic_status"'!g' < /www/tmpl/mining_stat.html_tmpl2 so when you are all set with files in the two directories, you just do a simple cp fetch_mining_stat.cgi.[newversion] fetch_mining_stat.cgi then it doesn't disrupt anything since now it just goes to the other formatting file smoothly Thanks! |
|
|
|
|
Show Posts
