Btw JakeTri has his code he converted from the python hf-tool into cgminer pushed into the latest git of cgminer.. so you have commands like --hfa-options <arg> Set hashfast options name:clock or clock@voltage (comma separated) --hfa-options "rabbit:650,turtle:550@800" +Would set a device named rabbit to clock speed 650 MHz using default voltage
+and the one named turtle to 550 MHz using a voltage of 800 mv. Starting the
+device at a speed where it is most stable will give more reliable hashrates
+long term and prevent it interacting with other devices, rather than depending
+on the clockdown feature in cgminer. see https://github.com/ckolivas/cgminer/commit/ef97e80a14240c95a7d2966abe462b12f7d4bf03you would need to build the latest git cgminer for this to work. Also use with caution, we cannot be responsible if you happen to blow up your board |
|
|
|
A simplified version of my voltage adjustment was merged yesterday into cgminer. This version set same voltage for all cores/dies and use following new syntax for --hfa-options:
name:clock@voltage,name2:clock2@voltage1, ....
+1 |
|
|
|
Welp, after doing some even further digging, Ive confirmed there are 8 cores being disabled upon startup by bfgminer. The resultant hashrate loss is nearly identical to what Im seeing in cgminer.
Some further things noticed & tested:
1. Ive confirmed that at least 1 of those disabled cores is able to do good work, by enabling it in bfgminer & watching it have a share accepted.
2. I couldnt believe it at first, thought I was going crazy, but the 8 cores that are being identical are 4 per hab, the id of the cores being EXACT between the 2 habs... WTF?!
0dr,0hj,0lb,0ot & 1dr,1hj,1lb,1ot - as seen in bfgminer
3. I went and hit the reset button on the board and noticed bfgminer re-detect the boards, each time a different core count was detected, ranging from min of 760 to a max of 766!(only 2 disabled)
4. I manually turned on those disabled cores in bfgminer, seeing my hashrate climb to what it should be, at least measured locally.
5. The state in which those 8 cores are upon bfgminer start is "RST"
Any ideas as to what could be going on?! =/
This is confusing the hell outta me....
are you running cgminer with --hfa-noshed ? HF chips can report to have babbling cores that just seem to do random stuff at times, its not clear and we where told it was fixed in .5 of the firmware but well take it with a grain of salt with that statement. |
|
|
|
I can confirm JakeTri method works fine with a two-board setup on latest cgminer 4.3.4 built from git. (Prior to the code being reverted). I can't comment on the default hash rate jaketri notes above due to a preexisting issue. For some reason on my Ubuntu 12.0.4 install, setting hfa-hash-clock to 1 forces all dies to the lowest speed configured per card. I just want to make sure that everyone is aware that this would be a replacement (especially under Windows or say a rPi) for the Python script, and not something that you would run every time you start cgminer.
MrTeal, can you comment on why someone wouldn't want to run this every time they start cgminer? When you say lowest speed, that would be the speed that was set with the hf-tool.. so if you set your volts to lets say 940, and freq to 900, --hfa-hash-clock 1 as *we* understand it would then run it at 900Mhz.. I could be wrong and I haven't had enough coffee yet to wake up my brain cells. Its proba a good idea to stick with the hf-tool for a bit until Jake can work on the part of the code, with the tool you just have to set it once so every time you restart cgminer or so you do not have to set this and we are not 100% sure if their is any fallout or issues doing it with cgminer writing to the flash all the time. |
|
|
|
Yeah, this sucks, I guess they are damaged now somehow, no idea, Ive upped the voltage plenty on the 875mhz one and, temps are till under 100C but hashrate are still stuck at 645-650GH
Even tried next mv setting up for the one at 850mhz and it has no effect, just runs hotter ... ugh, its hashrate still at 630-635GH
So, somewhere Im losing 3% on each one =*(
What do the 3 buttons do? more specifically the reconfig one, does that restore firmware defaults or allow firmware installation?
Also, like in my original post, any way to see the status of each 96 cores?
Thanks
Sorry to hear about your issues, as far as a status of each core cgminer does not provide this information, BFGMiner does but I haven't had the time or energy to work on porting the Pepper App to use BFG, and while BFG is a great miner its missing some of the functionality currently that you can do with cgminer for HF/HAB products. One thing is to check your inflight value per board, now this isnt displayed in the pepper app, I could prob make a build with a debug option at the bottom of each page, this should be around 760ish.. if you have damaged a die this value gets lower. Mr Teal could maybe elaborate a bit on this if he has time. Also while these things can be fun to play with and tweak to maximum performance their are times where damage *could* happen. I have busted a few boards just doing this and killed off a die so just be careful with them. |
|
|
|
Totally different subject. I have three Habs and three Goldrushes. I have them mixed with 3 running on a pc and 3 running on a Rpi. My issue is the Rpi. It seems to lock up and lose communication with the network after 3-4 hours. It needs to be physically reset. I use a data center so that really sucks. I have a similar issue with a pi on the old Drillbit miners. But for that one I bought one of those network enabled outlets that I can cut off power and restart power via the web. But those are not cheap.
My question is if anyone else has reset issues with their Rpi and if so how did you fix it. Bad SD card? Different hub or switch to router? Grasping here.
You can configure the watchdog to reboot the Pi when it hangs. I have only used the watchdog with peon on the Pi and it seems to have fixed the hang issue. Try get hold of a BeagleBone Black $55 from adafruit who also accept btc, they work much better then the Pi. (i have 2x Pi and 2x BBB) There area few posts online saying the Pi flaw in the architecture that causes the USB to lock, which then also locks the network. Some say overclocking the Pi can help but it still locked up for me. Thanks guys. The PDU is bigger than I have room for and upgrading to 240v would cost me. I have an old laptop I'll stick in there for now. But I think I will try a beaglebone and see if that works any better. I appreciate the advise and glad to hear I am not the only one with hanging Rpi. I would avoid the beaglebone for now, it has a hot plus usb issue that doesnt seem to be fixed even in some of the beta kernels.. anyhow just my 2 cents since I tried to get one working and just gave up. |
|
|
|
So, the voltage tool... I got it working, does it require setting custom voltages across power cycling? Or does it maintain the settings Ive specified?
I love the tool btw, I got one of my habs at .81v(under load) @ 725mhz @ 550GH @ 590 wall watts(can do 750mhz as well but keeping lower so my PSU stays alive).
With the 280L, fans @ 100 .. the above settings yields a hottest core of 80C ... cant wait to get my PSU's to power these puppies.
Having said that, changing voltages, in the slightest, makes a huge difference in power & temp on these things.
Ive also noticed that cores will "drop out" momentarily if the voltages are too low at a given clockspeed even before HW% becomes an issue.
----
On another note, I think gateway said it, but Im gonna reiterate the importance of head pressure when screwing it down onto the chip, DO NOT do it too tightly, I was looking at the board sideways and I can see the actual PCB of the package(PCB the dies set on, not the PCB of the main board) bowing because the dies were being pushed so hard down into it.
Since then Ive loosened all screws a great deal and maintain same cooling temps.
Check out this post, maybe that helps you understand the drops when using the Pepper App and some suggestions what to do. |
|
|
|
I am extremely pleased with my Habanero purchase. From checkout to delivery the entire experience has been transparent and satisfying. If you are happy with your purchase and with the support Mr. Teal and Gateway provide on the forums, then you should give their username's a positive trust rating. Might as well let others know that they are trustworthy enough to do business with.
Thanks, its been an interesting road for us on this project and also it was also quite exciting to go from start of a new design to final production and out the door in a few months. |
|
|
|
I don't think it exists.
@Gateway, @MrTeal: could we gain your opinions on whether the HF-Tool will/would work under windows. After a quick look. The tool is built from Python, uses pip to install pyusb. Pip comes standard with Python 3.4 install. And the board identification code seems like it wouldn't be tied exclusively to linux. Either willing to try it? Pip installation instructions: stackexchange linkI have tried this. I installed the usb dependencies with pip and tried to run hftool. I got 'HFBulkDevice not found' about every second in a loop. I haven't dug into the hftool code to find what is causing this error, but I can confirm it doesn't work on windows. I woulnt hold my breath on windows hf tool, however someone has taken the time to take the python code and convert it to be used in cgminer, read though this thread to see the work on it.. You can see the commits here and he has send a pull request to Con to see if he would integrate it into the latest cgminer. |
|
|
|
Maybe im tired today but what does the -50 mean? cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0" Also maybe a small change but easier to read would be name:die/s:mV@freq so to do all dies it would be hab1:*:930@875 ? |
|
|
|
How do you plan to address if a person has more than one board on their system, and what about sierras that are changed, granted this is more for habaneros that don't have the chain up or down.
For now the "new" settings are applied only if board have 4 dies ... that should cover habaneros and yoli. I think the change to cgminer can be expanded to support chained boards (like sierras) but I don't have any way to test it. For chained boards it would be tricky to find a way to provide the settings (voltage and clock value/offset) for individual dies in the command line. cgminer already support individual (per board) settings based on board name (set with cgminer using --hfa-name) when multiple boards are connected to one system. Here is the command line that I used on my system where I have connected 2 habaneros (one is named "pepper1" and the other one is "pepper2"): cgminer --hfa-options "pepper1:925:950:920:950:950:0:-50:0:0,pepper2:950:930:960:970:970:-50:0:0:0" Similar hftool command line for the system with "pepper1" connected would be ./hftool.py -w 0:950@925,1:920@875,2:950@925,3:950@925 and for the second system with "pepper2" ./hftool.py -w 0:930@900,1:960@950,2:970@950,3:970@950 And to use hftool I have to use 2 systems instead of one  Cool, well I say send it over to con so he can pull it in, prob should add something to a readme and maybe a warning, experimental feature for now.. this will give windows users maybe the ability to change voltages, lets just hope they dont make it 1000mV, I have no idea what might happen.. |
|
|
|
@JakeTri How do you plan to address if a person has more than one board on their system, and what about sierras that are changed, granted this is more for habaneros that don't have the chain up or down. python on windows.. blah hahaha |
|
|
|
I have been getting this error when the board is clocked at 850.
I am running the board on a pi with cgminer 4.3.5.
Is the board just getting too hot? I have not changed any voltages.
Need a few more specifics.. What is the temp of your dies, ambient temp, and are you blowing any thing over the board to keep it cool? What is your voltage set to? Also note at times ill be avail on irc channel ##habanero for any questions.. this is on a freenode server |
|
|
|
Have received my 2 Habanero boards. Tried to fit the Corsair H100i and it seems the 115x stand offs are too high. The CPU block has about 5mm of space to move up and down. The LGA2011 stand off did the trick but had to source 4 separate 4mm nuts to screw it down. Still to be tested. While I was sourcing the 4mm nuts, I also started setting up the XSPC Water Cooling Kit for the 2nd board. More pics can be found here: http://imgur.com/a/SMBJPWhile I have both boards ready with water coolers installed and powered up, I keep getting the following errors on cgminer: [2014-06-10 23:21:10] Hashfast detect (2:17) failed to initialise (incorrect device?)
[2014-06-10 23:21:15] USB init, open device failed, err -3, you don't have privilege to access - HFA device 2:17-i1 ha and it just occurred to me that I didn't run cgminer with sudo .. this may be the cause of my errors.. will attempt to run again later tonight after work. Silly me. Back to work i guess, QG Very nice, im curious to see what you can get out of the boards, just be gentle with them since the dies are fragile. One thing you mentioned is the cgm issue, its important to on unix boxes to follow the directions on the git depo search for the key word LINUX: on this page or follow these commands sudo usermod -G plugdev -a `whoami` If your distro doesnt have plugdev do this lastly its important to copy the cgminer udev rules over, once done its probably a good idea to reboot. sudo cp 01-cgminer.rules /etc/udev/rules.d/ after doing this you shouldn't have to run cgminer with sudo |
|
|
|
I made an update to this app, so if you have more than one board plugged into your host you have the ability to select which one to get the data from, see screen shot here.  You can grab the latest builds here here. Donations are welcome to continue app development! 15XLtKh5ziBqiaF1vAMiKRD5keqY8JSUJg |
|
|
|
I'd be careful about using this method. What you're basically doing is overwriting the default voltage stored on the flash of the device and then resetting it.
If you want to use it, we would suggest running it in the same way that you would use the python script; run it once to set the voltages, but don't run it as a normal part of your cgminer command line. I haven't tested it, but it should work great as a one-time setup you call when you want to tweak something, but don't call otherwise.
True.. |
|
|
|
I'll check for the test points tonight when I get back home and let you know the measurements results. I plan to push the change to con but I was thinking to clean it up a little before pushing it upstream. As it is right now it will brake any Sierra or any other Hashfast device with more than 4 dies ... Not that I'm thinking of it ... the easiest fix would be to enable this code only when device have 4 dies I'll fix that and push it to con today. True.. hmm you mean chained boards right? Also note that some dies fail, crack or what ever so we use the hf tool to disable a die because w/o doing this you cant mine and it spits our crazy errors. So a die#:0 is set to turn it off, this allows the board to continue hashing with 3 dies for example. Also prob should put some sort of limiting factor so someone doesn't put in a huge number, which im not sure what would happen but prob a few checks an balances.. or a --i-agree-to-use-this-expirmental-feature option |
|
|
|
Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool. The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments. Original syntax was "name:clock". Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax. Here are some exmaples of cgminer command line assuming board name "hab1": - select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV: cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0" - select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock): cgminer --hfa-options "hab1:950:970:970:970:980" - select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock): cgminer --hfa-options "hab1:950:970" Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cbLook like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv). It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event. Very nice ill test it out, we wernt 100% sure this could be done with the current firmware. Have you tested the points on the board to see if your getting that voltage out of them with a multimeter? So far I used the Pepper Mining App to check if voltage was same with hashfast python tool and with the updated cgminer. I can measure the voltage with a multimeter if you give me hints about good test points on the board for each die voltage. Where the chip is, on the edge of the board are a few test areas one for each die.. I forget the names off the top of my head. btw you should push this change to con to see if he accepts it.. cheers! |
|
|
|
Here is a first attempt to integrate into cgminer the voltage adjustment part from the python hashfast tool. The existing hfa-options that accept hash clock was expanded to accept per die voltage and per die clock adjustments. Original syntax was "name:clock". Expanded syntax is "name:clock:voltage_die0:voltage_die1:voltage_die2:voltage_die3:clock_offset_die0:clock_offset_die1:clock_offset_die2:clock_offset_die3" and it is backward compatible with original syntax. Here are some exmaples of cgminer command line assuming board name "hab1": - select hash clock of 950Mhz and voltage 970mV for all for dies 0, 2 and 3 and for die 1 use 900Mhz with 940mV: cgminer --hfa-options "hab1:950:970:940:970:970:0:-50:0:0" - select hash clock of 950Mhz and voltage 970mV for all 4 dies except last one that need 980mV (all dies use same 950Mhz clock): cgminer --hfa-options "hab1:950:970:970:970:980" - select hash clock of 950Mhz and voltage 970mV for all 4 dies using simplified command options (all dies use same 970mV voltage and same 950Mhz clock): cgminer --hfa-options "hab1:950:970" Full cgminer source code is available https://github.com/jaketri/cgminer.git and commit adding the voltage selection functionality is https://github.com/jaketri/cgminer/commit/4aed93156df9cc15f699f53ee9db03d99cafc1cbLook like the board need a reset after changing the voltage so you will see a board reset and a hotplug event on every cgminer startup if voltage is not default value (930mv). It would be greatly appreciated if anyone can help with a proper way to setup voltage before device detection to avoid the dead device follow by the hotplug event. Very nice ill test it out, we wernt 100% sure this could be done with the current firmware. Have you tested the points on the board to see if your getting that voltage out of them with a multimeter? |
|
|
|
|
Please send me a PM with the actual number of boards you want to order. I want to take a tally of how many people on the forum still want boards.
|
|
|
|
|
Show Posts
