Topic: BTCMiner - Open Source Bitcoin Miner for ZTEX FPGA Boards, 215 MH/s on LX150 - page 19. (Read 161737 times)
February 21, 2012, 02:07:13 PM
Thanks for the new feature Ztex. Do you think capping the maximum frequency overclock may improve the longevity of the FPGAs?
February 21, 2012, 11:14:52 AM
A new release of BTCMiner (http://www.ztex.de/btcminer) has been published: http://www.ztex.de/btcminer/ZtexBTCMiner-120221.jar .
New feature: Improved overheat protection by FPGA shutdown if frequency drops too much.
The shutdown threshold is a factor and can be set by "-oh" option. If the frequency drops by that factor, but at least two frequency steps, the overheat shutdown is triggered. Default vaule is 0.05, recommended values are 0 to 0.1. If the value is set to 0 the FPGA is stopped if the frequency drops by two frequency steps.
New feature: Improved overheat protection by FPGA shutdown if frequency drops too much.
The shutdown threshold is a factor and can be set by "-oh" option. If the frequency drops by that factor, but at least two frequency steps, the overheat shutdown is triggered. Default vaule is 0.05, recommended values are 0 to 0.1. If the value is set to 0 the FPGA is stopped if the frequency drops by two frequency steps.
February 11, 2012, 02:59:04 PM
Did you see application note 879?
XAPP879 is about dynamic PLL reconfiguration.
PLL is not reconfigured. See the source code.
February 11, 2012, 02:20:29 PM
I too had similar "countdown to death" experiences yesterday with a new 1.15x and d3a and d2, only d1 worked. I have also changed the pool yesterday just to make sure it wasn't a problem with the pool, but same result.
Surprisingly, today the d3a worked without problem. I have not changed anything else, heat sink still the same, same power supply, same parameters etc.
Surprisingly, today the d3a worked without problem. I have not changed anything else, heat sink still the same, same power supply, same parameters etc.
d2, d3 and d3a firmwares are marked as experimental because they may not work.
But I think I found the problem: it was an undocumented requirement in the DCM re-programming sequence.
Did you see application note 879?
Quote:
In short, the operations that must be implemented to reconfigure one value in the PLL are:
• Assert RST to the PLL (do not de-assert)
• Set DADDR on the PLL and assert DEN for one clock cycle
• Wait for the DRDY signal to assert from the PLL
• Perform a bitwise AND between the DO port and the MASK (DI = DO and MASK)
• Perform a bitwise OR between the DI signal and the BITSET (DI = DI or BITSET)
• Assert DEN and DWE on the PLL for one clock cycle
• Wait for the DRDY signal to assert from the PLL
• De-assert RST to the PLL
• Wait for PLL to lock
February 10, 2012, 12:34:22 AM
Eclipse Mining Consortium 
February 10, 2012, 12:31:34 AM
Nice report CAcoins, very helpful.
May I ask what EMC is? Edit: Uhh, EMC the pool. Never mind.
May I ask what EMC is? Edit: Uhh, EMC the pool. Never mind.
February 09, 2012, 11:16:39 PM
Quote
I uploaded a new http://www.ztex.de/btcminer/ZtexBTCMiner-120208.jar this morning (didn't spent a new version number) with two (more than) late minute fixes. It should reduce the CPU usage during start-up and the string error which occurs with some Java version.
Tested out the latest version. A couple of observations:
1. The new programming doesn't use the cpu at all. Barely noticed a blip on the cpu utilization during initial programming or mining. So it doesn't seem like the software needs much cpu power at all. May be time to replace the i7-2600k back to the G620.
2. The problem with EMC appears fixed with the bug-fixes. Now mining with no problems on EMC.
Bravo on the bug fixes!
February 09, 2012, 07:05:14 PM
Thanks for the advice! I will try it out and post the updated results.
February 09, 2012, 06:58:03 PM
Looks like i have to upgrade soon 
.
. Yes, time to upgrade
These little suckers are awesome.Quote
I wonder why the boards only run at 208 MHz, Here at 65 degree the slowest board runs at 208 and the fastest at 220. Most do 212. Perhaps you can try to cool them down more ?
Yeah, ztex noticed it too. I haven't really work on the cooling yet. Maybe still stuck in the mindset that 60 degree C is cool. I have some old Silverstone 120mm fans that I plan to use for some airflow. Do you notice any difference if you have air flowing through the bottom of the boards? I also have a habit of putting on too much thermal paste so I might re-apply to see if it makes a difference. I am content with the hashrate though as long as it runs stable. It's middle of winter and it is already 85 F outside. And SCE charges an arm and a leg (12-30 cents/kwh) so AC is a hard pill to swallow.
If you can cool the heatsink from the side you should be able to see a difference. Best would be a 80mm fan behind every board for max effect. Heatsink placement can be a b!itch. I would start with the boards with the highest error rate and re-grease them to see if something changes. At 200 MHz you should not see any errors. Be carefull with the plastic pins ! I broke one off on my first board when i replaced the pad with thermal grease.
February 09, 2012, 06:00:49 PM
Looks like i have to upgrade soon .
. Yes, time to upgrade
These little suckers are awesome.Quote
I wonder why the boards only run at 208 MHz, Here at 65 degree the slowest board runs at 208 and the fastest at 220. Most do 212. Perhaps you can try to cool them down more ?
Yeah, ztex noticed it too. I haven't really work on the cooling yet. Maybe still stuck in the mindset that 60 degree C is cool. I have some old Silverstone 120mm fans that I plan to use for some airflow. Do you notice any difference if you have air flowing through the bottom of the boards? I also have a habit of putting on too much thermal paste so I might re-apply to see if it makes a difference. I am content with the hashrate though as long as it runs stable. It's middle of winter and it is already 85 F outside. And SCE charges an arm and a leg (12-30 cents/kwh) so AC is a hard pill to swallow.
February 09, 2012, 05:03:31 PM
Wow, 20 boards... very nice. Looks like i have to upgrade soon . I wonder why the boards only run at 208 MHz, Here at 65 degree the slowest board runs at 208 and the fastest at 220. Most do 212. Perhaps you can try to cool them down more ? Replaced all my fans on the 1.15x boards with Scythe Kaze minis. They are a bit less effective since they run at 3500rpm, but they are very quiet. Lost 4 MHz on one board, the others have a bit higher error rate.
. I wonder why the boards only run at 208 MHz, Here at 65 degree the slowest board runs at 208 and the fastest at 220. Most do 212. Perhaps you can try to cool them down more ? Replaced all my fans on the 1.15x boards with Scythe Kaze minis. They are a bit less effective since they run at 3500rpm, but they are very quiet. Lost 4 MHz on one board, the others have a bit higher error rate. February 09, 2012, 04:07:57 PM
I uploaded a new http://www.ztex.de/btcminer/ZtexBTCMiner-120208.jar this morning (didn't spent a new version number) with two (more than) late minute fixes. It should reduce the CPU usage during start-up and the string error which occurs with some Java version.
Ok, will test it out.
Quote
The CPU usage during runtime (i.e. after start-up) should be almost zero.
Yes, during run time is almost no cpu usage (and yes, a 2600k is probably overkill but I couldn't help it.) I will clarify it on my post that maxing the CPU is only during programming, otherwise it barely uses the cpu during run time.
February 09, 2012, 04:00:04 PM
Thanks for the review.
I uploaded a new http://www.ztex.de/btcminer/ZtexBTCMiner-120208.jar this morning (didn't spent a new version number) with two (more than) late minute fixes. It should reduce the CPU usage during start-up and the string error which occurs with some Java version.
The CPU usage during runtime (i.e. after start-up) should be almost zero.
Quote
ztex_ufm1_15d3-04A32E1A99: Error: String index out of range: 4: Disabling device
I noticed this error when I briefly tried running with EMC. I didn't have time to fully test it out, but I just thought I didn't have the pool info correct. Any thoughts?I uploaded a new http://www.ztex.de/btcminer/ZtexBTCMiner-120208.jar this morning (didn't spent a new version number) with two (more than) late minute fixes. It should reduce the CPU usage during start-up and the string error which occurs with some Java version.
Quote
It will run on the g620 without errors, but it maxes the cpu.
The CPU usage during runtime (i.e. after start-up) should be almost zero.
February 09, 2012, 03:30:52 PM
Quote
ztex_ufm1_15d3-04A32E1A99: Error: String index out of range: 4: Disabling device
I had a chance to test the cluster yesterday, and I just want to summarize my experience with ztex. I hope I am not stating what everybody already knows:
Currently, with the 120208 release, I am able to run my 20-board test cluster with d1, d3, and d3a. I have been testing with deepbit for the last week or so, and the rate has been very stable at around 4GH/S. It will range between 3900 to 4100, but for the most part it is around 4,000 to 4,050 (60 min average per deepbit). Most of the boards are running at 200 to 208 MHz. Power, measured with a power meter at the outlet is 245 watts (APC BR1500, Corsair Ax1200 gold, core i7 2600k, 4gig ram, 32G SSD, win 7 64, jre64).
Code:
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-A1: f=204.00MHz, errorRate=0.41%, maxErrorRate=1.86%, hashRate=203.2MH/s, submitted 16 new nonces, luckFactor=0.96
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-A2: f=200.00MHz, errorRate=0.00%, maxErrorRate=0.31%, hashRate=200.0MH/s, submitted 11 new nonces, luckFactor=1.02
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-A3: f=200.00MHz, errorRate=0.00%, maxErrorRate=0.25%, hashRate=200.0MH/s, submitted 14 new nonces, luckFactor=1.02
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-A4: f=200.00MHz, errorRate=0.00%, maxErrorRate=1.05%, hashRate=200.0MH/s, submitted 11 new nonces, luckFactor=0.99
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B1: f=208.00MHz, errorRate=0.07%, maxErrorRate=0.67%, hashRate=207.8MH/s, submitted 12 new nonces, luckFactor=1.00
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B2: f=208.00MHz, errorRate=1.23%, maxErrorRate=1.94%, hashRate=205.4MH/s, submitted 8 new nonces, luckFactor=0.96
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B3: f=200.00MHz, errorRate=0.04%, maxErrorRate=0.50%, hashRate=199.9MH/s, submitted 18 new nonces, luckFactor=1.06
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B4: f=204.00MHz, errorRate=0.12%, maxErrorRate=1.33%, hashRate=203.7MH/s, submitted 12 new nonces, luckFactor=0.92
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B5: f=204.00MHz, errorRate=0.04%, maxErrorRate=1.20%, hashRate=203.9MH/s, submitted 17 new nonces, luckFactor=1.04
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B6: f=200.00MHz, errorRate=0.27%, maxErrorRate=0.54%, hashRate=199.5MH/s, submitted 17 new nonces, luckFactor=1.03
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A0: f=204.00MHz, errorRate=0.00%, maxErrorRate=0.54%, hashRate=204.0MH/s, submitted 19 new nonces, luckFactor=1.04
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A5: f=200.00MHz, errorRate=0.30%, maxErrorRate=1.48%, hashRate=199.4MH/s, submitted 13 new nonces, luckFactor=0.96
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A6: f=200.00MHz, errorRate=0.00%, maxErrorRate=0.64%, hashRate=200.0MH/s, submitted 10 new nonces, luckFactor=0.96
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A7: f=204.00MHz, errorRate=1.86%, maxErrorRate=2.95%, hashRate=200.2MH/s, submitted 20 new nonces, luckFactor=1.07
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A8: f=204.00MHz, errorRate=0.00%, maxErrorRate=0.28%, hashRate=204.0MH/s, submitted 16 new nonces, luckFactor=0.99
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A9: f=204.00MHz, errorRate=0.00%, maxErrorRate=0.32%, hashRate=204.0MH/s, submitted 12 new nonces, luckFactor=1.00
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B0: f=204.00MHz, errorRate=0.29%, maxErrorRate=1.46%, hashRate=203.4MH/s, submitted 11 new nonces, luckFactor=0.97
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B7: f=204.00MHz, errorRate=0.00%, maxErrorRate=0.32%, hashRate=204.0MH/s, submitted 13 new nonces, luckFactor=1.05
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B8: f=204.00MHz, errorRate=0.00%, maxErrorRate=0.58%, hashRate=204.0MH/s, submitted 13 new nonces, luckFactor=1.14
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B9: f=200.00MHz, errorRate=0.45%, maxErrorRate=1.45%, hashRate=199.1MH/s, submitted 18 new nonces, luckFactor=1.08
2012-02-09T23:31:04: bus-0-0: poll loop time: 74ms (USB: 2ms network: 72ms) getwork time: 189ms submit time: 197ms
2012-02-09T23:31:04: bus-0-1: poll loop time: 75ms (USB: 2ms network: 73ms) getwork time: 187ms submit time: 194ms
2012-02-09T23:31:04: Total hash rate: 4045.6 MH/s
2012-02-09T23:31:04: Total submitted hash rate: 4076.4 MH/s
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-A2: f=200.00MHz, errorRate=0.00%, maxErrorRate=0.31%, hashRate=200.0MH/s, submitted 11 new nonces, luckFactor=1.02
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-A3: f=200.00MHz, errorRate=0.00%, maxErrorRate=0.25%, hashRate=200.0MH/s, submitted 14 new nonces, luckFactor=1.02
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-A4: f=200.00MHz, errorRate=0.00%, maxErrorRate=1.05%, hashRate=200.0MH/s, submitted 11 new nonces, luckFactor=0.99
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B1: f=208.00MHz, errorRate=0.07%, maxErrorRate=0.67%, hashRate=207.8MH/s, submitted 12 new nonces, luckFactor=1.00
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B2: f=208.00MHz, errorRate=1.23%, maxErrorRate=1.94%, hashRate=205.4MH/s, submitted 8 new nonces, luckFactor=0.96
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B3: f=200.00MHz, errorRate=0.04%, maxErrorRate=0.50%, hashRate=199.9MH/s, submitted 18 new nonces, luckFactor=1.06
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B4: f=204.00MHz, errorRate=0.12%, maxErrorRate=1.33%, hashRate=203.7MH/s, submitted 12 new nonces, luckFactor=0.92
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B5: f=204.00MHz, errorRate=0.04%, maxErrorRate=1.20%, hashRate=203.9MH/s, submitted 17 new nonces, luckFactor=1.04
2012-02-09T23:31:04: bus-0-0: ztex_ufm1_15d3-2012-L1-B6: f=200.00MHz, errorRate=0.27%, maxErrorRate=0.54%, hashRate=199.5MH/s, submitted 17 new nonces, luckFactor=1.03
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A0: f=204.00MHz, errorRate=0.00%, maxErrorRate=0.54%, hashRate=204.0MH/s, submitted 19 new nonces, luckFactor=1.04
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A5: f=200.00MHz, errorRate=0.30%, maxErrorRate=1.48%, hashRate=199.4MH/s, submitted 13 new nonces, luckFactor=0.96
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A6: f=200.00MHz, errorRate=0.00%, maxErrorRate=0.64%, hashRate=200.0MH/s, submitted 10 new nonces, luckFactor=0.96
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A7: f=204.00MHz, errorRate=1.86%, maxErrorRate=2.95%, hashRate=200.2MH/s, submitted 20 new nonces, luckFactor=1.07
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A8: f=204.00MHz, errorRate=0.00%, maxErrorRate=0.28%, hashRate=204.0MH/s, submitted 16 new nonces, luckFactor=0.99
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-A9: f=204.00MHz, errorRate=0.00%, maxErrorRate=0.32%, hashRate=204.0MH/s, submitted 12 new nonces, luckFactor=1.00
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B0: f=204.00MHz, errorRate=0.29%, maxErrorRate=1.46%, hashRate=203.4MH/s, submitted 11 new nonces, luckFactor=0.97
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B7: f=204.00MHz, errorRate=0.00%, maxErrorRate=0.32%, hashRate=204.0MH/s, submitted 13 new nonces, luckFactor=1.05
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B8: f=204.00MHz, errorRate=0.00%, maxErrorRate=0.58%, hashRate=204.0MH/s, submitted 13 new nonces, luckFactor=1.14
2012-02-09T23:31:04: bus-0-1: ztex_ufm1_15d3-2012-L1-B9: f=200.00MHz, errorRate=0.45%, maxErrorRate=1.45%, hashRate=199.1MH/s, submitted 18 new nonces, luckFactor=1.08
2012-02-09T23:31:04: bus-0-0: poll loop time: 74ms (USB: 2ms network: 72ms) getwork time: 189ms submit time: 197ms
2012-02-09T23:31:04: bus-0-1: poll loop time: 75ms (USB: 2ms network: 73ms) getwork time: 187ms submit time: 194ms
2012-02-09T23:31:04: Total hash rate: 4045.6 MH/s
2012-02-09T23:31:04: Total submitted hash rate: 4076.4 MH/s
-Boards were shipped the day after payment. Shipping took 4 days from Germany to California, including 2 days at customs.
-The boards were well packaged.
-Assembly of the heatsink was straight forward (I used arctic silver for the thermal paste instead of the included stock paste)
-The power supply is probably the most involved part of the assembly. We decided to solder the wires and the connectors (anal retentiveness acting up) after initially using the terminals per ztex guide, which also works.
-
-Ambient temperature is about 75 degree F (sorry it is California) and heatsink temperature is around 85 F measured with a probe.
-Mining has been very stable on deepbit, which is key for me. Plan now is to try the other pools. Is P2Pool running fine now?
Overall, I am very impressed with ztex's professional work and his boards. He has been very responsive and I am definitely looking to purchase more boards from him. Sorry to take up this space on the forum post, but I just thought I'd leave a good word for ztex and his work.
February 09, 2012, 02:06:59 PM
Somehow i can't use d3a with my 1.15d boards ? d3 works...
Edit: User too dumb it works !
Edit: User too dumb
it works ! February 09, 2012, 08:37:43 AM
I can confirm that the new BTCMiner-120208.jar release with the d3a firmware fixed the LP problem with slush's pool (bitcoin.cz) and also the "High speed FPGA configuration failed" warning seems to be gone for now. Configuration took 3000+ms instead of 7000+ms.
Something curious, why did it set the frequency from 216MHz to 220MHz and then straight back to 212MHz?
Something curious, why did it set the frequency from 216MHz to 220MHz and then straight back to 212MHz?
Because at 212MHz your board delivers the most valid hashes per second.
BTCMiner needs to test it out. (The frequency is increased until a certain error rate (10%) is reached. Then the frequency with the highest rate of valid hashes is chosen.)
As smaller the frequency steps as more often you can see this behavior. At 4MHz this is quite normal.
February 09, 2012, 08:04:35 AM
I can confirm that the new BTCMiner-120208.jar release with the d3a firmware fixed the LP problem with slush's pool (bitcoin.cz) and also the "High speed FPGA configuration failed" warning seems to be gone for now. Configuration took 3000+ms instead of 7000+ms.
Something curious, why did it set the frequency from 216MHz to 220MHz and then straight back to 212MHz?
ztex_ufm1_15d3-04A32E00E9: Set frequency to 212.00MHz
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.00%, hashRate=212.0MH/s, submitted 1 new nonces, luckFactor=0.84
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.40%, maxErrorRate=0.50%, hashRate=211.1MH/s, submitted 2 new nonces, luckFactor=0.95
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.30%, maxErrorRate=0.50%, hashRate=211.4MH/s, submitted 0 new nonces, luckFactor=0.90
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.57%, maxErrorRate=0.60%, hashRate=210.8MH/s, submitted 1 new nonces, luckFactor=0.92
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.38%, maxErrorRate=0.60%, hashRate=211.2MH/s, submitted 0 new nonces, luckFactor=0.88
ztex_ufm1_15d3-04A32E00E9: Set frequency to 216.00MHz
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz, submitted 2 new nonces, luckFactor=0.94
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz, errorRate=1.63%, maxErrorRate=1.89%, hashRate=212.5MH/s, submitted 4 new nonces, luckFactor=1.16
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz, errorRate=2.05%, maxErrorRate=2.49%, hashRate=211.6MH/s, submitted 5 new nonces, luckFactor=1.40
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz, errorRate=1.57%, maxErrorRate=2.53%, hashRate=212.6MH/s, submitted 0 new nonces, luckFactor=1.34
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz, errorRate=2.00%, maxErrorRate=2.53%, hashRate=211.7MH/s, submitted 5 new nonces, luckFactor=1.56
ztex_ufm1_15d3-04A32E00E9: Set frequency to 220.00MHz
ztex_ufm1_15d3-04A32E00E9: Set frequency to 212.00MHz
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.32%, maxErrorRate=0.60%, hashRate=211.3MH/s, submitted 0 new nonces, luckFactor=1.50
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.22%, maxErrorRate=0.60%, hashRate=211.5MH/s, submitted 1 new nonces, luckFactor=1.49
Something curious, why did it set the frequency from 216MHz to 220MHz and then straight back to 212MHz?
ztex_ufm1_15d3-04A32E00E9: Set frequency to 212.00MHz
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.00%, hashRate=212.0MH/s, submitted 1 new nonces, luckFactor=0.84
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.40%, maxErrorRate=0.50%, hashRate=211.1MH/s, submitted 2 new nonces, luckFactor=0.95
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.30%, maxErrorRate=0.50%, hashRate=211.4MH/s, submitted 0 new nonces, luckFactor=0.90
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.57%, maxErrorRate=0.60%, hashRate=210.8MH/s, submitted 1 new nonces, luckFactor=0.92
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.38%, maxErrorRate=0.60%, hashRate=211.2MH/s, submitted 0 new nonces, luckFactor=0.88
ztex_ufm1_15d3-04A32E00E9: Set frequency to 216.00MHz
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz, submitted 2 new nonces, luckFactor=0.94
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz, errorRate=1.63%, maxErrorRate=1.89%, hashRate=212.5MH/s, submitted 4 new nonces, luckFactor=1.16
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz, errorRate=2.05%, maxErrorRate=2.49%, hashRate=211.6MH/s, submitted 5 new nonces, luckFactor=1.40
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz, errorRate=1.57%, maxErrorRate=2.53%, hashRate=212.6MH/s, submitted 0 new nonces, luckFactor=1.34
ztex_ufm1_15d3-04A32E00E9: f=216.00MHz, errorRate=2.00%, maxErrorRate=2.53%, hashRate=211.7MH/s, submitted 5 new nonces, luckFactor=1.56
ztex_ufm1_15d3-04A32E00E9: Set frequency to 220.00MHz
ztex_ufm1_15d3-04A32E00E9: Set frequency to 212.00MHz
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.32%, maxErrorRate=0.60%, hashRate=211.3MH/s, submitted 0 new nonces, luckFactor=1.50
ztex_ufm1_15d3-04A32E00E9: f=212.00MHz, errorRate=0.22%, maxErrorRate=0.60%, hashRate=211.5MH/s, submitted 1 new nonces, luckFactor=1.49
February 09, 2012, 08:02:12 AM
posting on behalf of newbie user vibe ...
Quote
On Ubuntu 32bit using the latest ZtexBTCMiner-120208.jar with latest java.
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
# java -cp ZtexBTCMiner-120208.jar BTCMiner -host "http://asdasd.com:8337" -u asdasd -p asdasd -f ztex_ufm1_15d3.ihx -v
ztex_ufm1_15d3-04A32E1A99: New device: bitfile=ztex_ufm1_15d3 f_default=198.00MHz f_max=240.00MHz HpC=1.0H
ztex_ufm1_15d3-04A32E1A99: FPGA configuration time: 3240 ms
ztex_ufm1_15d3-04A32E1A99: Set frequency to 198.00MHz
Disconnect device or press Ctrl-C for exit
ztex_ufm1_15d3-04A32E1A99: Error: String index out of range: 4: Disabling device
Greetings Vibe
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
# java -cp ZtexBTCMiner-120208.jar BTCMiner -host "http://asdasd.com:8337" -u asdasd -p asdasd -f ztex_ufm1_15d3.ihx -v
ztex_ufm1_15d3-04A32E1A99: New device: bitfile=ztex_ufm1_15d3 f_default=198.00MHz f_max=240.00MHz HpC=1.0H
ztex_ufm1_15d3-04A32E1A99: FPGA configuration time: 3240 ms
ztex_ufm1_15d3-04A32E1A99: Set frequency to 198.00MHz
Disconnect device or press Ctrl-C for exit
ztex_ufm1_15d3-04A32E1A99: Error: String index out of range: 4: Disabling device
Greetings Vibe
As I wrote per Email: Download it again: http://www.ztex.de/btcminer/ZtexBTCMiner-120208.jar (last minut fix) and try it again.
February 09, 2012, 07:55:24 AM
posting on behalf of newbie user vibe ...
Quote
On Ubuntu 32bit using the latest ZtexBTCMiner-120208.jar with latest java.
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
# java -cp ZtexBTCMiner-120208.jar BTCMiner -host "http://asdasd.com:8337" -u asdasd -p asdasd -f ztex_ufm1_15d3.ihx -v
ztex_ufm1_15d3-04A32E1A99: New device: bitfile=ztex_ufm1_15d3 f_default=198.00MHz f_max=240.00MHz HpC=1.0H
ztex_ufm1_15d3-04A32E1A99: FPGA configuration time: 3240 ms
ztex_ufm1_15d3-04A32E1A99: Set frequency to 198.00MHz
Disconnect device or press Ctrl-C for exit
ztex_ufm1_15d3-04A32E1A99: Error: String index out of range: 4: Disabling device
Greetings Vibe
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) Client VM (build 20.5-b03, mixed mode, sharing)
# java -cp ZtexBTCMiner-120208.jar BTCMiner -host "http://asdasd.com:8337" -u asdasd -p asdasd -f ztex_ufm1_15d3.ihx -v
ztex_ufm1_15d3-04A32E1A99: New device: bitfile=ztex_ufm1_15d3 f_default=198.00MHz f_max=240.00MHz HpC=1.0H
ztex_ufm1_15d3-04A32E1A99: FPGA configuration time: 3240 ms
ztex_ufm1_15d3-04A32E1A99: Set frequency to 198.00MHz
Disconnect device or press Ctrl-C for exit
ztex_ufm1_15d3-04A32E1A99: Error: String index out of range: 4: Disabling device
Greetings Vibe
February 08, 2012, 04:43:42 PM
Thanks Ztex for the updates. I am finally going to have some time to do some testing today and I will let you know how it goes.
CAC
CAC
Jump to: