 Show Posts
|
|
Pages: [1] 2 3 4 »
|
|
Antminer has been coming through for people. I'd go with them. I'm invested in KnC, and can recommend, but like you said, on the cheap: Antminer IMO
Thanks for the support too. It's nice to see people with your mindset. And who knows, if BTC goes to the moon, you might even make a profit FTW.
|
|
|
|
Spondoolies Tech dude?! Please. Vaporware. Who are they? What's their track record? Look at the product design: no way you can cool their claimed hashing power in rack server form factors like that. Calling bullshit right now. Run.
Have you checked their thread: https://bitcointalk.org/index.php?topic=521520.0 ? dogie (who posted a big review of it), ckolivas and me and some other customers already received their SP10 unit and yes it is possible to cool it because they are just that good and because it's loud (this will be fixed in the future)  I stand corrected. Seems pretty legit. ckolivas is credible. One to watch I guess. Terrible business name though |
|
|
|
|
Spondoolies Tech dude?! Please. Vaporware. Who are they? What's their track record? Look at the product design: no way you can cool their claimed hashing power in rack server form factors like that. Calling bullshit right now. Run.
|
|
|
|
|
Well I'm sure you guys have seen KnC completed "tape out". Sounds like IMI might be right with June delivery, assuming chip arrival takes 60 days after tape out. Is there any evidence for chip delivery after tape out taking 60 freaking days?! Thanks.
|
|
|
|
Copy/Paste: In stock Neptunes jumped up again from 898 to 909. More refunds? Maybe. I've got a few preorders with alpha-t.net, a Scrypt ASIC. I'm pretty impressed with their development updates (nearly weekly), along with a forum specifically for customers with all the questions answered, as well as their transparency with their process. It's too bad more manufacturers don't do similar methods. I'm still keeping my CA batch orders. Better than BFL, CT, HF that's for sure. How they compare to Bitmain will really be a long term question, although I think KnC hardware will run much longer and be more profitable. We'll have to analyze that one down the line. I have a thread on when the general memberbase thinks the Neptunes are shipping, and the majority feel it's April, which would line up the latest batch during Q2. https://bitcointalk.org/index.php?topic=384125.0@Offtopic individuals, you guys should really keep on topic. Let's focus on KNC (I don't care if we talk about KNC conspiracy theories, facts, or whatever), there are venues available for other discussions. april?! that wishful thinkin imo. i dont think they taped-out yet and from tape-out to production you can assume roughly 60 days. so lets say they tape-out in the coming weeks and need 60 days till the chips arrive. that means the chips arrive in mid may. then also assume that chips doenst mean everything is ready to deliver, you got to bring that thing to work somehow. that leaves us to a delivered neptune in june, imo. I hear ya man. I don't think they're going to announce all that tape out fab out stuff though. If I'm remembering correctly, and we compare what happened in their first product launch, they were pretty tight lipped, except for leaks by Bitcoinorama. They said they'd ship in late September through October and they did, only late by like 2 weeks. IMO I think we should expect the same, although the Jupiter farm and accompanying announcement makes me a bit nervous. They fucking slammed us with difficulty with that damn farm too! Looks like its complete now though with recent Swedish press and difficulty slowing at the moment. |
|
|
|
They will not ship Neptune until much later (Q3-Q4) or never.
LOL! |
|
|
|
Edit to say, after to put again the firm 0.99.1 tune, i have a little problem with voltages.. it was crazy.. now is working well after reset to factory defaults in advanced but a line 12v of my 1100w PSU now is dead, i got a screenshot, any idea of this?  The VRM are designed for 40W, many of us regularly push them to between 50-60W. At 70W per VRM I think you are on your own in new territory! Your screenshot shows 70W per die (per VRM also). 70W x 4 die = 280W per ASIC Add AT LEAST 10% to that because the VRM's use that much before even cooking them by overclocking. OVER 300 Watt per ASIC is what your power supply was asked to do before failure. (you were asking for >1200W from a 1100W supply) I suggest 300W per ASIC is possibly too much. Almost definately too much for a single PCIe 6 pin power connector. You can install another on each module, KnCMiner provided for that on the PCB. YMMV Good advice! Greed is NOT good Mr. Gecko! |
|
|
|
still running 291/790GH/810w oct. jupiter  291?! Hot damn! |
|
|
|
This 1.0 firmware - KnC states you can change clock speeds through the GUI. Can you actually overclock on a per die basis? They were always talking against overclocking and voiding the warranty. Can someone using 1.0 confirm this? Screenshot? Thanks.
Very interesting. I didn't notice this before, but it looks like the default clock of an October Jupiter is 750, and it can be increased to 775 in the 1.0 web GUI. The default clock of a November Jupiter is 900, and it can be increased to 1000 in the 1.0 web GUI. I guess it's time to play around now... Ok only to 775 via the GUI on a October Jupiter. That makes sense. They're not letting people do much. Custom hacks are still the way to go then. Thanks. |
|
|
|
|
This 1.0 firmware - KnC states you can change clock speeds through the GUI. Can you actually overclock on a per die basis? They were always talking against overclocking and voiding the warranty. Can someone using 1.0 confirm this? Screenshot? Thanks.
|
|
|
|
|
Yeah I don't like their arrogant tone and their failure to deliver on the 2TH/s promise. Now a 400GH/s card slated for JUNE?! Comon. Cointerrible.
|
|
|
|
I have an October Saturn currently running 612/589ghs through cgminer and 585 through KNC's gui. This is far and away the absolutely highest numbers I've seen (for me and this machine), by almost double. Thing is, it's doing no good. Error must be bad. WU is only 1450ish. Poolside reporting is tragic -- looks like about 185ghs. If someone can help me figure out how to make use of this apparent speed/reduce errors, I'll leave you a nice tip. I don't have enough knowledge and must resort to bribes. Not every die is going to enjoy being overclocked. Use something like Bertmod to see which dies have disabled cores due to hardware errors. Using the per module, per die script, return troublesome dies to their original clock setting of 1D1 or whatever yours was. There's no strict rules. You have to experiment to see what works best for your machine. If you PM your Bertmod per module stats and your script, I can recommend clock settings. |
|
|
|
Thank you very much j03. I'm not clear on exactly what to modify in the bash script for an October Saturn, but I'm getting there.
KNC gui shows ASIC slot #3 and ASIC slot #4 are used. I assume this is 3 and 4 on the control board? There are two free spots to the left and two to the right.
---------------beagleboard side----------------------
plug plug plug plug plug plug
{FREE} {FREE} {USED} {USED} {FREE} {FREE}
| |
| |
| |
| |
[ASIC] [ASIC]
4 dies 4 dies
---------------ASIC/FAN side-----------------------
How do you count these spots for the script?
Looking down at the controller board from the direction you have illustrated, the plugs (ASIC board numbers) are 0 through 5 counting from right to left. So, your boards that are in use are: 2 and 3 from right to left. |
|
|
|
Thanks very much, j03. I'll try testing that way.
I have not been able to find the bash script, but I'll look again. A couple questions:
1. Is Bertmod ZPM different from v4? Is this from the KNC forums?
2. Have you done any SPI voltage, SPI frequence, or per-die tuning in the KNC Advanced gui?
3. What's your order of procedure? I have:
-flash a KNC firmware
-run enablecores.bin (just out of habit)
-let the machine spin up
-ssh into cgminer
-"vi /etc/init.d/cgminer.sh" to get to clock settings
-adjust clock settings
-type esc, then a colon, and then "wq", then enter
-machine seems to reboot on it's own, i don't restart
-watch the new hashrate
-mess with tuning, even though I don't know what im doing
-compare pool and machine hash rates
-wonder what's going on (LOL)
Could you share? Thank you very much.
Bash script is here. Keep the original clock setting on line 61 and paste the script in beginning on the next line (line 62): https://bitcointalk.org/index.php?topic=313978.msg4432410#msg4432410That script is for a 4 module, 4 VRM machine and assumes you modules are plugged in 0 through 3 connectors on the controller board. Change to your setup. Also, you need to add or subtract the number of module IF statements based on your machine. Mine is a Jupiter+2, so I added 2 additional statements for modules 4 and 5 that are plugged into the controller board. The 4 die clock settings within each module IF statement assumes 4 VRM. If you have 8 VRMs, add 4 more within each IF statement. 1. Not sure about the diffs in Bertmod versions. 2. I haven't touched Advanced Tuning because I also have no idea what I'm doing there 3. My procedure is the same as yours but you forgot /etc/init.d/cgminer.sh restart after :wq the changes. Don't reboot the machine or you'll lose your changes. Also applying changes at Advanced Tuning wipes changes to cgminer.sh. There's instructions in this thread to make your custom cgminer.sh persist on reboot, but I haven't done it. I currently get around 920GH/s on a Jupiter+2. |
|
|
|
Any ideas on how to reduce errors? Does tuning do the trick?
I've been getting some crazy machine-side speed reporting from an October Saturn. The KNC GUI is showing 398gh. SSHing into the machine is showing 398/355.
Poolside, however, I'm apparently only getting 227? Can this be accurate? I presume the problem is errors, but I don't know...
Just my 0.02: I noticed better hash rate matching between the pool and client with cgminer 3.9.0 on firmware 0.99.1-tune. As far as reducing errors, I've had good luck with not overclocking, or underclocking, some dies and overclocking others. Use the bash script that CYPER posted in this thread a while back in order to set per die clock settings. I still use Bertmod ZPM fix to analyze individual module/die performance. |
|
|
|
Below 1B1 is 1A1 (675) Below 1A1 is 191 (650) There is something to be said for the efficiency increase at lower speeds. I keep it in mind as the efficiency tradeoff for speed becomes moot at some difficulty level. Above 251 is 261 ignore the last digit 950 MHz would be 25 (251) 975 MHz would be 26 (261) 1000MHz would be 27 (271) Increase by one It's hexadecimal so A comes after 9 (instead of 10) TANGENT alert! To calculate the value in the last column Again ignore the last digit, multiply by 2 and add 1 (determined experimentally) ex: using 825MHz because the hex and decimal LOOK the same and the math works. 825.0 MHz 201 412 201, drop the 1 20 x 2 = 40 40 + 1 = 41 add a 2 to the end for last column 412 is the same as 201 Think of it as 20 divided by 1 or 40 divided by 2 (plus 1 for the div by 2 instance) Most should have a calculator with hex mode, try it on a wierd one with a letter! Aha. Thanks tolip_wen. Seems so obvious now |
|
|
|
Can't seem to find the rest the chart below anywhere. Anybody know the settings for below 1B1 and above 251? I'm having good luck underclocking some dies and overclocking others. Thanks. SPEED setting
700.0 1B1 372
712.5 382
725.0 1C1 392
737.5 3A2
750.0 1D1 3B2
762.5 3C2
775.0 1E1 3D2
787.5 3E2
800.0 1F1 3F2
812.5 402
825.0 201 412
837.5 422
850.0 211 432
862.5 442
875.0 221 452
887.5 462
900.0 231 472
912.5 482
925.0 241 492
937.5 4A2
950.0 251 4B2
|
|
|
|
|
I believe it's a few million dollars to produce a 28nm process chip.
|
|
|
|
|
