ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards

[ztex]

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".

[Inspector 2211]

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]

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 ;-) )

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]

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

[Inspector 2211]

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]

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]

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]

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]

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]

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]

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 ;-) )

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]

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

[ztex]

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]

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]

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

[HendrikJan]

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?

[nelisky]

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]

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]

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

[ztex]

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.