Bitcoin Forum
December 07, 2016, 10:31:52 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 »
  Print  
Author Topic: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards  (Read 174157 times)
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
March 06, 2012, 09:39:29 AM
 #361

There are 3 options now:
  • Keep the ztex module as a community-maintained worker module (and hope nelisky will keep maintaining it)
  • Make it an official 3rd party worker module (maintained by ztex)
  • Make it a core MPBM module (maintained by me (I might need a board for that), and shipped with the official MPBM package)

For me there is no reason to participate in development of some kind of software that does the same as BTCMiner. I will only support your software in frame of the OS discount program, see  http://www.ztex.de/os_discount_program.e.html for the conditions.

This is probably a matter of personal preference, but from my perspective it might even make sense to drop BTCMiner completely at some point, and instead focus on providing a standardized interface, that any miner software can plug into, just like it works for GPUs.

But for now this basically boils down to: If I get a board, I will maintain it. If not, I can't.

There is even a con:  ZTEX FPGA boards allow frequency scaling. Improper use of this feature may cause damage. This is mainly a warranty issue. (For that reason logging will become mandatory in the next BTCMiner release.)

Sure, but that issue just can't really be avoided. The only thing that helps here is designing that feature to be at least mostly bullet proof. Doing it in the µC firmware (at least by default, if possible with thermal or current monitoring) could help as well.

Quote
@ztex: btw, does the USB core used in that cypress chip support interrupt endpoints? I'd really like to get rid of polling...

Interrupt transfers are supported by the SDK. But they (as any USB transfers) are initiated by the host, i.e. they do not avoid polling. Interrupt transfers only guarantee a certain latency.

They do, however, offload the polling work to the USB host controller hardware. Currently there's a major CPU hit from that.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481149912
Hero Member
*
Offline Offline

Posts: 1481149912

View Profile Personal Message (Offline)

Ignore
1481149912
Reply with quote  #2

1481149912
Report to moderator
1481149912
Hero Member
*
Offline Offline

Posts: 1481149912

View Profile Personal Message (Offline)

Ignore
1481149912
Reply with quote  #2

1481149912
Report to moderator
1481149912
Hero Member
*
Offline Offline

Posts: 1481149912

View Profile Personal Message (Offline)

Ignore
1481149912
Reply with quote  #2

1481149912
Report to moderator
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
March 06, 2012, 10:37:42 AM
 #362

Is there a way to stop the FPGA from mining without forcing a reconfigure to get it going again? The use case being many boards loosing network connectivity which will make them go round and round on the same data while waiting for new work, which is wasted electricity.
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
March 06, 2012, 10:43:05 AM
 #363

They do, however, offload the polling work to the USB host controller hardware. Currently there's a major CPU hit from that.

While that is true, and I guess it would be simple enough to add an interrupt transfer to signal the existence of a golden nonce to process, you would stop fetching the error rate data which, I believe, isn't something you could easily handle on the uC. And since we ztex boards allow for user controlled frequency scaling, this data is VERY important.
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
March 06, 2012, 02:13:51 PM
 #364

They do, however, offload the polling work to the USB host controller hardware. Currently there's a major CPU hit from that.

While that is true, and I guess it would be simple enough to add an interrupt transfer to signal the existence of a golden nonce to process, you would stop fetching the error rate data which, I believe, isn't something you could easily handle on the uC. And since we ztex boards allow for user controlled frequency scaling, this data is VERY important.

Isn't the error rate calculated by looking at the shares that the µC uploads to the PC? Or is there some more sophisticated self-testing mechanism on the FPGA?

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
March 06, 2012, 02:47:29 PM
 #365

Every time you poll ztex board you get 2 x nonce and 2 x goldennonce. The latter is when there's a diff=1 share found and the former is just the last calculated nonce (twice because ztex uses 2 hashers in parallel, I believe).

