Hashfast Open Source Interface Protocol

[fubly]

The documentation found here:
https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdf

Information source:

https://hashfast.com/golden-nonce-interface-protocol-released/

Introducing The Global Work Queue.

HashFast aims to make mining easier and more efficient – a necessity when building and using terrahash mining systems. HashFast is also dedicated to supporting the open source community.

Going forward it is clear that the less work the miner has to do to get devices working the better. What the miner apps should be doing is deriving work (from a Stratum server), pushing that work out to devices, and getting back nonces and device status. Managing individual cores in every die/ASIC in a 6 foot rack is just not sensible. Devices themselves should do the grunt work, leaving the mining app to do what it does best.

We had an opportunity to do this – because (a) we had already built advanced mechanisms in our serial protocol that allow work multiplication and dispersal – group and multicast mechanisms, ntime rolling etc., and (b) our USB interface has programming capability. As such, we are able to offer three interface mechanisms:

1.  ASIC serial – useful for vendors who wish to make their own boards and interface means to the ASIC

2.  USB mapped serial – USB interface but all of the low level serial protocols available, data CRC not required/present

3.  USB Global Work Queue – A higher level interface that just involves work flow to the device and nonce flows back to host

The driver for CGminer (to be published on github soon) will use the Global Work Queue.

Today, we are releasing our interface protocol document that describes these three mechanisms, and more.

There are no fundamental protocol changes to use the Global Work Queue protocol. Drivers using the USB interface simply nominate this as the protocol they wish to use, and they direct OP_HASH operations to a virtual ASIC at address 254. (255 is the broadcast address). A simple sequence numbering system tells the driver when it may send work and when to stop. All it gets back is a nonce stream, and if it asks for it, periodic status/monitoring data which will contain a lot of information about voltages, temperatures, fans etc. and that data will wind up in the miner’s API. The driver doesn’t need to know how many cores or chips are out there.

A side effect of using a higher level interface is that the driver becomes straightforward. Instead of thousands of lines of complex low level code, there will be just a few hundred lines of simple high level stuff to deal with.

Needless to say, we are excited to release this 84-page engineering document to the world, and to present it to the open source development community .

Download the document gn_protocol.
https://hashfast.com/wp-content/uploads/2013/10/gn_protocol.pdf

Check back here for more news on the driver header files (coming soon).

[gmaxwell]

Hm. Is there a way to replace pending work without potentially producing a pipeline stall?

E.g. is a RESET of the pending work followed by new work guaranteed to either successfully replace the work, or provide the next work, without ever halting processing?

For longpolling for transaction updates (or for P2Pool sharechain motion) you want them to happen as fast as possible, but not at the expense of stalling the pipeline (because the work is still useful).

For longpolling for chain motion, you also want to switch as fast as possible, but a stall is irrelevant since the work is actually useful (and stalling can be beneficial if it saves power over just waiting for the stale work to finish). 

[HashFast_CL]

Hm. Is there a way to replace pending work without potentially producing a pipeline stall?

E.g. is a RESET of the pending work followed by new work guaranteed to either successfully replace the work, or provide the next work, without ever halting processing?

For longpolling for transaction updates (or for P2Pool sharechain motion) you want them to happen as fast as possible, but not at the expense of stalling the pipeline (because the work is still useful).

For longpolling for chain motion, you also want to switch as fast as possible, but a stall is irrelevant since the work is actually useful (and stalling can be beneficial if it saves power over just waiting for the stale work to finish). 

Relevant?

Finally, there is no motivation to shortening the nonce range in order to drop work time down
to fractions of a second, because HashFast products allow work to be aborted, and in
particular with the GWQ protocol, the OP_WORK_RESTART mechanism provides a built in
command to seamlessly abort all work in progress and replace it with new work based on a
new coin base, as often as required and with negligible hashing downtime

OP_WORK_RESTART = awesome.   The problem with many ASICs and p2pool is that p2pool generates "new" work on a short interval (about 30 sec between reward chain blocks).  Without a OP_WORK_RESTART or something similar an ASIC will continue using "stale" work for a significant fraction of a second (or even multiple seconds).   On Bitcoin network (600 sec average time between blocks) losing say 0.6 seconds to "stale work" means 0.1% stale shares but on p2pool with 30s average it is more like 2% ouch.  This is in addition to other forms of stale shares due to network latency. 

The ability to abort all work rapidly to all cores and supply new work should result in GN doing good things on p2pool.