NanoFury Project - Open Source Design

[loshia]

Loshia - just out of curiosity - can you give it a shot with the binary that I used during my initial development and testing? It is available at:
http://www.nanofury.com/cgminer-NanoFury-bin-2013-10-02.zip
It supports only one miner (and sometimes doesn't shut it off when you exit) but it would be interesting to see how that one compares. In my initial observations the same miners with bfgminer did a bit better... but it is also possible that just my initial coding was messy.

Window build  
Which one to use?

48-56?
can you post a screen shot of it?

[1713603182]

1713603182

[-ck]

Don't forget I always create drivers for cgminer that report hashrate based on real shares generated, not some arbitrary amount of hashes done (that doesn't translate into meaningful hashrate). I can happily make you a build that shows you making 2.5TH if you like. Make sure you check your pool to see how many effective shares you're submitting with your other drivers... People don't like the truth.

Forgive me CK, doesn't mean to offend you.

But i got 2 different error message.

They're real crashes. Could be somehow related to being on non-pc (which is the only thing I tested on).

Both of mine perform quite differently:

Code:

 NF1  0:                | 2.507G/2.499Gh/s | A:  62599 R: 1242 HW:    0 WU:  35.0/m
 NF1  1:                | 2.073G/2.068Gh/s | A:  57470 R:  648 HW:    0 WU:  29.0/m

Alas I'm travelling from tomorrow so I doubt I'll be able to do any debugging any time soon.

[rgr_rgr]

I also had a few crashes - core dump. Maybe because of weird system. Try to figure out on weekend.

System load seemed much lower with the version of main.

[loshia]

I also had a few crashes - core dump. Maybe because of weird system. Try to figure out on weekend.

System load seemed much lower with the version of main.

This is due to nonce checking. For sure Con version is doing it faster. I am sure that in new technoit release this will be tweaked also

[vs3]

Loshia - just out of curiosity - can you give it a shot with the binary that I used during my initial development and testing? It is available at:
http://www.nanofury.com/cgminer-NanoFury-bin-2013-10-02.zip
It supports only one miner (and sometimes doesn't shut it off when you exit) but it would be interesting to see how that one compares. In my initial observations the same miners with bfgminer did a bit better... but it is also possible that just my initial coding was messy.

Window build  
Which one to use?

48-56?
can you post a screen shot of it?

the 48-56 are the hard-coded speed bits. That's the same build I used during initial development - e.g. like in the screenshot here: https://bitcointalk.org/index.php?topic=291456.msg3280783#msg3280783

[utdrmac]

Success! Perfect! RaspberryPI Model B. 2 YellowJacket NanoFury's (powered hub required)! 2.2-2.5GHs each! No more 50% frequency errors!

Why doesn't master branch of cgminer have this patch included?

wget https://github.com/ckolivas/cgminer/archive/afe7710858e4ce28bb60f6ae6e167a18d687634f.zip
unzip cgminer-afe7710858e4ce28bb60f6ae6e167a18d687634f.zip
cd cgminer-afe7710858e4ce28bb60f6ae6e167a18d687634f/
wget http://technobit.eu/0_1_3.rar
unrar e 0_1_3.rar
patch -p1 <afe7710858e4ce28bb60f6ae6e167a18d687634f.patch
./autogen.sh --enable-hexmineru
make; sudo make install

[vs3]

Success! Perfect! RaspberryPI Model B. 2 YellowJacket NanoFury's (powered hub required)! 2.2-2.5GHs each! No more 50% frequency errors!

Why doesn't master branch of cgminer have this patch included?

wget https://github.com/ckolivas/cgminer/archive/afe7710858e4ce28bb60f6ae6e167a18d687634f.zip
unzip cgminer-afe7710858e4ce28bb60f6ae6e167a18d687634f.zip
cd cgminer-afe7710858e4ce28bb60f6ae6e167a18d687634f/
wget http://technobit.eu/0_1_3.rar
unrar e 0_1_3.rar
patch -p1 <afe7710858e4ce28bb60f6ae6e167a18d687634f.patch
./autogen.sh --enable-hexmineru
make; sudo make install

Congrats! :-)

By the way I think Con did incorporate exactly those changes into the mainstream cgminer (I think as of version 3.11 everything should be stable, he also added a speed override option)
Here is a link to the latest release - 3.12:

New version: 3.12.0, 29th January 2014