I don't know why as it's been a while since I had to tinker with the sha256 algo, but hash(nonce)[28:32] == H7+0x5be0cd19 if the hasher is doing its thing. Ztex can set me straight if I'm full of it right now Smiley

But regardless, in a nutshell you get nonces to verify at every read, but the board verifies and stores the golden nonces itself. I am assuming that going the interrupt transfer route you would only be interested in getting transfers in the event of a golden nonce, making the error rate resolution much smaller and potentially harmful to the board.

If, on the other hand, you would get interrupt transfers for every nonce calculated... well, nothing gained from current approach, right?

I might have gotten this all wrong, so feel free to call bs.
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
March 06, 2012, 05:33:06 PM
 #366

Hm, something like that makes very much sense, but should probably be done at the firmware level. That way some kind of thermal runaway trap could be implemented on the board itself, mitigating at least some of the third party miner warranty issues. It would also reduce host to board traffic and miner CPU time a lot.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
March 07, 2012, 09:04:22 AM
 #367

They do, however, offload the polling work to the USB host controller hardware. Currently there's a major CPU hit from that.

Even in larger clusters (50+) the CPU usage of BTCMiner during normal operation is almost zero. There has to be another reason (than the kind of used USB transfers).


ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
March 07, 2012, 09:06:12 AM
 #368

Is there a way to stop the FPGA from mining without forcing a reconfigure to get it going again? The use case being many boards loosing network connectivity which will make them go round and round on the same data while waiting for new work, which is wasted electricity.

Already implemented: after about 5 minutes of inactivity the FPGA board enters a low power state. This is implemented in firmware,

But due to the support of backup servers this feature shouldn't be used much.


ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
March 07, 2012, 09:09:28 AM
 #369

Isn't the error rate calculated by looking at the shares that the µC uploads to the PC? Or is there some more sophisticated self-testing mechanism on the FPGA?

Error rate is measured by verification of the latest hash value. Error rate measurement based on shares would be inaccurate / slow  because in average there would be only one measurement every 20s.


ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
March 07, 2012, 09:21:00 AM
 #370

Every time you poll ztex board you get 2 x nonce and 2 x goldennonce. The latter is when there's a diff=1 share found and the former is just the last calculated nonce (twice because ztex uses 2 hashers in parallel, I believe).

In order to avoid loss if two shares are found within the poll interval the firmware stores (and returns) the previous solutions too. This is why the output is doubled.


A few word about interrupt transfers:

Interrupt transfers guarantee a certain latency, e.g. you want to see the mouse pointer moving while you are transferring data to your USB HD.

They do not generate an interrupt on the host computer. They are initiated by the host as any USB transfers, i.e. CPU time for all kind of transfers is about the same. The difference is the latency.

Latency for Bitcoin mining is not an issue:
1. because it doesn't matter if you would receive a share with a delay of 50ms
2. bandwidth is extremely low. Therefore latency is always small if only FPGA boards are connected to the USB.


nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
March 07, 2012, 09:22:53 AM
 #371

Is there a way to stop the FPGA from mining without forcing a reconfigure to get it going again? The use case being many boards loosing network connectivity which will make them go round and round on the same data while waiting for new work, which is wasted electricity.

Already implemented: after about 5 minutes of inactivity the FPGA board enters a low power state. This is implemented in firmware,

But due to the support of backup servers this feature shouldn't be used much.

Backup servers are fine, and they do solve the most common use case but my biggest pain is not pool downtime, rather network issues and no backup pool will help with those.

So just not sending new work to the board for 5 minutes will trigger low power sounds like a great feature, and if I want to force the FPGA to hold still I can issue a resetFpga() though that means I need to reconfigure it afterwards, correct?
TheSeven
Hero Member
*****
Offline Offline

Activity: 504


FPGA Mining LLC


View Profile WWW
March 07, 2012, 10:26:04 AM
 #372

A few word about interrupt transfers:

