I have a small modification to show the HW% on the Cgminer Status page: ssh into your unit with ssh -l root <ip address>cd to the directory /usr/lib/lua/luci/controllervi cgminer.luaScroll down to the following lines: for line in summary do local elapsed, mhsav, foundblocks, getworks, accepted, rejected, hw, utility, discarded, stale, getfailures, localwork, remotefailures, networkblocks, totalmh, wu, diffaccep if elapsed then local mhw = string.format("%d(%1.2f%%)",hw,(100*hw/(diffaccepted+diffrejected+hw))); local str local days Add the local mhw = line Scroll down to the lines: ['accepted'] = accepted, ['rejected'] = rejected, ['hw'] = hw, ['utility'] = utility, ['discarded'] = discarded, Change the = hw that you see into = mhwSave the new file and cd to /tmpremove the luci caches: rm -rf luci-indexcache luci-modulecachereload the Cgminer Status page in your browser and admire your HW%  Note1: This mod might go away after a reboot Note2: The calculation of HW is not 100% correct since I can't use Diff1shares but have to use DiffA + DiffR but it's close enough! Update: rejected% instructions below in message #4 @CKolivas: Can you add this mod to your next release when you're back from a well deserved vacation ? |
|
|
|
so, after the first test run with this options I saw in the morning that avalon does not provide shares
cgminer restarted every few minutes, but always 0.00 MHs
only a hard reset does help
anyone have had this before?
TIA
Remove all the --avalon options, set a Chip Frequency(for example 282) and try again. I also have a silver Avalon that doesn't like the new --avalon options. No idea why, I don't have much time to investigate so I have it hashing at 282Mhz. Have you flashed the TP-LINK to the lastest ckvolias firmware? Yes, it's running 20130703. |
|
|
|
As it is a modular design, if I remove one or several hashing boards, can the miner still work properly?
Yes, as long as you start with the highest number board and go down by 1. So if you have boards 1 to 12 occupied and want to remove 4, you must remove 12, 11, 10 and 9. |
|
|
|
I don't want to sound mean but ...
Writing this just gave me an idea.
No worries, I have a thick skin and I am glad I could be of indirect help  Works for me too, explain to someone how good I solved something and then realize ... |
|
|
|
current bitfury group buy: 400gh / 119shares * 0.95(fee) = 3.19 ghash/sec per btc current knc group buy: 400gh / 30shares / 2.6btc * 0.98(fee) = 5 ghash/sec per btc bitfury price: 119 shares * 1 btc/share = 119 btc * 87 usd/btc = 10,353 usd  (should the price per share be changed) knc price: 30 shares * 2.6btc = 78 btc * 87 = 6786 usd --> nice clearly knc have the advantage. hope knc will really deliver. The us$ price is exactly my issue too. That's why I suggested to refund the unused BTC after a purchase. |
|
|
|
so, after the first test run with this options I saw in the morning that avalon does not provide shares
cgminer restarted every few minutes, but always 0.00 MHs
only a hard reset does help
anyone have had this before?
TIA
Remove all the --avalon options, set a Chip Frequency(for example 282) and try again. I also have a silver Avalon that doesn't like the new --avalon options. No idea why, I don't have much time to investigate so I have it hashing at 282Mhz. |
|
|
|
|
May I suggest to buy a machine when you've collected 119 BTC, and return the unused BTC to the participants of that machine right after buying to prevent issues.
Are you going to participate yourself in the GB ?
|
|
|
|
|
There is something odd with the Bitburner boards. The 10 chip board is relatively more expensive than the 20 chip board, but still has a higher profit % ?!
|
|
|
|
Once it gets triggered it doesn't let go until it has all 4 bytes. I hope today goes better, as the crunch is really on now, and believe me I feel the pressure to get everything finalized enough to make final boards.
Sorry if I am going on about this. May I suggest: Create a tiny interrupt handling routine that gets and stores one byte in a buffer and increment the store memory pointer and returns from the interrupt again. Mean and lean! something like: constant int dataBufferLength=32;
byte interruptDataBuffer[dataBufferLength];
byte* interruptDataBufferAddress=&interruptDataBuffer;
byte* lastReadBufferAddress=&interruptDataBuffer;
handleInterrupt:
reg a = getDataByteFromInterrupt();
get ix from interruptDataBufferAddress;
store a at ix;
increment ix;
if (ix == &interruptDataBuffer+dataBufferLength) ix=interruptDataBufferAddress;
store ix at interruptDataBufferAddress;
returnFromInterrupt;
And in your main program you can then compare lastReadBufferAddress with interruptDataBufferAddress to see if byte(s) have been received. I know I am simplifying things, but interrupt handlers should be as short as possible. I also have a question: It is possible, although unlikely, that more than one chip has a result at the same time. Do you know from which chip the data is coming ? If so, this should be taken into account in the above pseudo code. If not, could it be the reason for your data issue? Good luck solving the issue at hand! |
|
|
|
|
The correct formula to calculate HW% is: 100 * HW / (diff1shares + HW)
You are probably looking at the number of shares, and not the number of diff1shares!
|
|
|
|
Does anyone have any tips for getting the side panel back on? I just spent like an hour trying to get all the screws to line up, stay in place, and tighten up. I still have 3 that screwed in all sideways and I can't get to straighten out.
I had the panel off because the top fan was making a racket. I put in a cable tie to hold back all the cables away of the fan. There was also an extra nut bouncing around in the case (must have been dropped in during assembly). Everything's working great now but man those screws are a royal pain.
Cut little pieces of foam and put it under all nuts before putting on the lid. Remove them when you're done.  |
|
|
|
... If any of the chips find a good result, then it pulls the report line down, and hands the good result to the Spartan chip. All the other chips then "lose" and their work basically discarded.
Am I reading this correctly that you are waiting for one valid result and then discard all other future potential valid results for that unit of work ?! You do know that there can be more than one valid result for a given unit of work ? Have a look here: https://bitcointalk.org/index.php?topic=190731.msg2680342#msg2680342 |
|
|
|
Carry a pad and pencil around. What are those ? Oh, you mean a smartphone! |
|
|
|
These are horrible numbers you are currently generating 48% hardware errors. What made you think 390mhz was stable on your current design? HW% = 100 * HW / (diff1shares + HW) 100 * 294 / (922 + 294) -> 24% Still not good tho, should be less than 2%. Must be because of high freq of 390! What HW% do you get at 300Mhz ? |
|
|
|
Out of curiosity, why is cgminer reporting MinerCount 24, while you seem to only have two boards connected ? MinerCount should be 2 ?! |
|
|
|
The method I was going to use was to give the current month and about 6 months out, giving the data on each month for each unit. That would allow people to see if they got a unit now second hand what it would be worth, or if they had something coming a month from now. Then it wouldn't matter what batch, just the hashing power vs lead time.
I suggest to make a distinction between the silver Avalons of B1 and black Avalons of B2. The black ones are newer and are capable of running faster (around max. 300Mhz versus 350 Mhz). |
|
|
|
|
Have a look at the Cgminer API Log, and check the match_work_countNN for the 24/32 chips. You'll probably see some out of ordinary values there. Have a look at mine:
[match_work_count1] => 8721
[match_work_count2] => 8502
[match_work_count3] => 937
[match_work_count4] => 0
[match_work_count5] => 8377
[match_work_count6] => 8735
Clearly 3 and 4 are not happy.
|
|
|
|
|
The problem has been acknowledged and is being worked on. I am locking this thread.
|
|
|
|
|
Show Posts