- Another even number, so it's gotta be stable!

Human readable changelog:

- Antminer U1 support
- Numerous fixes for behaviour surrounding USB errors - pipe and IO errors, and no more attempting to reset the device since it's rarely helpful and occasionally harmful.
- Libusb and libusbx have finally reconciled their differences and merged all their fixes together into a new official libusb release, so the main change in this version is updating the core code to include this latest libusb. Hopefully this might increase compatibility with some USB3 hubs on windows and make it more reliable (based on the changelogs I can see in libusb). This is the reason for the minor version number update to 12 as it's quite a substantial code change, hopefully only for the better!
- Increased the hashfast overheat limit default to 90 after extensive discussions with the engineers who designed the devices.
- Fixed a crash in the nanofury USB stick code.
- Fixed the displayed diff shown being wrong when solo mining.
- bab driver fixes courtesy of Kano.


Full changelog:

- Add support for AntminerU1 devices with the icarus driver.
- Add antminer U1 to comment in udev rules.
- Do away with usb resets entirely since we retry on both pipe and io errors now
and they're of dubious value.
- Retry on usb IO errors instead of faking success.
- Check that we've cleared the pipe error after a clear request, not the err
value which is unchanged.
- Update to libusb-1.0.18
- Change hfa overheat limit to 90 degrees.
- Relax timeout in hf get header to 500ms to match the usb timeout.
- Minion - check/clear interrupts for all chips
- Set info work to null after it is freed in nf1 after a restart to prevent
double free later.
- The second_run bool in libbitfury should be per device. Microoptimise its and
job_switched usage, removing the unused results array for NF1 devices.
- Fix displayed diff when solo mining at >2^32 diff.
- bab - stop stale work accumulating
- bab - set the default SPI speed back to 96000

[utdrmac]

By the way I think Con did incorporate exactly those changes into the mainstream cgminer (I think as of version 3.11 everything should be stable, he also added a speed override option)

Hrmm. I didn't see any references to this patch in the main branch, which is why I created my fork (https://github.com/utdrmac/cgminer). If I clone ckolivas's main branch, and compile, I have to use hidapi and I get hardware errors or I get no detection of NFY at all.

Using my fork, with the patch from technobit, there's no need for hidapi (known to be cumbersome with RPis), YellowJackets are detected, run more efficiently and produce 0 hardware errors.

[vs3]

By the way I think Con did incorporate exactly those changes into the mainstream cgminer (I think as of version 3.11 everything should be stable, he also added a speed override option)

Hrmm. I didn't see any references to this patch in the main branch, which is why I created my fork (https://github.com/utdrmac/cgminer). If I clone ckolivas's main branch, and compile, I have to use hidapi and I get hardware errors or I get no detection of NFY at all.

Using my fork, with the patch from technobit, there's no need for hidapi (known to be cumbersome with RPis), YellowJackets are detected, run more efficiently and produce 0 hardware errors.

Take a look here: https://github.com/ckolivas/cgminer/network
Go back to Jan/2 and follow the branch that Con split off at that time, and which branch got merged back into the trunk on Jan/8. That's when majority of the work was done.