Interrupt transfers guarantee a certain latency, e.g. you want to see the mouse pointer moving while you are transferring data to your USB HD.

They do not generate an interrupt on the host computer. They are initiated by the host as any USB transfers, i.e. CPU time for all kind of transfers is about the same. The difference is the latency.

Latency for Bitcoin mining is not an issue:
1. because it doesn't matter if you would receive a share with a delay of 50ms
2. bandwidth is extremely low. Therefore latency is always small if only FPGA boards are connected to the USB.

Yes, you could do the same thing (if you don't mind about latency) with an IN BULK endpoint that NAKs all requests until there is a device-side event. Doing it with an IN INTERRUPT EP additionally guarantees that a request is sent once per frame (for bInterval = 1).
However, IIUC (and I haven't yet looked at nelisky's code in detail), the current interface requires the host software to actively poll for events because the device always responds to the transfer immediately, and not only if there was an event. That way the polling can't be offloaded to the hardware, and thus the effective latency before the miner software notices that there's a share is much higher.

And yes, latency does matter, at least for P2Pool. 100ms more total longpoll + sendshare latency = ~1% more stales.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
March 07, 2012, 10:54:26 AM
 #373

So just not sending new work to the board for 5 minutes will trigger low power sounds like a great feature, and if I want to force the FPGA to hold still I can issue a resetFpga() though that means I need to reconfigure it afterwards, correct?

The ultimate low power mode is to reset the FPGA. But this also requires reconfiguration afterwards.


SamHa1n
Member
**
Offline Offline

Activity: 67


View Profile
March 07, 2012, 05:31:39 PM
 #374



DeepBit
Donator
Hero Member
*
Offline Offline

Activity: 532


We have cookies


View Profile WWW
March 07, 2012, 10:00:09 PM
 #375

HDD mounting plates ? Nice idea :)

Welcome to my bitcoin mining pool: https://deepbit.net ~ 3600 GH/s, Both payment schemes, instant payout, no invalid blocks !
Coming soon: ICBIT Trading platform
Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
March 10, 2012, 01:40:31 PM
 #376

Dr Z. what will be your answer to this ? https://bitcointalk.org/index.php?topic=49971.0 Any plans on a 3 ring design ?

BR0KK
Hero Member
*****
Offline Offline

Activity: 742



View Profile
March 10, 2012, 03:39:11 PM
 #377

I got rid of the high speed config issue since i moved my vm to parallels Smiley

allinvain
Legendary
*
Offline Offline

Activity: 1988



View Profile
March 10, 2012, 07:12:32 PM
 #378

HDD mounting plates ? Nice idea Smiley

Indeed! Very elegant idea. I'd like to try it with Icarus boards.

Anyone know where he possibly bought this hdd enclosure? I've been hunting on newegg but can't seem to find something similar. I'm guessing that it was taken from a case though.

Edit: Hmm, I found something similar : http://www.newegg.ca/Product/Product.aspx?Item=N82E16816111045

I still think the one in the picture looks bigger though, but I could be wrong.

SamHa1n
Member
**
Offline Offline

Activity: 67


View Profile
March 10, 2012, 08:25:17 PM
 #379

HDD mounting plates ? Nice idea Smiley

Indeed! Very elegant idea. I'd like to try it with Icarus boards.

Anyone know where he possibly bought this hdd enclosure? I've been hunting on newegg but can't seem to find something similar. I'm guessing that it was taken from a case though.

Edit: Hmm, I found something similar : http://www.newegg.ca/Product/Product.aspx?Item=N82E16816111045

I still think the one in the picture looks bigger though, but I could be wrong.

Thanks. The rack is by "sans digital". It's two of them stacked.
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
March 10, 2012, 08:41:04 PM
 #380

Dr Z. what will be your answer to this ? https://bitcointalk.org/index.php?topic=49971.0 Any plans on a 3 ring design ?
Hm, can somebody explain how this works like I'm 5 years old? Smiley

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!