Bitburner Fury, getting roughly 52~54 gh/s.
I see . I was dreaming for nanofury to work on Pi with cgminer
|
|
|
Hi Marto, could i choose to ship with DHL? UPS is too expensive You can always choose pick up option and send DHL to collect your sending Hmm, i need to ask DHL in my country if they can do pickup on other country tomorrow. Thanks marto Hi marto, it's seem DHL ask for frequent shipping for me to be able use their import tool. I hope you could add DHL shipping options in order page if possible
|
|
|
Hi Marto, could i choose to ship with DHL? UPS is too expensive You can always choose pick up option and send DHL to collect your sending Hmm, i need to ask DHL in my country if they can do pickup on other country tomorrow. Thanks marto
|
|
|
Hi Marto, could i choose to ship with DHL? UPS is too expensive
|
|
|
Got the Fury working with 3.8.3 and now getting nearly 2 gh/s more per device. That's nice. Which fury did you use?
|
|
|
Hi marto, Could you publish cgminer patch 3.8.2 rev 0ed1828bd47282218c2bb130fd03737ed2c51a5e.patch ? Thanks
|
|
|
And no more OFF boards or at least less often Really hope nanofury to work on TL-MR3020 or Pi Marto, i believe you & your team can make it work.
|
|
|
New TP-LINK TL-MR3020 image & cgminer patch is available. Link : 0.1.00.1.0:
* cgminer Bugfix – detecting HEX boards + memory corruption * cgminer NEW – Auto detect miners in case of usb errors during detection --set_default_to_a, --set_default_to_b and --set_default_to_c. The default is hexA – all boards will be detected as Avalon1 * cgminer updated to 3.8.3 rev 7ddb94d6964f2451d2e76f70b069dfdf2b3d4d6f * cgminer patch to cgminer 3.8.3 rev 7ddb94d6964f2451d2e76f70b069dfdf2b3d4d6f.patch - various code cleanup and optimization needs to be done * cgminer pending work to implement nanofury support * openwrt Web – added config for Auto detect option * openwrt updated to r38917
todo
* finish cgminer nanofury support * add cgminer monitor script - done * stay in sync with official cgminer git and build fresh openwrt images - synced * add auto frequency adjustment support avalon-auto style - canceled * add configuration options (voltage and clock) per board based on HEX16A serial number - canceled
HEX16A(Avalon1): Best results 7.4-7.7 Gh/s (16 chips) in terms of stability and clocking are observed at 1460mV core voltage + 480 MHz Clock.
HEX16B(Bitfury): Best results 44.5-45 Gh/s (16 chips) in terms of stability and clocking are observed at 900mV core voltage + 540 Clock. Do not go above 540 it is not working!
HEX16C(Avalon2): To be tested with 10 chips - 1100mV core voltage + 1500 MHz Clock.
|
|
|
New TP-LINK TL-MR3020 image & cgminer patch is available. Link : 0.1.00.1.0:
* cgminer Bugfix – detecting HEX boards + memory corruption * cgminer NEW – Auto detect miners in case of usb errors during detection --set_default_to_a, --set_default_to_b and --set_default_to_c. The default is hexA – all boards will be detected as Avalon1 * cgminer updated to 3.8.3 rev 7ddb94d6964f2451d2e76f70b069dfdf2b3d4d6f * cgminer patch to cgminer 3.8.3 rev 7ddb94d6964f2451d2e76f70b069dfdf2b3d4d6f.patch - various code cleanup and optimization needs to be done * cgminer pending work to implement nanofury support * openwrt Web – added config for Auto detect option * openwrt updated to r38917
todo
* finish cgminer nanofury support * add cgminer monitor script - done * stay in sync with official cgminer git and build fresh openwrt images - synced * add auto frequency adjustment support avalon-auto style - canceled * add configuration options (voltage and clock) per board based on HEX16A serial number - canceled
HEX16A(Avalon1): Best results 7.4-7.7 Gh/s (16 chips) in terms of stability and clocking are observed at 1460mV core voltage + 480 MHz Clock.
HEX16B(Bitfury): Best results 44.5-45 Gh/s (16 chips) in terms of stability and clocking are observed at 900mV core voltage + 540 Clock. Do not go above 540 it is not working!
HEX16C(Avalon2): To be tested with 10 chips - 1100mV core voltage + 1500 MHz Clock.
|
|
|
New TP-LINK TL-MR3020 image & cgminer patch is available. Link : 0.1.00.1.0:
* cgminer Bugfix – detecting HEX boards + memory corruption * cgminer NEW – Auto detect miners in case of usb errors during detection --set_default_to_a, --set_default_to_b and --set_default_to_c. The default is hexA – all boards will be detected as Avalon1 * cgminer updated to 3.8.3 rev 7ddb94d6964f2451d2e76f70b069dfdf2b3d4d6f * cgminer patch to cgminer 3.8.3 rev 7ddb94d6964f2451d2e76f70b069dfdf2b3d4d6f.patch - various code cleanup and optimization needs to be done * cgminer pending work to implement nanofury support * openwrt Web – added config for Auto detect option * openwrt updated to r38917
todo
* finish cgminer nanofury support * add cgminer monitor script - done * stay in sync with official cgminer git and build fresh openwrt images - synced * add auto frequency adjustment support avalon-auto style - canceled * add configuration options (voltage and clock) per board based on HEX16A serial number - canceled
HEX16A(Avalon1): Best results 7.4-7.7 Gh/s (16 chips) in terms of stability and clocking are observed at 1460mV core voltage + 480 MHz Clock.
HEX16B(Bitfury): Best results 44.5-45 Gh/s (16 chips) in terms of stability and clocking are observed at 900mV core voltage + 540 Clock. Do not go above 540 it is not working!
HEX16C(Avalon2): To be tested with 10 chips - 1100mV core voltage + 1500 MHz Clock.
|
|
|
i can't get my raspberry to even recognize the DUB-H7 that i have, but it will recognize regular devices
I remember my Pi not recognize DUB-H7 on lower usb port but work fine in upper usb port. This is nut, what is the differences. Ok, i give up running nanofury on Pi. Just lets it burn on Windows.
|
|
|
This is interesting since i am linux noob. I see new command there because i use command that 2GOOD post to compile. Since my pi not doing anything because HEX16A hashing with TL-MR3020, so i try new thing today. I try to apply 2e9afa38e39678a5dc5bf8be6d20baf1849b548c.patch to cgminer-3.8.3 LOL. Don't laugh, of course it's not work. But the funnies is after that, i can't run sudo reboot or sudo poweroff
|
|
|
Stupid question I just freed up a usb port on my hub is there any more available? or was there another thread?
Technobit NanoFury
|
|
|
Marto, you forget to upload 3.8.2 rev 0ed1828bd47282218c2bb130fd03737ed2c51a5e.patch cgminer 3.8.3 already release
|
|
|
All is good That is due to hotplug USB disconnect / reconnect events. In old versions they were hidden. Keep mining and do not pay attention to it:) In old versions OFF line was not shown Check dmesg or logread and you will see when USB was disconnected reconnected. Best PS: If you are in doubt please do your paid hash rate calc as suggested by kano https://bitcointalk.org/index.php?topic=170332.msg3358609#msg3358609An you will see that all is good I see, thanks loshia
|
|
|
After run for 2 days, something happen with rev 0.0.7. I only had 2 HEX16A.
|
|
|
How do you know the hidapi driver even works on a Pi? I would be surprised if it did without modifications.
That's the problem, it's didn't work
|
|
|
Assuming you are using Debian and the files are in the same place.
cd /usr/local/lib
rm -i *hidraw*
The only reason I removed them was I can't be bothered install installing the kernel source, setting the zillion options, and recompiling with hidraw enabled.
Thanks erk. But it's seem with pi, it's more complicated.
|
|
|
/EDIT nvm I deleted all the hidraw libs, ran another ldconfig and it found the device with libusb it's mining now at about 2.1GH/s with standard defaults.
Thanks.
Hi erk, please tell me how to delete the hidraw lib? step by step since i am new to linux
|
|
|
Anyone had luck with Raspberry Pi wheezy?
I bought a RasPi last week and am waiting for it to arrive .. as soon as I get it I'll give it a shot too. No promises though - I'm not sure if the hidapi is compatible with it at all or what is the nature of the issue.. Great, i am looking for it
|
|
|
|