Bitcoin Forum
December 10, 2016, 03:26:14 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   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 174207 times)
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
January 27, 2012, 06:50:02 PM
 #221

Will do, but right now I'm at work, so by the time I can send them, it'll be [early] Saturday morning in Germany.
I'm mining in a small office I rent in Silicon Valley, mostly with HD 5830 cards. (Yes, it gets "toasty" in there...)

Did you evaluate the "submitted hash rate" or "hash rate"?

If you find no shares within the fist few minutes the "submitted hash rate" is zero because you submitted nothing.

The actual hash rate is the frequency minus errors, because the FPGA calculates on hash per clock. In the new version this value is called "hash rate" and can be found ind the logs/output between "maxErroRate" and "submitted <n> new nonces".

1481340374
Hero Member
*
Offline Offline

Posts: 1481340374

View Profile Personal Message (Offline)

Ignore
1481340374
Reply with quote  #2

1481340374
Report to moderator
1481340374
Hero Member
*
Offline Offline

Posts: 1481340374

View Profile Personal Message (Offline)

Ignore
1481340374
Reply with quote  #2

1481340374
Report to moderator
1481340374
Hero Member
*
Offline Offline

Posts: 1481340374

View Profile Personal Message (Offline)

Ignore
1481340374
Reply with quote  #2

1481340374
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481340374
Hero Member
*
Offline Offline

Posts: 1481340374

View Profile Personal Message (Offline)

Ignore
1481340374
Reply with quote  #2

1481340374
Report to moderator
1481340374
Hero Member
*
Offline Offline

Posts: 1481340374

View Profile Personal Message (Offline)

Ignore
1481340374
Reply with quote  #2

1481340374
Report to moderator
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
January 27, 2012, 06:53:56 PM
 #222

Did you evaluate the "submitted has rate" or "has rate"?

If you find no shares within the fist few minutes the "submitted hash rate" is zero because you submitted nothing.

The actual hash rate is the frequency minus errors, because the FPGA calculates on hash per clock. In the new version this value is called "hash rate" and can be found ind the logs/output between "maxErroRate" and "submitted <n> new nonces".


I just looked at the screen output, the number on the far right side. And yes, I did wait a minute or two to see whether I get a non-zero hash rate.

What I noticed is, the software kept switching frequencies like crazy, in 6 MHz increments, whereas the old software switched in 8 MHz increments and only very rarely.

ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
January 27, 2012, 07:12:57 PM
 #223

I just looked at the screen output, the number on the far right side. And yes, I did wait a minute or two to see whether I get a non-zero hash rate.

This is the "submitted hash rate". Never, ever, ever use this value for performance evaluation if you run the board only for a few minutes. Use the frequency or the "hash rate" in the center of the line.

(Maybe I should put the actual "hash rate" to the end of the line and the "submitted hash rate" into the center. This will save al lot of support time ;-) )

Quote
What I noticed is, the software kept switching frequencies like crazy, in 6 MHz increments, whereas the old software switched in 8 MHz increments and only very rarely.

It switches more often at start-up but will stabilize after a while.

rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
January 27, 2012, 08:20:07 PM
 #224

Don't forget the new firmware: -f ztex_ufm1_15d2.ihx

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
January 27, 2012, 09:44:14 PM
 #225

Don't forget the new firmware: -f ztex_ufm1_15d2.ihx

The Java software detects which firmware it is targeted at, and will complain if you try to run it against the wrong (== too old or too new) firmware.
CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 306


View Profile
January 27, 2012, 09:57:22 PM
 #226

Quote

What I noticed is, the software kept switching frequencies like crazy, in 6 MHz increments, whereas the old software switched in 8 MHz increments and only very rarely.


I got that problem too.  I tested the new firmware on two boards and it will do that somewhat randomly.  I tried it out for at least 30 minutes and it wouldn't stabilize.  Got only about combined 180MH/s on two boards at deepbit.  Went back to the d1 firmware and it ran fine at about 400MH/s.  
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
January 27, 2012, 10:27:24 PM
 #227

I got that problem too.  I tested the new firmware on two boards and it will do that somewhat randomly.  I tried it out for at least 30 minutes and it wouldn't stabilize.  Got only about combined 180MH/s on two boards at deepbit.  Went back to the d1 firmware and it ran fine at about 400MH/s.  

What exactly happened to the frequency? Does the the d2 firmware clocks down, but the d1 firmware runs stable?

