gateway (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2014, 05:11:37 AM Last edit: June 05, 2014, 09:53:03 PM by gateway |
|
Hey everyone we are able to release a tool that allows you to adjust your voltage settings for your Evo and Habanero boards. HF has provided us with a python 3 script that we are allowed to distribute. Basically in a nutshell this is good to use ONLY if your trying to push your boards past 900Mhz because you will need to increase the voltage on the board in order to give the chip more power. USE AT YOUR OWN RISK, please read the LICENSE FILE first before using this tool. This only works with one miner plugged in at a time!
The hftool.py utility is used to query and manipulate hashfast module settings. Requirements: Python 3.x pip for Python 3.x Pyusb Installing pip for python 3 on most unix systems (command for ubuntu below) sudo apt-get install python3-pip hftool requires pyusb. To install it: pip3 install --pre pyusb Put these into a file /etc/udev/rules.d/01-hashfast.rules: You will need root access to create this file and also when done its recommended you reboot in order for these rules to take effect. ATTRS{idVendor}=="297c", ATTRS{idProduct}=="0001", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev”, ENV{ID_MM_DEVICE_IGNORE}="1" ATTRS{idVendor}=="297c", ATTRS{idProduct}=="8001", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", ENV{ID_MM_DEVICE_IGNORE}="1" ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2ff6", SUBSYSTEMS=="usb", ACTION=="add", MODE="0660", GROUP="plugdev", ENV{ID_MM_DEVICE_IGNORE}="1" RUNNING Start the tool by with: Read die frequencies and voltages: Write die frequencies and settings: $ ./hftool.py -w 0:VLT@FRQ,1:VLT@FRQ,2:VLT@FRQ,3:VLT@FRQ example would be setting all dies to .930 volts at 875Mhz $ ./hftool.py -w 0:930@875,1:930@875,2:930@875,3:930@875 You can grab it from Bitbucket Git depo here https://bitbucket.org/gateway69/hf-toolAND no I dont work for HF, we pushed them to get a tool released so our customers of our Habanero boards could tweak and push their boards. Order your Habanero from Batch 2 today for $850 here
|
|
|
|
xjack
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2014, 06:09:17 PM Last edit: June 07, 2014, 12:36:22 AM by xjack |
|
Just wanted to throw this out. There is no Python 3 package of pip for Ubuntu 12.04 LTS. So I installed this way...
sudo apt-get install python3-setuptools sudo easy_install3 pip
Got it installed but can't test it remotely since it crashes with two miners connected. Will report back later.
edit: See post below.
|
|
|
|
gateway (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2014, 09:52:23 PM |
|
Oh, yea I should mention only use this with one miner plugged in at a time
|
|
|
|
xjack
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 06, 2014, 03:47:50 AM |
|
Any thoughts on this error? I'm getting it on 12.04 LTS, and Debian 7.4 on the beaglebone black. Stumped. jack@jack-nT-A3000-series:~/hf-tool$ ./hftool.py -r HFBulkDevice Found! ConfigurationValue 1 InterfaceNumber 0,0 EndpointAddress 131 InterfaceNumber 1,1 EndpointAddress 129 EndpointAddress 2
EndpointAddress for writing 2 EndpointAddress for reading 129
Generic exception handler: (<class 'AttributeError'>, 'list' object has no attribute 'copy', <traceback object at 0x15c6f80>) Traceback (most recent call last): File "/home/jack/hf-tool/hf/load/routines/settings.py", line 50, in one_cycle self.transmitter.send([]) File "/home/jack/hf-tool/hf/load/hf.py", line 83, in send mybyteslist = byteslist.copy() AttributeError: 'list' object has no attribute 'copy'
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File "./hftool.py", line 67, in <module> main(sys.argv[1:]) File "./hftool.py", line 55, in main while setter.one_cycle(): File "/home/jack/hf-tool/hf/load/routines/settings.py", line 129, in one_cycle self.end() File "/home/jack/hf-tool/hf/load/routines/base.py", line 304, in end self.transmitter.send(op_usb_shutdown.framebytes) File "/home/jack/hf-tool/hf/load/hf.py", line 83, in send mybyteslist = byteslist.copy() AttributeError: 'list' object has no attribute 'copy'
|
|
|
|
jimmychopps
Newbie
Offline
Activity: 8
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 06, 2014, 09:52:07 AM |
|
Getting the same error when I try to read current freq and voltages.
|
|
|
|
gateway (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 06, 2014, 06:19:17 PM |
|
First of all our dev boxes are running ubuntu desktop 13.04 or .10 64 bit .. so if you have an image of that try that out. secondly, their are a few things to check since this requires python 3 and the running python by default is usually 2.7 or something close not 3 netcom@chromy2:~/Documents/firmware/tools$ python --version Python 2.7.5+ netcom@chromy2:~/Documents/firmware/tools$ python3 --version Python 3.3.2+
so u need some flavor or python 3... You could try running the command like so.. Please make sure you also have pip3 and pyusb installed for python 3.
|
|
|
|
xjack
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 06, 2014, 07:32:25 PM |
|
Got it working on 12.04 LTS... sudo apt-get install build-essential libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev
Then install the python3 from source code:
wget https://www.python.org/ftp/python/3.4.0/Python-3.4.0.tar.xz tar xvf Python-3.4.0.tar.xz cd Python-3.4.0 ./configure make make test sudo make install
sudo pip3.4 install --pre pyusb (or sudo pip3.4 install pyusb I can't remember now)
python3.4 hftool.py -r
|
|
|
|
gateway (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 06, 2014, 07:38:13 PM |
|
Got it working on 12.04 LTS... sudo apt-get install build-essential libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev
Then install the python3 from source code:
wget https://www.python.org/ftp/python/3.4.0/Python-3.4.0.tar.xz tar xvf Python-3.4.0.tar.xz cd Python-3.4.0 ./configure make make test sudo make install
sudo pip3.4 install --pre pyusb (or sudo pip3.4 install pyusb I can't remember now)
python3.4 hftool.py -r
awesome good news.. prob should start a little faq for various linux versions.. btw not sure if you need these.. libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev
|
|
|
|
xjack
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 06, 2014, 07:50:20 PM |
|
awesome good news.. prob should start a little faq for various linux versions.. btw not sure if you need these.. libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev I blindly followed a guide from Stackoverflow. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
|
xjack
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 06, 2014, 11:26:26 PM Last edit: June 07, 2014, 04:07:14 PM by xjack |
|
Still tweaking board #2
Board #1 has all dies at .975v/950MHzBoth boards hashing stable with .975/950MHz settings. (clocking at 925MHz) cgminer version 4.3.4 - Started: [2014-06-06 22:50:16] ---------------------------------------------------------------------------------------------------- (5s):1.136T (1m):1.290T (5m):1.371T (15m):1.396T (avg):1.404Th/s A:14260992 R:44032 HW:3972 WU:19617.1/m | ST: 176 SS: 0 NB: 75 LW: 14958907 GF: 0 RF: 0 Connected to xxxxxxxx 1.02K with stratum as user xxxxx Block: c0e29fcd... Diff:11.8G Started: [11:05:05] Best share: 18.4M ---------------------------------------------------------------------------------------------------- [U]SB management [P]ool management [S]ettings [D]isplay options [Q]uit 0: HFB Dabs : 925MHz 99C 100% 0.90V | 722.1G / 700.6Gh/s WU: 9787.2/m A:7135104 R:28160 HW:2104 1: HFB Chip : 925MHz 101C 100% 0.90V | 569.0G / 703.6Gh/s WU: 9829.9/m A:7125888 R:15872 HW:1868 ---------------------------------------------------------------------------------------------------- [2014-06-07 11:05:15] Accepted 0acf8627 Diff 6.06K/1024 HFB 0 pool 0 [2014-06-07 11:05:15] Accepted 01a3e358 Diff 40K/1024 HFB 0 pool 0 [2014-06-07 11:05:18] Accepted 16f68815 Diff 2.85K/1024 HFB 0 pool 0 [2014-06-07 11:05:18] Accepted 28e32c95 Diff 410K/1024 HFB 1 pool 0 [2014-06-07 11:05:32] Accepted 20eb99a9 Diff 1.99K/1024 HFB 1 pool 0 [2014-06-07 11:05:34] Accepted 297d0612 Diff 1.58K/1024 HFB 0 pool 0
Just awesome - thanks Peppermining! YMMV.
|
|
|
|
xjack
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 07, 2014, 03:23:49 PM |
|
Good guide for getting your Habanero "close" to target speeds. Frequency | Hashrate | Voltage Setpoint | Board Power (W[DC]) | Efficiency (J/GH) | 925 | 704 | 0.97 | 783.0 | 1.11 | 900 | 685 | 0.95 | 727.9 | 1.06 | 875 | 666 | 0.935 | 682.5 | 1.02 | 850 | 647 | 0.92 | 636.0 | 0.98 | 825 | 628 | 0.91 | 598.4 | 0.95 | 800 | 609 | 0.89 | 559.1 | 0.92 | 775 | 589 | 0.88 | 528.8 | 0.90 | 750 | 570 | 0.87 | 498.7 | 0.87 |
Test notes -Single board prototype tested, not a production unit -Power measurements are DC at the board input -Coarse-grained voltage optimization was used, no attempt to individually optimize each die was made For the picture of the board with the heatsink, I can't provide that yet. Next week.
|
|
|
|
JakeTri
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 10, 2014, 12:15:11 PM |
|
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.
|
BTC donations always welcome: 1JakeTriwbahMYp1rSfJbTn7Afd1w62p2q
|
|
|
gateway (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 10, 2014, 06:11:42 PM |
|
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?
|
|
|
|
JakeTri
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 10, 2014, 06:40:32 PM |
|
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.
|
BTC donations always welcome: 1JakeTriwbahMYp1rSfJbTn7Afd1w62p2q
|
|
|
gateway (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 10, 2014, 06:52:43 PM |
|
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!
|
|
|
|
JakeTri
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 10, 2014, 07:01:27 PM |
|
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! 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) I'll fix that and push it to con today.
|
BTC donations always welcome: 1JakeTriwbahMYp1rSfJbTn7Afd1w62p2q
|
|
|
gateway (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 10, 2014, 07:09:11 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
MrTeal
Legendary
Offline
Activity: 1274
Merit: 1004
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 10, 2014, 07:39:17 PM |
|
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.
|
|
|
|
gateway (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 10, 2014, 07:50:45 PM |
|
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..
|
|
|
|
|