More stable perhaps, but less efficient. The bulk of power use in a CMOS IC is the charge required to flip the transistors on and off. The current use is proportional to frequency for obvious reasons - more flips per second means more electrons moving back and forth per second. In order to flip fast enough, a higher voltage might be required in order to have more "pressure" pushing those electrons into and out of the gates fast enough to keep up, so voltage tends to increase as frequency increases. This is where your efficiency comes into play. For a given voltage, the power use is directly proportional to frequency, but as frequency increases the voltage has to as well - so power use increases from both voltage and current increases, which means more overall power per unit work.
Bitmain's original S5 announcement post (https://bitcointalksearch.org/topic/antminer-s5-1155ghoverclock-potential-in-stock-0319gh-051wgh-902305) has a chart for this.
Topic: GekkoScience 2Pac/Compac BM1384 Stickminer Official Support Thread - page 56. (Read 177410 times)
December 15, 2017, 01:57:31 PM
December 15, 2017, 01:22:57 PM
Voltage has nothing to do with the workload, just the hardware's stability. In general, the higher the voltage at a given frequency, the more stable it'll be (until heat or junction breakdowns become an issue).
The amount of work done is proportional to the operating frequency. I see about WU 1.53/MHz with a 2-chip stick, so 225MHz should run about 344 - plus or minus, because USB traffic and pool latency and whatever.
And that's what I am seeing now, OK thanks for the confirmation! Ok I'll Bump them back up to 250Mhz, And return the voltage to 1.4 as that seemed to be running fine. I just wanted to see if the 2pacs would be more efficient or stable at the lower clock with higher volt. The amount of work done is proportional to the operating frequency. I see about WU 1.53/MHz with a 2-chip stick, so 225MHz should run about 344 - plus or minus, because USB traffic and pool latency and whatever.
December 15, 2017, 01:11:14 PM
Voltage has nothing to do with the workload, just the hardware's stability. In general, the higher the voltage at a given frequency, the more stable it'll be (until heat or junction breakdowns become an issue).
The amount of work done is proportional to the operating frequency. I see about WU 1.53/MHz with a 2-chip stick, so 225MHz should run about 344 - plus or minus, because USB traffic and pool latency and whatever.
The amount of work done is proportional to the operating frequency. I see about WU 1.53/MHz with a 2-chip stick, so 225MHz should run about 344 - plus or minus, because USB traffic and pool latency and whatever.
December 15, 2017, 12:53:26 PM
...
I have noticed as well initial WU is down by 40 per 2pac. average per 2pac at 250/1.40 was 383, on restart at 225/1.46 showing 340, expecting that number to rise over the next few hours though.
I'm wondering if anyone else has tried this, and what where your results?
That appears in range. WU change is proportional to freq. About a 10% change in each there.
more details:
https://bitcointalksearch.org/topic/m.18329715
December 15, 2017, 12:48:34 PM
...
I have noticed as well initial WU is down by 40 per 2pac. average per 2pac at 250/1.40 was 383, on restart at 225/1.46 showing 340, expecting that number to rise over the next few hours though.
I'm wondering if anyone else has tried this, and what where your results?
That appears in range. WU change is proportional to freq. About a 10% change in each there.
more details:
https://bitcointalksearch.org/topic/m.18329715
December 15, 2017, 12:26:48 PM
https://i.imgur.com/X8LLLZF.jpg
Running an experiment, Trying with initial settings of 250Mhz*1.40v and changing to 225Mhz*1.46v to see if I can get better stability out of the 2pacs.
So far temp with addition fan cooling and 5C ART has not changed, 45C probe reading at the heat-sink from 2pac at centre of array, 61C-65C IR reading from the 2pac boards outer row.
I have noticed as well initial WU is down by 40 per 2pac. average per 2pac at 250/1.40 was 383, on restart at 225/1.46 showing 340, expecting that number to rise over the next few hours though.
I'm wondering if anyone else has tried this, and what where your results?
Running an experiment, Trying with initial settings of 250Mhz*1.40v and changing to 225Mhz*1.46v to see if I can get better stability out of the 2pacs.
So far temp with addition fan cooling and 5C ART has not changed, 45C probe reading at the heat-sink from 2pac at centre of array, 61C-65C IR reading from the 2pac boards outer row.
I have noticed as well initial WU is down by 40 per 2pac. average per 2pac at 250/1.40 was 383, on restart at 225/1.46 showing 340, expecting that number to rise over the next few hours though.
I'm wondering if anyone else has tried this, and what where your results?
December 14, 2017, 12:54:03 AM
Let's see what's connected:
Code:
sudo cat /sys/kernel/debug/usb/devices | grep -E "^([TSPD]:.*|)$"
December 14, 2017, 12:39:35 AM
i have installed cgminer on RPi as per first post
cgminer starts but it does not detect my gekko 2 PAC sticks either 3 in a hub or just one alone in RPi
what could i be missing
any sugestions
how about one in a hub?
have one in a hub, everything connected, then restart the pi, then start the cgminer.
no luck already tried one in hub and tried again cuz you sugested
[2017-12-13 21:37:04.857] Started cgminer 4.10.0
[2017-12-13 21:37:04.857] Loaded configuration file /home/pi/.cgminer/cgminer.c
onf
[2017-12-13 21:37:05.024] No devices detected!
[2017-12-13 21:37:05.024] Waiting for USB hotplug devices or press q to quit
[2017-12-13 21:37:05.024] Probing for an alive pool
[2017-12-13 21:37:06.993] Pool 0 difficulty changed to 2048
[2017-12-13 21:37:07.036] Pool 1 difficulty changed to 2048
[2017-12-13 21:37:08.026] Network diff set to 1.59T
December 14, 2017, 12:19:12 AM
i have installed cgminer on RPi as per first post
cgminer starts but it does not detect my gekko 2 PAC sticks either 3 in a hub or just one alone in RPi
what could i be missing
any sugestions
how about one in a hub?
have one in a hub, everything connected, then restart the pi, then start the cgminer.
December 13, 2017, 11:44:38 PM
i have installed cgminer on RPi as per first post
cgminer starts but it does not detect my gekko 2 PAC sticks either 3 in a hub or just one alone in RPi
what could i be missing
any sugestions
December 13, 2017, 08:59:06 PM
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have the same exact problem and haven't been able to narrow down the issue despite trying. Sometimes it lasts a few hours and other times 24+ hours. Then randomly the 2pacs stop blinking and the Pi cannot be reached via VNC Viewer or Putty and I have to pull/plug the power to get it running again. I know that is not an answer to your question but figured it wouldn't hurt to know you are not the only one to have this problem.
I may have caught it in the act earlier today when I saw the 2pacs all reducing their hashrate and going zombie but stopped it and restarted no problem. I should have let it play out to see if that was the issue but didn't think about it at the time.
Yes, this is pretty much exactly what is happening to me. Did you happen to be watching the hashrate at the time? I'm not sure how to troubleshoot it or where to start.
All I remember seeing is one stick registering as "SICK" and the others slowly reducing their hashrate. I remember seeing two around 800 MH/s and I think another was 200... Another odd thing is that after I stopped cgminer and attempted to restart the Pi using sudo reboot, it didn't restart. Once again I had to pull the plug and do a hard restart then as always everything started working again no problem.
I wish I could figure it out but I just don't know enough yet to narrow it down further. I did re-flash the raspian image about a month ago to see if it would help but that didn't do anything.
Something worth reviewing and trying out if the kernel is going down:
https://bitcointalksearch.org/topic/m.5932931
December 13, 2017, 11:28:40 AM
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have the same exact problem and haven't been able to narrow down the issue despite trying. Sometimes it lasts a few hours and other times 24+ hours. Then randomly the 2pacs stop blinking and the Pi cannot be reached via VNC Viewer or Putty and I have to pull/plug the power to get it running again. I know that is not an answer to your question but figured it wouldn't hurt to know you are not the only one to have this problem.
I may have caught it in the act earlier today when I saw the 2pacs all reducing their hashrate and going zombie but stopped it and restarted no problem. I should have let it play out to see if that was the issue but didn't think about it at the time.
Yes, this is pretty much exactly what is happening to me. Did you happen to be watching the hashrate at the time? I'm not sure how to troubleshoot it or where to start.
All I remember seeing is one stick registering as "SICK" and the others slowly reducing their hashrate. I remember seeing two around 800 MH/s and I think another was 200... Another odd thing is that after I stopped cgminer and attempted to restart the Pi using sudo reboot, it didn't restart. Once again I had to pull the plug and do a hard restart then as always everything started working again no problem.
I wish I could figure it out but I just don't know enough yet to narrow it down further. I did re-flash the raspian image about a month ago to see if it would help but that didn't do anything.
I pulled up the info in /var/log/syslog and it shows this....
Code:
Dec 12 22:17:58 rPints snmpd[417]: Connection from UDP: [192.168.0.138]:46897->[192.168.0.121]:161
Dec 12 22:17:58 rPints snmpd[417]: Connection from UDP: [192.168.0.138]:49198->[192.168.0.121]:161
Dec 12 22:18:01 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:06 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:11 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:16 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:21 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:26 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:31 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:36 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:41 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:46 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Dec 12 22:17:12 rPints systemd-modules-load[117]: Inserted module 'i2c_dev'
Dec 12 22:17:12 rPints fake-hwclock[107]: Wed 13 Dec 06:17:01 UTC 2017
Dec 12 22:17:12 rPints systemd-fsck[111]: e2fsck 1.43.4 (31-Jan-2017)
Dec 12 22:17:12 rPints systemd-fsck[111]: Superblock last mount time (Tue Dec 12 13:17:01 2017,
Dec 12 22:17:12 rPints kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Dec 12 22:17:12 rPints kernel: [ 0.000000] Linux version 4.9.60-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #1048 SMP Fri Nov 3 16:05:21 GMT 2017
Dec 12 22:17:12 rPints kernel: [ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
Dec 12 22:17:58 rPints snmpd[417]: Connection from UDP: [192.168.0.138]:49198->[192.168.0.121]:161
Dec 12 22:18:01 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:06 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:11 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:16 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:21 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:26 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:31 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:36 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
Dec 12 22:18:41 rPints vncserver-x11[434]: AgentInitCheck: no response from agent
Dec 12 22:18:46 rPints vncserver-x11[434]: AgentInitCheck: agent comms failure
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@Dec 12 22:17:12 rPints systemd-modules-load[117]: Inserted module 'i2c_dev'
Dec 12 22:17:12 rPints fake-hwclock[107]: Wed 13 Dec 06:17:01 UTC 2017
Dec 12 22:17:12 rPints systemd-fsck[111]: e2fsck 1.43.4 (31-Jan-2017)
Dec 12 22:17:12 rPints systemd-fsck[111]: Superblock last mount time (Tue Dec 12 13:17:01 2017,
Dec 12 22:17:12 rPints kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Dec 12 22:17:12 rPints kernel: [ 0.000000] Linux version 4.9.60-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #1048 SMP Fri Nov 3 16:05:21 GMT 2017
Dec 12 22:17:12 rPints kernel: [ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
at which point i stopped responding to snmp/ping.
this morning i did a hard reset/unplug and the next entries are....
Code:
Dec 12 22:17:33 rPints vncserver-x11[431]: AgentInitCheck: agent comms failure
Dec 12 22:17:38 rPints vncserver-x11[431]: AgentInitCheck: no response from agent
Dec 13 06:58:39 rPints systemd[1]: Time has been changed
Dec 13 06:58:39 rPints systemd[557]: Time has been changed
Dec 12 22:17:38 rPints vncserver-x11[431]: AgentInitCheck: no response from agent
Dec 13 06:58:39 rPints systemd[1]: Time has been changed
Dec 13 06:58:39 rPints systemd[557]: Time has been changed
I am guessing that there was something that caused the crash, and it rebooted. But then there are no entries from after the reboot until after I hard reset this morning.
December 13, 2017, 08:21:35 AM
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have the same exact problem and haven't been able to narrow down the issue despite trying. Sometimes it lasts a few hours and other times 24+ hours. Then randomly the 2pacs stop blinking and the Pi cannot be reached via VNC Viewer or Putty and I have to pull/plug the power to get it running again. I know that is not an answer to your question but figured it wouldn't hurt to know you are not the only one to have this problem.
I may have caught it in the act earlier today when I saw the 2pacs all reducing their hashrate and going zombie but stopped it and restarted no problem. I should have let it play out to see if that was the issue but didn't think about it at the time.
Yes, this is pretty much exactly what is happening to me. Did you happen to be watching the hashrate at the time? I'm not sure how to troubleshoot it or where to start.
All I remember seeing is one stick registering as "SICK" and the others slowly reducing their hashrate. I remember seeing two around 800 MH/s and I think another was 200... Another odd thing is that after I stopped cgminer and attempted to restart the Pi using sudo reboot, it didn't restart. Once again I had to pull the plug and do a hard restart then as always everything started working again no problem.
I wish I could figure it out but I just don't know enough yet to narrow it down further. I did re-flash the raspian image about a month ago to see if it would help but that didn't do anything.
December 13, 2017, 08:17:21 AM
as per first post
Are you sure about this part? Because everything you just said doesn't make sense with the info given in the first post. There are sample command lines given in the first post, complete with options for adjusting frequency and stuff.
December 13, 2017, 03:26:32 AM
i installed cgminer on a Pi as per first post with gekko 2 PAC i can not figure out how to start mining.
my old command that i used now does not do anything
sudo ./git/vthoang/cgminer --bmsc-options 115200:0.57 -o stratum+tcp://stratum.slushpool.com:3333-u smsscott.pi -p sailing --bmsc-voltage 0800 --bmsc-freq 1286
./cgminer -o stratum+tcp://stratum.slushpool.com:3333 -u smsscott.pi -p sailing –bxm-bits=56
cgminer -o stratum+tcp://stratum.slushpool.com:3333 -u smsscott.pi -p sailing
git/vthoang/cgminer/cgminer.c -o stratum+tcp://stratum.slushpool.com:3333 -u smsscott.pi -p sailing
none of these will start cgminer what do i have wrong....?
i am new to Pi and mining i had installed cgminer with out the gekko support and could not enable 2 PAC stick it was in cgminer directory not like this one which is in the
"git/vthoang/cgminer" directory...? not cgminer directory like before
can anyone help me please....?
December 12, 2017, 10:13:06 PM
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have the same exact problem and haven't been able to narrow down the issue despite trying. Sometimes it lasts a few hours and other times 24+ hours. Then randomly the 2pacs stop blinking and the Pi cannot be reached via VNC Viewer or Putty and I have to pull/plug the power to get it running again. I know that is not an answer to your question but figured it wouldn't hurt to know you are not the only one to have this problem.
I may have caught it in the act earlier today when I saw the 2pacs all reducing their hashrate and going zombie but stopped it and restarted no problem. I should have let it play out to see if that was the issue but didn't think about it at the time.
Yes, this is pretty much exactly what is happening to me. Did you happen to be watching the hashrate at the time? I'm not sure how to troubleshoot it or where to start.
December 12, 2017, 08:13:11 PM
OS X El Capitan (10.11.6)
#if no errors:
Code:
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew doctor
brew tap vthoang/cgminer
brew install cgminer
brew doctor
brew tap vthoang/cgminer
brew install cgminer
#if no errors:
Code:
$ cgminer -n
[2017-12-12 17:08:23.377] USB all: found 8 devices - listing known devices
.USB dev 0: Bus 20 Device 24 ID: 10c4:ea60
Manufacturer: 'GekkoScience'
Product: '2Pac BM1384 Bitcoin Miner'
[2017-12-12 17:08:23.378] 1 known USB devices
[2017-12-12 17:08:23.377] USB all: found 8 devices - listing known devices
.USB dev 0: Bus 20 Device 24 ID: 10c4:ea60
Manufacturer: 'GekkoScience'
Product: '2Pac BM1384 Bitcoin Miner'
[2017-12-12 17:08:23.378] 1 known USB devices
Code:
cgminer -o stratum+tcp://pool.ckpool.org:3333 -u 1BURGERAXHH6Yi6LRybRJK7ybEm5m5HwTr -p x --suggest-diff 32
December 12, 2017, 07:21:06 PM
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have the same exact problem and haven't been able to narrow down the issue despite trying. Sometimes it lasts a few hours and other times 24+ hours. Then randomly the 2pacs stop blinking and the Pi cannot be reached via VNC Viewer or Putty and I have to pull/plug the power to get it running again. I know that is not an answer to your question but figured it wouldn't hurt to know you are not the only one to have this problem.
I may have caught it in the act earlier today when I saw the 2pacs all reducing their hashrate and going zombie but stopped it and restarted no problem. I should have let it play out to see if that was the issue but didn't think about it at the time.
December 12, 2017, 07:17:10 PM
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I get lockups with my zero on the odd occasion, I've never really found a solution. Running cgminer with the real-quiet and net-delay switches helped a lot though. Other than that, I've read suggestions that it could be: the pi hitting a ram limit, possibly a usb library hiccup, maybe sd card quality, but none seemed definitive. There's some old (different hw) discussion here which might shed some light, or maybe one of this thread's veterans might be able to chime in with something more concrete that I might have missed in this thread. I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
December 12, 2017, 07:13:19 PM
Hello All, I've been going through this thread trying to see any similar issues to what I'm seeing with no luck so far.
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
I have just setup a new RaspberrPi3 with the latest Raspian image. I have been able to get the vthoang cgminer 4.10 setup and working, and with two(2) 2pac on a powered USB hub the SW launches and logs into my pool with no problems. I'm running at the default freq of 100 for now. After some amt of time, anywhere from 2-6hrs the Pi seems to crash and is unreachable. I'm not exactly sure where to start to see what kind of problem I'm running into. the Pi is running headless so there is no screen to look at. Any suggestions?
Do you have any logs to post? Which hub?
Apart from this, maybe use an Arctic fan (or any other fan pretty much) and point it to sticks.
Second, separate the sticks, if possible (have a slot in between).
Jump to: