<<  >> (p.668)
    Author Topic: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.11.1  (Read 5806560 times)
    This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic. (3 posts by 1+ user deleted.)
    os2sam
    Legendary
    *
    Offline Offline

    Activity: 3586
    Merit: 1099


    Think for yourself


    View Profile
    November 09, 2013, 09:01:08 PM
    Last edit: November 10, 2013, 06:26:33 PM by os2sam
     #13341

    I have two block erupters that are producing about a Ths for me.  That would be great if weren't a Ths of Hardware errors.  I have seen others report very high hash rates for BE's but I don't remember what the consensus was.  Is this a BE, Hub or CGMiner issue?  Any insight would be appreciated.
    Sam
    It normally takes a 335MH device ~12.8 seconds to check all nonces in a single work item. The BEs use the icarus protocol which means as soon as they find a result, they report it back and then stop working. This can happen anywhere between zero and 12.8 seconds. The driver then gives it more work and the cycle starts all over again. If you can imagine the device coming back with a "result" in say .1 second and does this every time, the driver probably thinks it's running at a terrahash. However if it's a wrong result most of the time, it's meaningless. The driver shouldn't really be reporting it back as 1TH then so it's a mistake in the calculation in the driver. Kano might want to chime in since he wrote most of the driver.
    This happens when you use the timing option (short or long) and the documentation reference in FPGA-README is:

    'short' or 'long' mode should only be used on a computer that has enough CPU available to run
    cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough)
    Any CPU delays while calculating the hash time will affect the result
    'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
    'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
    corrects itself

    TL;DR - Don't use a timing option any more.

    Hmm, I'm not using any timing options. I just use --usb BAS:0 in my Erupter instance so that it doesn't try to capture the Jalapeno.

    I did find this earlier and it has seemed to resolve the behavior.

    Thanks,
    Sam

    High hash with bfgm and a Pi is a sign of low current to the hubs.  With good current expect to see 333+/- 5

    Thank you for this insight.  I believe you are 100%, or so, correct.

    I have the new 49 Port hub and had it loaded with 47 Erupters and two Arctic Breeze fans.  Two BE's were showing over 1Ths with virtually no shares submitted.  After reading this part of your post I dropped it to 40 BE's and the two fans and it is finally stable.

    Win7 64 bit.
    CGMiner 3.7.2

    Thanks again,
    Sam

    Edit: overnight I had two more BE's start reporting GHs range.  So I dropped my erupter count down to 35 on the 49 port hub.  So I'm not sure that the above has anything to do with my problem.

    A: Because it messes up the order in which people normally read text.
    Q: Why is top-posting such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
Page 667
Viewing Page: 668