 Show Posts
|
|
Pages: « 1 2 3 [4] 5 »
|
I am getting allot of KLNX:X went idle before work was sent messages, why does this happen and how can it be avoided?
Ditto. Also, seems to force an overheat sitatuion @ ~ 54C and ignores whatever I've set in --klondike-options clock:temp Running with "--klondike-options 325:65" Should I just ensure that these guys are in an environment that runs near 50C ? Temp in klondike-options is target temperature which firmware tries to hold by adjusting fan speed. It has nothing to do with overheat - this is a value in CGM driver. When that temperature is reached, CGM disables the board untill temperature falls to around 45°C. You can edit it in CGM driver-klondike.c at line 63 #define KLN_KILLWORK_TEMP 53.5 Try to set it for example to 63.5 and recompile cgm. |
|
|
|
I am getting allot of KLNX:X went idle before work was sent messages, why does this happen and how can it be avoided?
There is a work buffer in firmware, and when CGM is sending new work data to the board and that buffer is empty, this message is shown. It basically means nothing else than the board is idle when new work is pushed to it. It can be probably avoided by increasing work buffer in firmware and CGM driver. |
|
|
|
They're not, Avalon released datasheet for them a while ago. And they are using different clock frequency and different voltages.
There's still a lot of components to rescue though perhaps? New PCB, a few resistors to set the voltage and a different oscillator? From glancing at it, it looked like the comms protocol was similar but I might be wrong. The real problem is that the rapid growth in the network makes anything like this too risky. It will be interesting to see what happens to this auction. Yes it seems to be identical (at least timing is and anything else can be changed in firmware). So basically only Avalon footprint (pinout) has to be changed (so small modifications to the board around ASICs), then you will have to replace the oscillator for 25MHz one and power regs for PLL (because 55nm Avalon now uses 1.0 instead of 1.2V). Core voltage is now 0.9V, but since IR3895 can go as low as 0.5V output, no problem with that (you will only change one/two resistors as you're saying). I'm planning to modify the project, but I'm probably not going to build one (maybe just one board if I'll be able to get a few chips from somewhere - and it wont be an auction). |
|
|
|
55 nm is starting auction tomorrow. I wonder if they're pin compatible and if anyone will trust Avalon again or if we'll just let greed take over.
They're not, Avalon released datasheet for them a while ago. And they are using different clock frequency and different voltages. |
|
|
|
Steamboat already pasted Klondike project URL to LSD thread, but in case someone missed it, you can check it out at http://projectklondike.org. And anyone running Klondikes, you can drop pictures of your miners to drop@projectklondike.org. They will be added to the gallery. Thanks for putting that info up  I'll post my pics of my Klondikes after I clean up my setup  Great, looking forward to it  . |
|
|
|
Well, that kinda worked. I successfully programmed my 6 K16s using the PICkit 3.
The 3 that I'd gotten halfway working before now appear to be fully working, though I now need to address cooling. I keep getting "critical overheat" messages.
The 3 that weren't working are still not working. One gets 100% hw errors, one has a zero hashrate, and the third isn't even detected (I get "usb 1-4.1.4.4.4: device not accepting address 91, error -32" in dmesg, and the USB hub light turns off.)
I used 100% linux to program them BTW, no Windows, and it worked just fine.
Bogart, there is a failsafe in CGminer itself. Currently it is set to 53.5 deg C. You can change it to higher value in driver-klondike.c at line 63: #define KLN_KILLWORK_TEMP 53.5 to for example 63.5 is what I'm using: #define KLN_KILLWORK_TEMP 63.5 Then recompile. Anyways, Kano is going to change that soon I think. We discussed it, but we didn't achieved consensus yet on which temperature would be the best there. I just pushed up updated firmware with 333MHz default clock. It should be more stable at the start, so try that. Then you can use cgm config to clock it higher. |
|
|
|
Yes it's the latest working for now. |
|
|
|
It cost me 450€ to make 10 PCBs here (it's 4 layer btw with 0.5mm pitch components), so one board in this quantity is around 60USD locally. Doing for example one or two PCBs would be even more expensive, so that's the figure I based that on. And doing more than a few by hand is really not a good idea, as you can read in How to build. But I can ofc change that, just tell me what figure would be adequate. |
|
|
|
Guys, any of you running Klondikes, you can drop pictures of them to drop@projectklondike.org. We will add them to the gallery. |
|
|
|
Steamboat already pasted Klondike project URL to LSD thread, but in case someone missed it, you can check it out at http://projectklondike.org. And anyone running Klondikes, you can drop pictures of your miners to drop@projectklondike.org. They will be added to the gallery. |
|
|
|
You can download sources here https://github.com/zipiju/k16-firmware. For now just sourcefiles, I'll add compiled hex as soon as git starts cooperating with me . The issue was probably some kind of overflow in PIC, moving a function to different place in a code helped to get rid of all hw errors + there were some little modifications handling receiver reset and baud-rate generator. It was running with 333MHz here for about 6 hours, the stats were: KLN 0: 333MHz 100% 55C | 4.472G/5.345Gh/s | A:29434 R:50 HW:1 WU:74.7/m I needed to take a rest, so no further tests so far, but I'm planning to push it up to 400MHz now. |
|
|
|
I actually have 2boards now hashing with cgminer (Ubuntu in virtual box) now, although each is hashing 20% less than if they were standalone plus the hardware errors are still there. The temperature displayed by cgminer seems to be correct now also.
Although I am also an assembler, I have also been working with Steamboat on this issue for some time. I purchased my own boards from a different pcb manufacturer and purchased my own smt equipment for this project.
What's the rate of the hardware errors you now get at around 300Mhz? I think the high rate of HW is mainly caused by the clock delay circuit, especially the capacitor value. Nope, that's not a cause of high error rate. We've tried couple of values, which delays clock from data from 20 to 50ns. With 400MHz and 4 chips hashing you get error rates as low as 0.6%, with delay about 40ns. But when more chips are hashing, the error rate gets higher, but the delay stays the same. And there is nothing different with power rails, or noise or something like that. So really probably just fw issue. I have 2 boards with 16 chip each hashing at 350 MHz. The hardware error rate is high and we are working to solve that issue. We believe it to be SW related. There is a group of 6 or 8 of us working on this.
By chance is Terrahash one of the ppl you are working with? No |
|
|
|
Can the remaining developers chime in and settle a debate?
Does anybody have a working 16 chip klondike running at 333*16?
To clarify on this, it would be a 16 chip Klondike at 282*16 (4.5GH as Advertised) with low HW Errors. Also if whoever did this, did so using Terrahash's code. You are using 260pF for C274 right? In order to hash with 16 chips, you need to make the following modifications in klondike.c, from line 159: Status.ChipCount = 16;
// pre-calc nonce range values
BankSize = (Status.ChipCount+1)/2;
Status.MaxCount = WORK_TICKS / BankSize / 2;
NonceRanges[0] = 0;
for(BYTE x = 1; x < BankSize; x++)
NonceRanges[x] = NonceRanges[x-1] + BankRanges[BankSize-1];
If you look at that code, you see, that only 8 nonce ranges are defined. How could this work with 16 chips? Any idea? Also, the NonceRanges were defined as NonceRanges[8]. And for everyone here, fully populated board with 16 chips IS NOT WORKING with those firmware modifications that Terrahash posted above. Look at asic.c especially in SendAsicData function. You will get your answer there and in the end of send32 function. But it is a bit tricky how its done there... In fact you only need 8 nonce ranges What are you implying  The question is: Does it work? I can find NO ONE that can get the K16 to work. Okay so i will clarify this: This code NonceRanges[0] = 0;
for(BYTE x = 1; x < BankSize; x++)
NonceRanges[x] = NonceRanges[x-1] + BankRanges[BankSize-1];
generates the following nonce ranges for 8 chips (in hex): Nonce[0]:00000000
Nonce[1]:10000000
Nonce[2]:20000000
Nonce[3]:30000000
Nonce[4]:40000000
Nonce[5]:50000000
Nonce[6]:60000000
Nonce[7]:70000000
Then in SendAsicData you see: last_bit0 = last_bit1 = split;
send32_data = (WORD)&NonceRanges; send32_count = BankSize;
Send32();
and in Send32: MOVF _last_bit0 & 0x7F,W
CLRF LATC & 0x7F
BTFSC INDF1,7
MOVF _last_bit1 & 0x7F,W
MOVWF LATC & 0x7F
This changes the highest bit in nonce value to 1 and then you get the remaining 8 nonces. And between those instructions, is there a one, which changes what PORTC pins to use, when sending data out? Except the DATA_ONE and DATA_ZERO defines? |
|
|
|
Can the remaining developers chime in and settle a debate?
Does anybody have a working 16 chip klondike running at 333*16?
To clarify on this, it would be a 16 chip Klondike at 282*16 (4.5GH as Advertised) with low HW Errors. Also if whoever did this, did so using Terrahash's code. You are using 260pF for C274 right? In order to hash with 16 chips, you need to make the following modifications in klondike.c, from line 159: Status.ChipCount = 16;
// pre-calc nonce range values
BankSize = (Status.ChipCount+1)/2;
Status.MaxCount = WORK_TICKS / BankSize / 2;
NonceRanges[0] = 0;
for(BYTE x = 1; x < BankSize; x++)
NonceRanges[x] = NonceRanges[x-1] + BankRanges[BankSize-1];
If you look at that code, you see, that only 8 nonce ranges are defined. How could this work with 16 chips? Any idea? Also, the NonceRanges were defined as NonceRanges[8]. And for everyone here, fully populated board with 16 chips IS NOT WORKING with those firmware modifications that Terrahash posted above. |
|
|
|
It is most likely a hardware bug in the circuit. During our testing we realized that the Dual NOR gates used in the design are too fast, and there needs to be some propagation delay. Using a cheap NOR gate chip from Fry's did the trick. We are still trying to see if this can be fixed in the firmware.
Maybe you may also want to try to use a bigger capacitor for the phase shifter in front of the NOR gate. A circuit should not depend on the propagation delays or fabrication tolerances of logic gates. I also tried to use the internal comparator of the PIC as a NOR gate, which is even better since it has some clock synchronization register. But it has shown that the comparator is not fast enough... Already tried using bigger capacitor. Does not work. The only work around we have found is using a slower gate, so far. I'm sorry to tell you, but you're wrong. I'm using v0.3.1 board with bigger cap (currently about 260pF) and it's hashing quite well. Without it, the clock signal is not delayed enough - just about 5ns and bad nonces are returned. BTW terrahash, what modifications did you made to the 4 chip firmware to hash with all 16 chips? You are using 260pF for C274 right? In order to hash with 16 chips, you need to make the following modifications in klondike.c, from line 159: Status.ChipCount = 16;
// pre-calc nonce range values
BankSize = (Status.ChipCount+1)/2;
Status.MaxCount = WORK_TICKS / BankSize / 2;
NonceRanges[0] = 0;
for(BYTE x = 1; x < BankSize; x++)
NonceRanges[x] = NonceRanges[x-1] + BankRanges[BankSize-1];
They said here how they got it working with 16 chips..? Yeah the only issue there is, that it's not working and it even can't work with that. The firmware, in it's early stages, were programmed to send same configuration data to both banks. So you had all 16 chips doing something, the only problem was, that both banks were solving the same problem. So you have higher error rate because of the collisions, and only half of the speed. So changing the nonce range with the code above isn't going to help here. And I've asked them again (after that), if they did changed anything else, and got no response. And the response above I only get because they wanted to know from me, what changes I've made in HW to get it working. |
|
|
|
I don't think everyone needs to.abandon. For the sake of community development. I'd say we finish the project. If a handful exist that's okay. I understand people are MIA as well as nerve racked. That is why I believe wr need fresh hands and eyes on this project.
Absolutely! I'm not advocating we abandon the project. But there's no point in continuing the design using first-generation Avalon chips. They are obsolete. At this point, with an assembled board in hand, if you mine forever, you will not make back the cost of the miner. However, we can retarget for a different chip and, at the very least, break even. The design is fully functional, the only thing that needs to be finished is firmware. I have two boards hashing with only one side (with 8 chips) at about 3Ghps, ~3% ER (without USB ferrite beads), chips overclocked to 375MHz with no overvolt. Other side on each board has few chips that do not respond, but this is because those chips were poorly soldered. And on every board it's different side. Tried to fix it yesterday, but was unsuccessful, and now waiting for solder wick and isopropylalcohol. I've also tried some modifications in firmware for 16 chips, but it wasn't really usable. The board with that did hash faster, but had around 20% ER - which is a firmware and poorly assembled chips problem, not the design one. Now waiting with this until I fix the other side, then will continue working on FW. Tried also to contact one of the companies, that claimed to have fully working board (with firmware that hash with all 16 chips), but they did not respond. Anyone here can guess why. About the ROI, it really is gone now, but you have to take into account, that BTC price will likely go up, so even if you lose now, you can gain later. Especially if you've already made an investment in the HW, chips etc. Edit: And about changing the HW for next gen Avalon chips (or any other chips), who is going to make this? Bkk seems to be gone (probably get sick of all the events regarding chips delivery, companies taking advantage of opensource project and giving nothing back) and there is noone (even in the group of those companies, which started their business on this) who is able to make this change. Is it not possible for you guys to use TerraHash's stuff? They said they have working k16's with less than 1% error rates. What Terrahash stuff? They have used stuff that Bkk made as opensource. To be absolutely clear on this, I've wrote to them about mine board with 4 chips assembled hashing at 400MHz with around 0.6% ER, when they were asking me via PM about the changes in HW I made to get it working. They were not able to fix even this for the whole time. They claimed even here on this forum, that the design is wrong. Later, when they did claimed at 5th of September, that they do have a working board, and the only issue there is I2C, I've wrote them again, asking what firmware changes do they made to hash with all 16 chips and that low error rate. They didn't even bother to wrote me back. So what do they actually have? Nothing? Lies? |
|
|
|
I don't think everyone needs to.abandon. For the sake of community development. I'd say we finish the project. If a handful exist that's okay. I understand people are MIA as well as nerve racked. That is why I believe wr need fresh hands and eyes on this project.
Absolutely! I'm not advocating we abandon the project. But there's no point in continuing the design using first-generation Avalon chips. They are obsolete. At this point, with an assembled board in hand, if you mine forever, you will not make back the cost of the miner. However, we can retarget for a different chip and, at the very least, break even. The design is fully functional, the only thing that needs to be finished is firmware. I have two boards hashing with only one side (with 8 chips) at about 3Ghps, ~3% ER (without USB ferrite beads), chips overclocked to 375MHz with no overvolt. Other side on each board has few chips that do not respond, but this is because those chips were poorly soldered. And on every board it's different side. Tried to fix it yesterday, but was unsuccessful, and now waiting for solder wick and isopropylalcohol. I've also tried some modifications in firmware for 16 chips, but it wasn't really usable. The board with that did hash faster, but had around 20% ER - which is a firmware and poorly assembled chips problem, not the design one. Now waiting with this until I fix the other side, then will continue working on FW. Tried also to contact one of the companies, that claimed to have fully working board (with firmware that hash with all 16 chips), but they did not respond. Anyone here can guess why. About the ROI, it really is gone now, but you have to take into account, that BTC price will likely go up, so even if you lose now, you can gain later. Especially if you've already made an investment in the HW, chips etc. Edit: And about changing the HW for next gen Avalon chips (or any other chips), who is going to make this? Bkk seems to be gone (probably get sick of all the events regarding chips delivery, companies taking advantage of opensource project and giving nothing back) and there seems to be noone (even in the group of those companies, which started their business on this) who is able to make this change. |
|
|
|
Wrong thread |
|
|
|
Zip, that's a great find and explains a lot of mystery. Well done lad ! - post an BTC address so we can tip you
Send that tip to BkkCoins. He deserves all the glory. And don't get too excited, I've made that mistake couple of times . |
|
|
|
|
