Rig 4 & 7 stop mining and fall off miner-farm intermittently

  • We have a problem where a number of our rigs will randomly drop off miner farm & the ether pool. We can still SSH onto them so the network connection is fine, and sometimes the rigs show as mining with 12 cards, however, sometimes they stop mining all together....

    We have checked the config, connected wires and power supply, we cant find what is causing this problem.

    Can anyone advise how to generate some detailed logs for investigation, please?

  • Staff

    Some things to check:
    Ensure the time on your rigs is current, to the second. Small variances in time can cause reporting issues with both miner.farm and the pool.

    You can check the standard Linux system logs at /var/log/messages and /var/log/syslog

    Perform the 'ifconfig' command on the rig when it fails, and look for errors or dropped packets on your interface. There should be none (0, zero) otherwise you may have a bad NIC or cable or port somewhere.

    Please perform the 'helpme' command on a failing rig or two, and share the URL here so we can get a better look.

    Thank you for your support,

  • Hi Lily, I have just noticed the time on the rigs are completely wrong. How would I change the time please?

    With regards to the other troubleshooting provided, I will try those after the time thanks.

  • Staff

    I replied on another thread of yours about using ntp, cross check that. You can also use the date command as follows:

    First, run the date command without any options. This will get you an example string you can change, modify it and return it with the date --set="DATE_STRING" command. Here is an example where we set the time one hour ahead:

    [/root]:# date 
    Mon Jun 18 10:30:49 EDT 2018
    [Agent: m204-anjinRulez (Running) Total HR: [40.81Mh/s] Miners running [1] GPUs [AA]]
    [10:30 AM][Uptime: 0d 3:27][root@pimp2(]
    [/root]:# date --set="Mon Jun 18 11:30:49 EDT 2018"
    Mon Jun 18 11:30:49 EDT 2018
    [Agent: m204-anjinRulez (Running) Total HR: [40.90Mh/s] Miners running [1] GPUs [AA]]
    [11:30 AM][Uptime: 0d 3:28][root@pimp2(]
    [/root]:# date
    Mon Jun 18 11:30:51 EDT 2018

    But... You really should just make sure ntp is working right. The only thing that might be broken is your firewall rules. That would also mess with miner.farm.

    Good luck!

  • Hi, many thanks for your reply.

    I have updated the time manually as NTP was not populating with the correct time, it was around 5 hours out.

    When you say I should make sure NTP is working right, will this be a major issue? What firewall rules in particular can you suggest to look at?

    Kind regards

  • This is what I get when i try to set up ntp tme0_1529397227097_Capture.PNG

  • Please help @staff

  • Staff

    info21, please let me know what you feel the time should be. The above looks 100% correct, and it shows the time and date are correct.

  • The time should be BST, that is around 5 hours out.

  • Support

    Hello info21,

    I started looking this issue up and got lost in the horrible, horrible world of computers & time zones... Ugh. I found a really good write-up and included it here just for fun.

    The solution is to set your time server to one from your region. run:

    sudo service ntp stop
    sudo ntpdate uk.pool.ntp.org
    sudo service ntp start

    You could also run:
    dpkg-reconfigure tzdata
    Follow through the on-screen prompts to set the locale to Europe and then London. This then solves the issue and the computer should automatically stay at the correct time when the clocks change.

    Kinda funny video explaining the headaches of Time and Time Zones:
    The Problem with Time & Timezones - Computerphile

    FULL WRITE-UP: (Credit St├ęphane Chazelas)
    BST is something that is output upon date/date +%Z, to tell users that it's a British Summer Time date (so GMT+1) not something that defines a timezone, not something that you can use for $TZ.

    That BST is significant to British users. When a British user sees 14:00 BST, they know the timestamp refers to 14:00 summer time in mainland Britain (so 13:00 UTC). The use of those 3-4 letter codes is widespread in Britain, the US and some other English speaking countries, so show up in the default output of date there (in en_GB.UTF-8 locales for instance). On the other hand, most French users will have no idea what 14:00 CEST means (even though CEST refers to Central European Summer Time, the GMT+2 that applies in summer in France), so you'd notice that when dates specify the time zone, they rather include the UTC offset than CET/CEST there (like mardi 2 mai 2017, 13:34:09 (UTC+0200)).

    The $TZ variable is not meant to contain those 3-4 letter codes. It contains something that defines/specifies the timezone, the region you're in. Applications use it to know the offset with UTC at any point in time, when to switch between Winter and Summer time and what the code (if any) for the Winter and Summer time would be displayed to the user (for those users for whom it's significant).

    For that, you can either set TZ to some system-defined timezone specification. Like TZ=:Europe/London (though many systems also accept TZ=Europe/London as well), or have TZ contain the full rules (though those rules are limited).

    For instance, If I use TZ=:Europe/London on my system, then the rules will be read from /usr/share/zoneinfo/Europe/London.

    That file will specify for instance that since 1996, the offset from UTC is 0 from the last Sunday in October at 2am UTC to the last Sunday in March (with name GMT for "Greenwich Mean Time") and 1 other wise (with name BST for "British Summer Time"), while for 1970 (0 Unix time) to 1972, it was 1 all year round with name BST for "British Standard Time".

    You can see already that it makes no sense to use BST as a timezone specification. First, it has meant different things at different points in time, and even if we only consider the current epoch, it's only a code for the summer time, so can't be used to as a timezone specification for the whole year.

    Now, you can also have TZ contain the full rules. For instance for the "British Standard (not Summer) Time" of the early 70s, you can use the simplest form of specification:


    That specifies a timezone that is always 1 hour East of UTC and for which date +%Z always returns BST. That timezone is correct for mainland Britain for the early 70s and for summer time since 1972, but not for Winter time since 1972 (and we can't tell for the future).

    Or you can use the full specification for the current rules:


    That says that there are two periods in the year, one for which the name is GMT with offset 0, and one BST with offset 1 (implied as 0+1 above when not specified), where the switch from one to the other is on the last (5) Sunday (0) of March (3) at 1:00:00 UTC and back on the last sunday of October at 2:00.

    Again, that TZ works from 1996 to now, but not necessarily otherwise. For instance, for 1970-01-01 00:00:00 UTC (0 Unix epoch time, when the local time was 1:00:00 BST (British Standard Time) in London):

    $ TZ=:Europe/London date -d @0 Thu 1 Jan 01:00:00 BST 1970 $ TZ=GMT0BST,M3.5.0/1:00:00,M10.5.0/2:00:00 date -d @0 Thu 1 Jan 00:00:00 GMT 1970

    Per POSIX, the behaviour for

    • TZ=BST-1 is well defined (as described above)
    • TZ=BST or TZ=GMT/TZ=UTC/TZ=Europe/London) is unspecified.
    • TZ=:BST/TZ=:Europe/London is implementation defined. That is systems are meant to support it and document what that does though POSIX doesn't tell us what's that done.

    In the third case above, on GNU systems (and I believe most other Unix-like systems), when TZ starts with a :, what followed is taken as a path to a timezone definition file. In the case of GNU system, that's the case as well when : is omitted (even if the value forms a valid timezone specification like UTC0, but generally there shouldn't exist such files, though I can see some exceptions on my system which makes it a non-POSIX system (for instance TZ=CST6CDT date -d 1943-01-01 +%Z outputs CWT instead of CST because there's a /usr/share/zoneinfo/CST6CDT file that defines a war time for that period)).

    That path is generally a relative path, in which case it's relative to $TZDIR (or some default like /usr/share/zoneinfo when $TZDIR is unset as is generally the case). For security reasons, $TZDIR, absolute path or relative paths with .. components are ignored in privilege escalation contexts (like in setuid contexts).

    So typically, on a GNU system, a TZ=:BST, same as TZ=BST will typically look for a /usr/share/zoneinfo/BST file. If not found (as would be the case, as BST can't possibly identify a timezone definition), it will typically assume UTC time and a timezone name (as in date +%Z output) of BST

  • Wow thank you so much!!! I really appreciate your help!! Running dpkg-reconfigure tzdata worked a charm

  • Support

    No problem. Glad you got it sorted out. PiMPs helping PiMPs.

  • Staff

    Incorrect time on a rig is the number one reason an agent will report intermittently (or not at all) to miner.farm.

    Thank you Doc for a fantastic and detailed write up on solutions to the problem!



Want 10% more hash from your rigs?

We promise to keep your email safe and never spam you.

Copyright (c) 2017 PiMP LLC. All rights Reserved.

Looks like your connection to PiMP Forum was lost, please wait while we try to reconnect.