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?
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.
I replied on another thread of yours about using
ntp, cross check that. You can also use the
datecommand as follows:
First, run the
datecommand 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  GPUs [AA]] [10:30 AM][Uptime: 0d 3:27][root@pimp2(10.0.0.204)] [/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  GPUs [AA]] [11:30 AM][Uptime: 0d 3:28][root@pimp2(10.0.0.204)] [/root]:# date Mon Jun 18 11:30:51 EDT 2018
But... You really should just make sure
ntpis working right. The only thing that might be broken is your firewall rules. That would also mess with
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?
info21 last edited by info21
This is what I get when i try to set up ntp tme
Please help @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.
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:
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
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
en_GB.UTF-8locales for instance). On the other hand, most French users will have no idea what
14:00 CESTmeans (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
mardi 2 mai 2017, 13:34:09 (UTC+0200)).
$TZvariable 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
TZto some system-defined timezone specification. Like
TZ=:Europe/London(though many systems also accept
TZ=Europe/Londonas well), or have
TZcontain the full rules (though those rules are limited).
For instance, If I use
TZ=:Europe/Londonon my system, then the rules will be read from
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
TZcontain 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 +%Zalways 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-1is well defined (as described above)
TZ=GMT/TZ=UTC/TZ=Europe/London) is unspecified.
TZ=:BST/TZ=:Europe/Londonis 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
TZstarts 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 +%Zoutputs
CSTbecause there's a
/usr/share/zoneinfo/CST6CDTfile 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
$TZDIRis 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=BSTwill typically look for a
/usr/share/zoneinfo/BSTfile. If not found (as would be the case, as
BSTcan't possibly identify a timezone definition), it will typically assume
UTCtime and a timezone name (as in
date +%Zoutput) of
Wow thank you so much!!! I really appreciate your help!! Running dpkg-reconfigure tzdata worked a charm
No problem. Glad you got it sorted out. PiMPs helping PiMPs.
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!
We promise to keep your email safe and never spam you.
Copyright (c) 2017 PiMP LLC. All rights Reserved.