Bitcoin Forum
May 25, 2024, 08:20:44 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: CGMiner and ZTEX: High HW errors okay?  (Read 1865 times)
oxident (OP)
Newbie
*
Offline Offline

Activity: 20
Merit: 0


View Profile
August 14, 2012, 09:29:31 PM
 #1

I've recently started mining with a ZTex 1.15y (quad FPGA) using CGMiner. As far as I can tell everything works fine (2 chips run @ 212MHz, 2 @ 216MHz) but I'm quite unsure about the stats:

After running nearly 4h, each FPGA showed about 4% rejects and three of them had about 150 HW errors. One surprisingly had only 15 errors. I don't know how to deal with these errors because I haven't seen them in the past on my GPU rigs...

Is this a normal behavior because the chips are simply regulating their clock speed on high error rates or should I check my setup?
el_rlee
Legendary
*
Offline Offline

Activity: 1600
Merit: 1014



View Profile
October 17, 2012, 03:27:23 AM
 #2

I've recently started mining with a ZTex 1.15y (quad FPGA) using CGMiner. As far as I can tell everything works fine (2 chips run @ 212MHz, 2 @ 216MHz) but I'm quite unsure about the stats:

After running nearly 4h, each FPGA showed about 4% rejects and three of them had about 150 HW errors. One surprisingly had only 15 errors. I don't know how to deal with these errors because I haven't seen them in the past on my GPU rigs...

Is this a normal behavior because the chips are simply regulating their clock speed on high error rates or should I check my setup?

I have a modminer quad and running > 10% hw error on bfgminer - is that normal?
oxident (OP)
Newbie
*
Offline Offline

Activity: 20
Merit: 0


View Profile
October 17, 2012, 06:11:42 AM
 #3

Someone told me it is. Like I guessed above, the HW error rates are absolutely okay because that's the only way for CGMiner to test if the board can handle the requested speed.

Please correct me if I'm wrong...
el_rlee
Legendary
*
Offline Offline

Activity: 1600
Merit: 1014



View Profile
October 17, 2012, 11:00:38 AM
 #4

Code:
Summary of runtime statistics:
                   
 [2012-10-17 18:57:36] Started at [2012-10-16 20:22:51]       
 [2012-10-17 18:57:36] Runtime: 22 hrs : 34 mins : 45 secs                   
 [2012-10-17 18:57:36] Average hashrate: 821.2 Megahash/s                   
 [2012-10-17 18:57:36] Solved blocks: 0                   
 [2012-10-17 18:57:36] Queued work requests: 3196                   
 [2012-10-17 18:57:36] Share submissions: 13601                   
 [2012-10-17 18:57:36] Accepted shares: 13338                   
 [2012-10-17 18:57:36] Rejected shares: 263                   
 [2012-10-17 18:57:36] Reject ratio: 1.9%                   
 [2012-10-17 18:57:36] Hardware errors: 2217                   
 [2012-10-17 18:57:36] Efficiency (accepted / queued): 417%                   
 [2012-10-17 18:57:36] Utility (accepted shares / min): 9.85/min
 [2012-10-17 18:57:36] Discarded work due to new blocks: 387                   
 [2012-10-17 18:57:36] Stale submissions discarded due to new blocks: 0                   
 [2012-10-17 18:57:36] Unable to get work from server occasions: 19                   
 [2012-10-17 18:57:36] Work items generated locally: 29637                   
 [2012-10-17 18:57:36] Submitting work remotely delay occasions: 1                   
 [2012-10-17 18:57:36] New blocks detected on network: 141
                   
 [2012-10-17 18:57:36] Summary of per device statistics:
                   
 [2012-10-17 18:57:36] MMQ0 53/50/48/40 C  | 5s:  0.0 avg:821.2 u:704.8 Mh/s | A:13338 R:263 HW:2217 U:9.8/m                   

2217/13338=16.6% of my hashing power goes to hardware errors? is that how it should be?
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!