Re: ZTEX USB-FPGA Modules 1.15x and 1.15y: 215 and 860 MH/s FPGA Boards
Dear ZTEX,
I need some help..
Today, my new 1.15y2 arrived from German-group-buy.
Some strange things are happening:
I reflashed the firmware once again, too.
I removed the heatsink from 1,2 & 3 removed paste (a bit too much) and attached them again, but I can't change it:
1. Chip 3 is running with 8 degrees more then chip 4 - something to worry about?
2. Chip2 is producing more errors then the other three, which results to a lower frequency and lower hashrate (of course).
On Chip too, the paste at the heatsink looked like it has only connection to the edges and not at the middle of the chip. Is this possible? Any advices? Is this within the normal range?
Thanky in advance,
Gaim
edit: In fact, after I reworked the paste on the chips, It behaves much better on bfgminer too... maybe that was the reason why.
edit2: The reason for posting is/was.. on my really first try the 3rd chip ( I assume no. 3 is c-suffix in bfgminer ) was running super fast, while the 2nd dropped much. I'm currently testing the values after the above written rework of the past on the spartan chips (while the no. 2 had over 300 errors)
edit3: Relaunched bfgminer to make a long-run test:
that is what I wanted to show you. .. it is for off with the hardware error rate.
I need some help..
Today, my new 1.15y2 arrived from German-group-buy.
Some strange things are happening:
Code:
008-0: ztex_ufm1_15y1-04A39E1212-1: f=220.00MHz, errorRate=0.51%, maxErrorRate=1.10%, hashRate=218.9MH/s, T=46.4°C, submitted 15 new nonces, luckFactor=1.05
008-0: ztex_ufm1_15y1-04A39E1212-2: f=216.00MHz, errorRate=1.21%, maxErrorRate=1.81%, hashRate=213.4MH/s, T=45.8°C, submitted 15 new nonces, luckFactor=1.06
008-0: ztex_ufm1_15y1-04A39E1212-3: f=224.00MHz, errorRate=0.00%, maxErrorRate=0.00%, hashRate=224.0MH/s, T=52.2°C, submitted 12 new nonces, luckFactor=0.87
008-0: ztex_ufm1_15y1-04A39E1212-4: f=220.00MHz, errorRate=0.00%, maxErrorRate=0.00%, hashRate=220.0MH/s, T=45.1°C, submitted 11 new nonces, luckFactor=0.93
With your miner the values are relative ok, because the client is able to change the frequence of all 4 independly. 008-0: ztex_ufm1_15y1-04A39E1212-2: f=216.00MHz, errorRate=1.21%, maxErrorRate=1.81%, hashRate=213.4MH/s, T=45.8°C, submitted 15 new nonces, luckFactor=1.06
008-0: ztex_ufm1_15y1-04A39E1212-3: f=224.00MHz, errorRate=0.00%, maxErrorRate=0.00%, hashRate=224.0MH/s, T=52.2°C, submitted 12 new nonces, luckFactor=0.87
008-0: ztex_ufm1_15y1-04A39E1212-4: f=220.00MHz, errorRate=0.00%, maxErrorRate=0.00%, hashRate=220.0MH/s, T=45.1°C, submitted 11 new nonces, luckFactor=0.93
I reflashed the firmware once again, too.
I removed the heatsink from 1,2 & 3 removed paste (a bit too much) and attached them again, but I can't change it:
1. Chip 3 is running with 8 degrees more then chip 4 - something to worry about?
2. Chip2 is producing more errors then the other three, which results to a lower frequency and lower hashrate (of course).
On Chip too, the paste at the heatsink looked like it has only connection to the edges and not at the middle of the chip. Is this possible? Any advices? Is this within the normal range?
Thanky in advance,
Gaim
edit: In fact, after I reworked the paste on the chips, It behaves much better on bfgminer too... maybe that was the reason why.
edit2: The reason for posting is/was.. on my really first try the 3rd chip ( I assume no. 3 is c-suffix in bfgminer ) was running super fast, while the 2nd dropped much. I'm currently testing the values after the above written rework of the past on the spartan chips (while the no. 2 had over 300 errors)
edit3: Relaunched bfgminer to make a long-run test:
| Device | Enabled | Status | MHS av | MHS 30s | Accepted | Rejected | Hardware Errors | Frequency |
| ZTX1a | Y | Alive | 213.988 | 215.727 | 102 | 0 | 10 | 216.000 |
| ZTX1b | Y | Alive | 214.320 | 215.715 | 115 | 1 | 259 | 216.000 |
| ZTX1c | Y | Alive | 210.527 | 211.729 | 115 | 1 | 2 | 216.000 |
| ZTX1d | Y | Alive | 222.402 | 223.756 | 144 | 0 | 71 | 216.000 |
that is what I wanted to show you. .. it is for off with the hardware error rate.