If yes, it is a clock stability problem (too much jitter). I saw that earlier and thought it would have been fixed because it does not appear anymore on my 1.15d FPGA board test cluster. I will change a few parameters and post a test release next week (because I cannot reproduce this problem here).

If that problem appears, just use the d1 firmware (from the new release). It is as fast.





CA Coins
Donator
Sr. Member
*
Offline Offline

Activity: 306


View Profile
January 27, 2012, 11:53:45 PM
 #228

I think that might be it.  It runs stable with the d1 firmware so I am sticking with that for now.  Here is a part of the log showing that it clocks up and down, sometimes really low.  It runs stable at 192Mhz with the d1 and sometimes it will run stable with the d2 as well, but it inconsistent.  I will trim the entry once you have seen it.

EDIT:  Got it, thanks.
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
January 28, 2012, 12:08:24 AM
 #229

I think that might be it.  It runs stable with the d1 firmware so I am sticking with that for now.  Here is a part of the log showing that it clocks up and down, sometimes really low.  It runs stable at 192Mhz with the d1 and sometimes it will run stable with the d2 as well, but it inconsistent.  I will trim the entry once you have seen it.

Seen it. I'll send you a new firmware for testing next week. If it cant be fixed I'll switch back to d1.

BTW, with d1 your boards should achieve 200 MHz, with d2 198 MHz or 204 Mhz.

Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
January 28, 2012, 12:33:58 AM
 #230

I think that might be it.  It runs stable with the d1 firmware so I am sticking with that for now.  Here is a part of the log showing that it clocks up and down, sometimes really low.  It runs stable at 192Mhz with the d1 and sometimes it will run stable with the d2 as well, but it inconsistent.  I will trim the entry once you have seen it.

Seen it. I'll send you a new firmware for testing next week. If it cant be fixed I'll switch back to d1.

BTW, with d1 your boards should achieve 200 MHz, with d2 198 MHz or 204 Mhz.


I'm assuming that in the December firmware, the PLL denominator, which divides the 48 MHz input clock (from the Cypress microcontroller) is 6, and thus the numerator is multiplied by 8 MHz, leading to frequency adjustments of granularity 8 MHz, whereas in the January firmware, the PLL denominator is 8, and thus the numerator is multiplied by 6 MHz, leading to frequency adjustments of granularity 6 MHz.

Correct?
Inspector 2211
Sr. Member
****
Offline Offline

Activity: 383



View Profile
January 28, 2012, 05:07:56 AM
 #231

I just looked at the screen output, the number on the far right side. And yes, I did wait a minute or two to see whether I get a non-zero hash rate.

This is the "submitted hash rate". Never, ever, ever use this value for performance evaluation if you run the board only for a few minutes. Use the frequency or the "hash rate" in the center of the line.

(Maybe I should put the actual "hash rate" to the end of the line and the "submitted hash rate" into the center. This will save al lot of support time ;-) )

Quote
What I noticed is, the software kept switching frequencies like crazy, in 6 MHz increments, whereas the old software switched in 8 MHz increments and only very rarely.

It switches more often at start-up but will stabilize after a while.

No, this new version really doesn't work. It tries and tries, gradually reducing the PLL frequency down to 126 MHz, that's when I gave up. I have sent you a log by email.
rupy
Hero Member
*****
Offline Offline

Activity: 724



View Profile
January 28, 2012, 07:52:34 AM
 #232

the d2 works fine for me with zalman heatsink stabilizing around 208 MH/s at 210 MHz:

ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz,  errorRate=0.10%,  maxErrorRate=0.69%, \
 hash rate: 209.8MH/s,  submitted 2 new nonces,  submitted hash rate 208.5MH/s
ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz,  errorRate=0.08%,  maxErrorRate=0.69%, \
 hash rate: 209.8MH/s,  submitted 3 new nonces,  submitted hash rate 208.6MH/s
ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz,  errorRate=0.28%,  maxErrorRate=0.69%, \
 hash rate: 209.4MH/s,  submitted 0 new nonces,  submitted hash rate 208.5MH/s
ztex_ufm1_15d2-04A32DC7CA: f=210.00MHz,  errorRate=0.21%,  maxErrorRate=0.69%, \
 hash rate: 209.6MH/s,  submitted 3 new nonces,  submitted hash rate 208.6MH/s