Also, I suspect Con based his work mostly on the changes that Marto did (which were based on LukeJr's code who reworked to a significant extent my nf_spidevc.* library). The reason being is - Luke used the hidapi library (which was something inherited from my code) while Marto's version switched to libusb and that's what Con used. I don't know whether Con or Marto was first with libusb though - it might be that Marto has just shown the way to Con and he has redone the entire library himself.

I haven't done a diff to see what are the differences between Marto's version and Con's, but I suspect I'll find many common blocks of code
(which however might be just a coincidence as both of them used LukeJr's code as a base)

And just for the record - I would be a bit suspicious about the zero hardware errors. No bitfury chip (to the extent of my knowledge) has ever worked ideally flawlessly in that regard.

[Taugeran]

By the way I think Con did incorporate exactly those changes into the mainstream cgminer (I think as of version 3.11 everything should be stable, he also added a speed override option)

Hrmm. I didn't see any references to this patch in the main branch, which is why I created my fork (https://github.com/utdrmac/cgminer). If I clone ckolivas's main branch, and compile, I have to use hidapi and I get hardware errors or I get no detection of NFY at all.

Using my fork, with the patch from technobit, there's no need for hidapi (known to be cumbersome with RPis), YellowJackets are detected, run more efficiently and produce 0 hardware errors.

Take a look here: https://github.com/ckolivas/cgminer/network
Go back to Jan/2 and follow the branch that Con split off at that time, and which branch got merged back into the trunk on Jan/8. That's when majority of the work was done.

Also, I suspect Con based his work mostly on the changes that Marto did (which were based on LukeJr's code who reworked to a significant extent my nf_spidevc.* library). The reason being is - Luke used the hidapi library (which was something inherited from my code) while Marto's version switched to libusb and that's what Con used. I don't know whether Con or Marto was first with libusb though - it might be that Marto has just shown the way to Con and he has redone the entire library himself.

I haven't done a diff to see what are the differences between Marto's version and Con's, but I suspect I'll find many common blocks of code
(which however might be just a coincidence as both of them used LukeJr's code as a base)

And just for the record - I would be a bit suspicious about the zero hardware errors. No bitfury chip (to the extent of my knowledge) has ever worked ideally flawlessly in that regard.

i might have 1 "flawless" at least at 54 bits. been running for over 1.5 weeks with no hw errors. this would mean its been through 2.091 × 10^15 hashes in that time period at 2.2 Gh/s which i would think is enough for a hit on each of the 756 cores.


and now i have to wonder why Bitfury chose 756 instead of a full 1024. silicon die sizing constraints?

[rgr_rgr]

Concerning diffs between Martos and Cons Code:
I have several NF, working without any problems with both versions. But one NF doesn't work with cgminer 3.12.0 (and before). It workes with Martos Patch and bfgminer as well.
It doesn't bother me but it shows there are differences between the patch and main.

[erk]

My NF1 crashes on cgminer 3.10, 3.11, usually when there is a stratum disconnect. Rock solid on bfgminer.

[rgr_rgr]

This bug is fixed in 3.12.0. It wasn't in Martos Patch either.

bfgminer rock solid? No frequency drops there anymore?

[vs3]

Looking at stuff like that just makes me proud with my Nanos

http://blockchain.info/tx-index/c5d213962751b47ac02130ff175fe67d4e41350475f0388d7252a8f1495fa568

Purchasing 8 please! ~$112.8 per unit, plus shipping. Very much looking forward to receiving them.

UPDATE
One unit received and loaded up:


16 Yellowjackets... mmm...


All overclocked to 54 oscillator bits, there don't seem to be any power-related error messages; it seems rock solid

Very happy, can't wait to get the rest!

[vs3]

Ah - a very good explanation and details for a question that seems to crop up quite often - the "how many of those can I plug to my USB hubs" one:

How many logical hubs is it?

(For example, a typical 7-port hub is two logical four-port hubs, with hub #2 "plugged" into a port of hub #1, leaving seven open ports for the user.)

Reason I'm asking is, the Raspberry Pi can have issues with this hub if there are too many logical hubs inside it.

I think they are three logical seven-port hubs. So each hub used counts as 21 usb ports with 19 usuable. Razorfish correct me if i am wrong here!

The hub is 19 external USB ports , 3 are level 1, 16 are level 2… that is all we need to care about… for expansion hubs plug the shit into the side.


This is something I have been  HARPING on for over a YEAR on the forums and WHY the Pi is NFG for large installations.

Most of these shitty little 'cutter' SBC's have major problems with the USB… then add into this equation SHITTY hubs.

Nearly everyone knows about the 126 USB device limit per Physical controller, but what is not often discussed it the level limitation.
'Theoretically' a usb chain can be nested to upto 5 levels.

 I.E

Controller+Hub+hub+hub+hub.
Now here is the rub… inside the silicon of the SBC or sometimes on the PCB is a hub chip (NOT for users)…, because these SBC devices CHAIN the  ethernet/bluetooth or other I/O internally off the USB protocol, just the manufacturers don't tell you directly….

So what they do is 'hide' as many as TWO logical USB hubs INSIDE the SBC (Huba Huba), BUT then Chain them off each other and into a SINGLE silicon port……,
The reason why they hide two, is because as soon a you plug a slow device into a chain then the WHOLE chain is that speed(new smarter hub chips can act as translators without destroying the speed of the whole chain as long as there is a clear path at 480Mb/s).

The net effect of this SBC hand job is that straightway the 5 levels become 3 or less!!!, which is basically enough for 1 extra 10 port hub (because 1 chip HAS to be chained off another one and hence the problems with the PI, if you are lucky you plug the other hubs into the  FIRST chip in the chain then you get a second level, if not they get plugged into the second chip and go out of range)

Coming back to the metal hub:
if you use the 3 side connectors, then it is one level ,
if you use the top, then it is basically 2 levels apart from 2 top ports where it is 1.(work it out!! )

So… if you buy 4 metal hubs

you plug your computer into one of the hubs via the 'B' type connector and then you plug the other THREE hubs into the side connectors of that ONE hub, UNLESS your computer has more than 1 port, in which case you use ALL the connectors on the computer first.

DO NOT build up a single chain of 1:1:1:1 and think it is cooler and faster, because it is not.
USB is a TREE structure and no tree has all the branches on a single limb (consider the controller as the TRUNK, notice how mother nature has ALL this 'effective distribution' shit already worked out!!!).


These metal hubs I PERSONALLY have had a full device chain of nearly 126 devices, the miner count reached ~104 devices, the rest was hub chips………
But NOTE, the miner performance is less with an SBC than a 'real computer', I suspect it is due to kernel task switching.


Next up……..
Realtek, yep you see they make all sorts of USB silicon…. In fact they developed a shit load of silicon when USB 1.0 came out, and since silicon development is expensive, when USB 2.0 came out they took a silicon 'wrapper' that runs USB2.0, but then the internal cores of their chips are USB 1.0…., their chips are mostly used in cheap crap hubs from China.

BUT they all advertise the products as USB 2.0 compatible with 1.0, because the silicon wrapper is good to USB2.0 standard (which Is compatible with 1.0) ,but the actual internal core silicon communicates at 12mb/s or SLOWER!!!.
Same with their Ethernet to USB chips, the whole core runs at USB1.0, which is ironic because the Ethernet is '100/10 compatible' but it is bottlenecked because it is running at USB1.0 speeds internally!!!!
(bit like some old lady driving her battery powered trike in a 45MPH zone, because it is 'road worthy' but holding up all the traffic behind her)

Needless to say Microsoft was involved in this…..

[bigbeninlondon]

So where are these for sale at reasonable prices now?

[Swimmer63]

So where are these for sale at reasonable prices now?

I have a few for sale but they run under the standard speed.  I have sold all my others and these are the leftovers from my batch of 110.
At the default 50 bits they range between 1.5 Gh/s to 1.75 Gh/s.
Overclocked at 54 bits they all run over 2.0 Gh/s and the faster ones run about 2.5 Gh/s.
I have about 8 of them and they run between $55-$70 depending on the speed.  Delivery is additional.

PM me if interested.

[-ck]

By the way I think Con did incorporate exactly those changes into the mainstream cgminer (I think as of version 3.11 everything should be stable, he also added a speed override option)

Hrmm. I didn't see any references to this patch in the main branch, which is why I created my fork (https://github.com/utdrmac/cgminer). If I clone ckolivas's main branch, and compile, I have to use hidapi and I get hardware errors or I get no detection of NFY at all.

Using my fork, with the patch from technobit, there's no need for hidapi (known to be cumbersome with RPis), YellowJackets are detected, run more efficiently and produce 0 hardware errors.

Excuse me? I'll give you the benefit of the doubt and assume you're mixing up my code with something else. There's no code in the master cgminer code that uses hidapi, nor was there any code that used it. It only uses libusb directly which is included in the cgminer source, for that is the driver model for all usb devices in cgminer.

[loshia]

For sure Technobit reworked Luke vs3 hidapi implementation to libusb and this is noted inside their code.
Peace.

[bigbeninlondon]

So where are these for sale at reasonable prices now?

I have a few for sale but they run under the standard speed.  I have sold all my others and these are the leftovers from my batch of 110.
At the default 50 bits they range between 1.5 Gh/s to 1.75 Gh/s.
Overclocked at 54 bits they all run over 2.0 Gh/s and the faster ones run about 2.5 Gh/s.
I have about 8 of them and they run between $55-$70 depending on the speed.  Delivery is additional.

PM me if interested.

$55-$70 is a bit steep, especially if they are under standard speed.  I was hoping $25 to $30, expected $40 or so. 

Is there nowhere I can get $10/gigahash?  That's the only price that makes any modicum of sense right now.