this didn't seem to make sense.. accepting btc is too much of a risk for a company like facebook, and what are the benefits really?
it's probably a fake ... |
|
|
|
Either folks at FB are worse in CSS than me in MS Paint, or this is fake:  probably a fake. |
|
|
|
Phoenix (and anyone else with the HW issues)
Try eligius' secondary pool, it seemed to have clean up my flushwork issues.
v2.srv.eligius.st:12234
Overall HW is down, WU is up about 2%.
3 hours and running, the 6 module jupiter is pushing 99.7% of rated hashrate to the pool (838/840)
Is there any reason why the secondary eligius pool behave differently? Do they have different backend/algorythm? |
|
|
|
1. Firewall the system from remote access, there is no reason any port on a KNC Miner needs to be accessible on the open internet, it works fine from behind a NAT on a home router, etc.. If you need remote access recommend a VPN solution as an option.
This. Never ever expose your miner directly to the internet. Do not assign public IP to miner network interface. Even if you're using a private address for your miner do not trust your router fw/firewall. Router firmwares are updated once in very long while, they reach support EOL quite rapidly. Taking this into account implies using your router port forwarding is moot. Use a bridge system between your router and your miner(s). Be it a linux hardened box or an OpenBSD one. Set up a firewall on this machine that do both ingress/egress filtering. Set up a VPN service on this bridge box. Access to the miner only through this VPN service. If you do not have a static IP spend a few bucks a month for a VPS with a static IP address and use n2n (a layer two p2p VPN) to mimic a more classic VPN set up. |
|
|
|
This morning I received an email from btcguild saying that one of my miners hasn't submitted shares for some time. This time it was KnC Juniper from October 2013 batch. I couldn't ping the miner, so I suspected a blown power supply. I went to the mining location and here is what I found:
1. Power supply unit is okay (HX1050), I measured all voltages with my multimeter, everything tested out fine
2. There is no problem with router or network anything, other miners run fine
3. The issue is with KnC miner itself, with BeagleBone to be exact.
I shut off the unit and after waiting for 30 seconds powered it back up. All I heard is a high pitch sound, coming from a control board. There was no LEDs on the board, all fans were spinning normally. I have an extra BBB, I swapped it and restarted the unit. Well, no high pitch sound this time and nothing was hashing of course. I went to get the recovery image off the KnC support site and was unable to use it!
Here are my questions:
1. Has anyone experienced anything similar to what I described?
2. It appears that KnC BBB and original BBB are very close to each other (KnC is missing USB port, power 5V plug, HDMI output). How do I get the image onto my BBB in when it happens again? In fact, there other reports that original BBB works with control board. (Instruction were the following: download .zip from support site, format flash as fat16 with boot flag and then unzip the recovery zip onto the root of the SD. Then, put the SD into the BBB, power up and hold USER/BOOT button for 3-5 seconds - that is when the flashing process should start with proper LED indication) - that doesn't happen at all. Any ideas?
3. Does KnC support has advanced RMA feature?
4. WTF?
Please advice.
P.S. It was a first major blow for KnC miner since October 18th 2013! Near perfect operation, 99.98% uptime!
I've had the same experience, modulo the high pitch sound, all the other sympthoms fit your descriptions. One thing that I noticed is that the only light coming from the machine was a fix blue one, it came from a led on the BBB. Anyhow this is what I did (more or less the instrunctions that kncminer would send you in case you will ask): 1) Download and unzip the content of the archive on to a micro SD card formatted with FAT file system. 2) Turn the miner off via the power supply off switch and disconnect from the wall. 3) Open the case of the miner. 4) Insert the micro SD with the recovery files on it in to the SD card slot on the controller board Note: to insert the micro SD card into the slot it might be necessary to unplug the flat cables which connect the ASIC boards to the controller board. 5) Reconnect the power supply and turn the power on. 6) Please wait while internal MMC flash memory is reprogrammed there will be a sequence of LED as follows: 1,2,3,4 blue LEDs on the BeagleBone will turn on, then bright white LED inside the case turns on for several seconds and then the red + green LEDs on the control board are on this means that the programming is in progress. When only the green LED is on for 5 seconds this means that the recovery was successful then all LEDs should go off and it means that the procedure completed. 7) Turn the miner off again and disconnect from the wall.  Eject the micro SD card from the controller board. 9) Plug in all the cables that were unplugged and ensure that they are secured. 10) Reconnect the power supply and power on. The miner should then start from the on-board MMC flash with the software revision 0.96.1 After the miner is up and running again you can download the latest firmware version 0.99-tuning and apply the latest firmware. |
|
|
|
My october jupiter is runing at 665 Ghash stable for two weeks now.
boards are All 4 VRM
KNC tuning settings to default (lets be fair, the stuff i shitted this morning does more then that suite), for board 3 die 1 just a liitle higher voltage because 2 chips that would else would go marked bad.
Ambient temp is between 20 and 22 degrees.
using bfgminer and custom bgfminer script with all board and dies on 231
All VRMs are just below 60 amps stable between 57 and 59 Amps
Temp board 1 67 degrees
Temp board 2 70 degrees
Temp board 3 79 degrees
Temp board 4 62 degrees
Thank you verry much for the info on overclocking. it gives me an extra 115 Ghash
so it seems that 4 VRMs board do not need a voltage boost to work under extreme OC settings. On my Oct jup as soon as I increase the OC if I don't do the same for the voltage settings I will obtain a storm of "Knc core x-xx disalbe due to.." on cgminer interface. Do you obtain the same perf using cgminer instead? |
|
|
|
Small update after my OC try.. I put a fan on one of the boards that was running a bit hot and it seems to be fine.. you can see here the eligius stats of when I changed it.. im running at around 634Gh/s for 12 hrs.. before OC it was around 550.. edit.. crap forgot the image http://diyasic.com/oc.jpgwhich value did you use for OC? did you use the same OC settings for all of your boards? I think I posted the link to pastie of the config.. just running 211, nothing else special. you're right, sorry. somehow I missed it. Are the voltage that you're applying the maximum? |
|
|
|
Small update after my OC try.. I put a fan on one of the boards that was running a bit hot and it seems to be fine.. you can see here the eligius stats of when I changed it.. im running at around 634Gh/s for 12 hrs.. before OC it was around 550.. edit.. crap forgot the image http://diyasic.com/oc.jpgwhich value did you use for OC? did you use the same OC settings for all of your boards? |
|
|
|
the concept just sort of glues together DHTs and Bitcoin-like Blockchains. DHTs have a number of problems associated with them. Also if he wants to use the Blockchain, there must be some clear incentive for the 'mining' function, in this case there is none(he does note this on his website).
Cool idea, but likely to break or be compromised if ever used in any significant capacity. No one has explored attack vectors yet.
I very much agree with these statements. This can not possibly scale even up to smallish numbers. Actually its the same reason exchanges can not be distributed. The blockchain can't be used for time-ordered messaging. Transactions in the chain are not ordered. The order of transactions in one block does not matter. However, order of messages in communication does matter. If in a thread one post comes later than another but refers to ts hat post, order is not preserved. So a conversation (i.e. message B is a reply to message A) is not possible, because order is needed. I think there is generally not a good understanding of what can be done with the blockchain in principle. The most interesting application by far is namecoin. The reason is that the cycle of messages is much longer. You reserve a name and this stays constant for say 12 months. I find it also interesting in that a domain name really is a link to a server, operated by a person or organization. If you think about it a corporation is really not much else. Twitter is a set of people tied to the services of Twitter Inc, a completely fictitious entity. There is no reason we could have much better legal frameworks. For example most multi-nationals avoid taxes completely with various schemes, corrupt governments, hand over information to power groups etc.etc. Didn't namecoin "blow up" for some reason? There was some bad news last month about it, just can't remember exactly what it was. you're right. There was a serious bug, in the beginning the current maintainer thought it was unfixable. Eventually he and the community found a solution and fixed the problem. At the moment on the exchange platform that I commonly use 1 NMC values is 7.71$. |
|
|
|
wow more than 200 Amps per Board. I suppose you have 4 VRMs for each board right? One last question: Are the voltage values you setted (-0.1121) the maximum available? |
|
|
|
No errors
SPI 1.95 V
Freq 201442
try to increase those values mine are 2.05V and 299707Hz, I'm in a hurry now but I rembemer 'Orama saying that OC require to pump up those values to keep the communicatoin between the FPGA and the asic sloths healty. |
|
|
|
Do they change their ASIC perf specifications since they announced it here? tacotime quote 735GH/s abd .59 W/GH/s... The Golden Nonce is:
The fastest Bitcoin mining chip in the world today — up to 735 Ghash/s per chip!
The most energy efficient mining chip in the world today — 0.59 watts per Ghash when run for maximum efficiency
The most silicon-efficient chip in the world — producing up to an astonishing 2.27 Ghash out of every square millimeter of silicon!
We couldn’t be prouder of these results – and can’t wait to see what the community can do with it. Well, if mine ever manage to materialize they sound kind of nice. now on their site http://hashfast.com/were-shipping-2013/ it's stated 664 GH/s and .67 W/GH/s |
|
|
|
(remove a lot of useful info)
At the end the default-settings for Advanced tuning works best (for now), BUT after playing with those
settings, and at the end setting all the Advanced tuner settings back to original values(manually) resulted in the worst performance of 250 Gh/s and the only remedy was to reflash the FW.
I'll play again with the settings after next diff change.
it's quite peculiar. in my experience an overclocked die need more voltage to keep the number of disabled cores low. e.g. on my 211 asic board I get at least 20 and 15 cores disabled in the first and the third die respectively if I left the same voltage settings used for 1F1. I had to set it way higher to get almost all cores enabled, and after that another bump has been necessary to lower the error rate. Speaking of power consumption: all dies across the boards are between 45 and 49 Amps. I have different OC settings for each board. The higher is 211 the lowest 1F1 and I've noticed that despite the OC settings and factoring out the voltage settings, the 4th die of each board is the one that drain more energy. |
|
|
|
Just to share my settings/performance: - October unit (Asic 1 = 4 VRM, other 3 are 8 VRM but only 4 active) - Firmware 0.99-tune - Clocksetting on 231, no other firmware changes. - Harware mod: Lowered the Asicboard-fans (more airflow over the board), added 2 fans at the outlet (so now push + pull) and slightly lowered fan speed to reduce the noise (80%). Images Status page --> 676 GH/s / 9131 WU Advanced page --> 2.5V SPI and 256kHz frequency, slightly modded volts (higher, as required for the increased clock), not completely fine-tuned. CGminer --> Error rate used to be 3%@560GH/s, since I lowered the volts a bit after the initial increase this increased to just below 4%. Fine with me as it lowered the temps 5-10 degrees an decreased power to 'around' 40 W per DC instead of closer to 50 W. Pool stat --> 650ghs average Power consumption in bertmod used to be 453 W, now it is 651 W (43% increase in consumption for 18/19% performance increase). With voltage finetuning the power consumption should be able to come down a bit, now it is all pretty much on the safe side (safe as in: higher voltage as required to avoid that cores get shut down). thanks for sharing your configuration! I've just bump up the OC to my miners, not as far as you did, though  I've different OC setting for each asic board. The hotter they run in the factory configuration the lower the OC. So I've the two front asics using the 201, left-rear using 211 (additional side fan, 80x80, pushing air unnder the main sink), right-rear using 1F1. For the SPI i'm using 2.05 V, 299707 Freq. I've found that to lower the hasrate under 5% I need to rise the voltage per die to get at least 35-6 Watts for each VRM. With this setting I get a WU of ~ 8400 and an error rate of ~ 4%. The next thing I want to try is lowering the Asicboard-fans, adding another small lateral onf the right-rear board and the pushing the OC settings higher for all the boards. |
|
|
|
On the November unit I have for testing, disabling work flushes in the cgminer source and running cgminer with -q -T gives me the following stats: (5s):731.0G (avg):681.2Gh/s | A:88420915 R:1590264 HW:133439 WU:9414.2/m Comes to ~0.15% HW errors. Pool side 3-hour rate is 670Gh. Disabling flushes causes an increase in rejected shares, but this seems to be far less of a loss than the false HW errors. Basically, flushing is broken in all current firmwares it seems. There is also a false HW error issue in the cgminer driver that was partially fixed in this commit to their cgminer fork. I'm currently working on a fresh rewrite of the driver. Just figured I'd throw this out there somewhere. -wk thanks for sharing wk! Flushwork has been the weakest point of knc cgminer driver since the beginning. Just drop us a line when your rewrite will be complete. |
|
|
|
I have my jupiter now at '201' with the case off and an extra 120mm fan right in the middle pushing the cooler intake air toward the rear boards. Seems to give steady 621GH/s (12+hrs) with temps from 40-58C across the boards. With proper cooling I have kept the wattage per asic around 40W so as not to overload the vrms. Not a bad result for a small text editor change and a fan. Next up will be to see if I can lower the voltage needed to keep this performance and maybe go to '211'. I had missed tinkering in the asic era, no longer.  what's your HW errors rate? I'm going to apply 201/211 to the rear-left asic just to see how it beahave. if everything is ok I'll set 201 also for the front boards. |
|
|
|
|
other two things I've just discovered:
- voltage settings are persistant across reboot. it makes sense since they're stored into /confg/advanced.conf
- the rear asics board run hotter than the front one (with or without case, and with or without overclocking). in my case the hotter is the rear-left one. I have a spare case fan and I've decided to use it to cool down the aformentioned asic board. The result was quite impressive on a 1F1 OC machine the temps lower from 65C to 42C and over HW error rate lower from 4.5% to 3.1%.
I'm planning to the same for the rear-right asic as soon the next time I'll go to the colo facility. Once I've done that I'll try to run the miner to higher freq/voltage.
|
|
|
|
Wonderful thread gentlemen, really shows the pioneering spirit of the mining core. Thank you.
Has there been a conglomeration yet of the tuning suite's best practices. Kind of like 'these ranges of voltages seem to keep up performance for less power' or 'certain SPI frequencies yield better stability results' etc.?
I would like to start adjusting values on the Adv. page if there is cause but without a manual or even best practices it is daunting.
no. unluckily there's no a "easy" howto so far. anyway the two things I've learnt about "Advanced" settings are: - once you've overclocked probably you'll notice more disabled cores than usual. to make those cores working again you need to set a higher voltage for the die to which they belong to. - The higher the hashrate the higher the SPI freq if you want to keep the HW error rate in shape, and that means that probably you need to higher also SPI voltage (I still haven't tried this, though) |
|
|
|
|
Show Posts