BANKBOOK GWT Wallet & no-FIAT Billing API
BTC 14xr5Q1j61A1eA6Mrs5MRhUmYZKboY8iq2 | Vanillacoin FPGA Miner
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
January 28, 2012, 09:51:44 AM
 #233

No, this new version really doesn't work. It tries and tries, gradually reducing the PLL frequency down to 126 MHz, that's when I gave up. I have sent you a log by email.

Use the d1 firmware from the new release if d2 does not work, see https://bitcointalk.org/index.php?topic=40047.msg715272#msg715272

ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
January 28, 2012, 09:55:41 AM
 #234

I'm assuming that in the December firmware, the PLL denominator, which divides the 48 MHz input clock (from the Cypress microcontroller) is 6, and thus the numerator is multiplied by 8 MHz, leading to frequency adjustments of granularity 8 MHz, whereas in the January firmware, the PLL denominator is 8, and thus the numerator is multiplied by 6 MHz, leading to frequency adjustments of granularity 6 MHz.

Correct?

Not exactly, but something like that: the only difference between the d1 and the d2 firmware of the new release are different DCM and PLL settings.

Turbor
Legendary
*
Offline Offline

Activity: 1008


BitMinter


View Profile WWW
January 28, 2012, 11:59:28 AM
 #235

Have d2 on all of my boards. 1 makes 216 MHz, 3 210 MHz and 2 204 MHz.

HendrikJan
Jr. Member
*
Offline Offline

Activity: 51



View Profile
January 28, 2012, 12:19:25 PM
 #236

Real nice project but i need to buy them for the sale price of 250 pieces before i can make some profit.
I get an break even in 323 days.
http://bitcoinx.com/profit/

Or did i miss something and can it be faster/cheaper?

http://vertcoin.org
It's ASIC resistant, Multipool resistant and Rare
nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
January 28, 2012, 12:34:30 PM
 #237

Although it might not be more than a coincidence, I can tell you that mining with d2 (on EclipseMC) has a weird behaviour; it starts fine, mines away at the expected rate but eventually starts to submit less nonces. I mean, not in a random way, consistently less, with all the rates reported in BTCMiner staying stable (even though the submits are correctly reported in the low ball area). It simply does not happen when mining with d1.

Doing a little debug it seems to me that it happens when there are multiple new blocks reported in a short amount of time. Could be a problem with long pooling, but why would only d2 be affected by this? My board runs at 198MHz with d2, 0% error rate, frequency is stable, so that's not it.

I'm sticking with d1 for now but let me know if you need more info or want me to test anything.
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
January 30, 2012, 11:03:31 AM
 #238

Although it might not be more than a coincidence, I can tell you that mining with d2 (on EclipseMC) has a weird behaviour; it starts fine, mines away at the expected rate but eventually starts to submit less nonces. I mean, not in a random way, consistently less, with all the rates reported in BTCMiner staying stable (even though the submits are correctly reported in the low ball area). It simply does not happen when mining with d1.

The difference between d1 and d2 firmware are different clock multipliers / dividers. This does not influence the submission of shares.

For performance evaluation use the "hash rate" value from the center of the line. The "submitted hash rate" at the end of the line is computed based on the shared found. This value depends on your luck and is only informative after at least a few hours runtime.

nelisky
Legendary
*
Offline Offline

Activity: 1554


View Profile
January 30, 2012, 11:10:22 AM
 #239

The difference between d1 and d2 firmware are different clock multipliers / dividers. This does not influence the submission of shares.

For performance evaluation use the "hash rate" value from the center of the line. The "submitted hash rate" at the end of the line is computed based on the shared found. This value depends on your luck and is only informative after at least a few hours runtime.

Yeah, that's what I though. It did run for 4+ hours each way, and the values reported by BTCMiner certainly fell within or above the expected. The problem was that it started consistently submitting a lot less shares, without exception, for a multi hour stretch of time (though the MHs rates staid where they should).

As I said, probably just coincidence, I just feel it is awkward this coincidence only happened with d2 and always happened to d2... but hey, that's why it is called 'coincidence', I guess Smiley
ztex
Donator
Sr. Member
*
Offline Offline

Activity: 367

ZTEX FPGA Boards


View Profile WWW
January 30, 2012, 01:16:36 PM
 #240

A testing release has been published: http://www.ztex.de/btcminer/ZtexBTCMiner-120130.jar . See the software thread (https://bitcointalk.org/index.php?topic=40047.msg722099#msg722099) for details.

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!