[OS] nvOC easy-to-use Linux Nvidia Mining - page 29.

CryptAtomeTrader44

full member

Activity: 340

Merit: 103

It is easier to break an atom than partialities AE

Quote from: thaelin on May 04, 2018, 04:25:57 AM

Quote from: CryptAtomeTrader44 on May 03, 2018, 07:05:28 PM

Bad news about Equihash :

Bitmain launch Equihash ASIC this day. 10 KSol/s consumming only 300W !

What do you think about this ASIC ?

https://shop.bitmain.com/product/detail?pid=00020180503154806494uGcSyiu806FD

I said that I do not come to promote them, I did not buy ASIC but it is quite clear that this case will pose a huge problem. Much worse than that of the ETH miner of the same company.

Only the Monéro community reacted in opposition to the bitmain ASICS. I simply wish to have your opinion on this issue which may make GPU mining obsolete on this algorithm rather quickly.

At this rate, only Neoscrypt and Cryptonight V7 will remain to be mined via CPU and GPU. Not a good deal for decentralization as a cryptocurrency target.

One rig 22mhX6 for 132MH drawing 680w VS 10Kh @300W is going to be a threat? Where?
Oh and each unit does cost 2K and you can only have one for now. Hmmmmm.
thay

Yes, a threat to the profitability of every coins that uses the Equihash algo.
The coins are massively produced for cheap which will reduce the profitability of RIGs graphics cards that consume much more and produce much less (as you indicate).The difficulty will also increase very strongly in a very short time.

Yes, it costs $ 2,000 for now but how many KSol can you produce with a rig at this price? Certainly much less.

So I'm not convinced by your answer a little too evasive.

WaveFront

member

Activity: 126

Merit: 10

Quote from: papampi on May 04, 2018, 05:28:36 AM

Quote from: thaelin on May 04, 2018, 04:25:57 AM

Quote from: CryptAtomeTrader44 on May 03, 2018, 07:05:28 PM

Bad news about Equihash :

Bitmain launch Equihash ASIC this day. 10 KSol/s consumming only 300W !

What do you think about this ASIC ?

https://shop.bitmain.com/product/detail?pid=00020180503154806494uGcSyiu806FD

I said that I do not come to promote them, I did not buy ASIC but it is quite clear that this case will pose a huge problem. Much worse than that of the ETH miner of the same company.

Only the Monéro community reacted in opposition to the bitmain ASICS. I simply wish to have your opinion on this issue which may make GPU mining obsolete on this algorithm rather quickly.

At this rate, only Neoscrypt and Cryptonight V7 will remain to be mined via CPU and GPU. Not a good deal for decentralization as a cryptocurrency target.

One rig 22mhX6 for 132MH drawing 680w VS 10Kh @300W is going to be a threat? Where?
Oh and each unit does cost 2K and you can only have one for now. Hmmmmm.
thay

Its equihash not ethash ...

For Ethash there is the Antiminer E3. Price and power consumption is not radically better than a GPU rig with an equivalent hash rate

Stubo

member

Activity: 224

Merit: 13

Quote from: urnzwy on May 04, 2018, 02:58:29 PM

Quote from: Stubo on May 04, 2018, 02:51:26 PM

Quote from: urnzwy on May 04, 2018, 02:03:59 PM

Found them! There is a lot in there... But I am not sure what I am looking for. There is some warnings I see in there, all the files look identical almost. Are you in the discord? I could send it to you on there? This is the last portion of it.

I am not in the discord. There is going to be a LOT of stuff in the syslog and most of it you can ignore. What you want to do is to zero in on the entries just before it froze. This is all done by timestamps. You can also look for entries that are hard errors but those may prove to be red herrings.

If you notice there are syslogs going back about a week. syslog is from today, syslog.1 is going to be yesterday, syslog.2.gz is the archived syslog from the day before that, etc. For the gz ones, just use "gunzip " as root to unzip them so that you can read them.

So start by recalling the day and time of the last freeze(s), and then figure out which log it would be in based upon the timestamp of the syslogs. Next, open whichever one(s) those are and find that day/time. You should then see additional clues (probably errors) that were logged. Once you find them, we can go from there.

Updated the previous post to include the last portion of the files.

It froze every day and all the files looks the same, so whatever this issue is it just happens over and over again.

Let me see if I can make it more clear. Unlike some nvOC specific logs, Ubuntu [any unix system] syslogs are written to constantly, so grabbing the last (most recent) part of one is unlikely to be helpful in diagnosing your problem. Instead, what you want to do is view the logs with an editor like vi and scroll through it until you find the day and time of when the freeze occurred.

For example, I had an issue with one of my miners on Wednesday morning. My pool indicated that it was not mining so tried to login via ssh but could not. I physically checked on the machine and it was running but I could not access it remotely (I don't have a display connected to it). So, I powered it down for a few minutes and then powered it back up. It came up just fine and started mining again. Of course, I wanted to find out what had happened so I started looking at my syslog for that day and at that time - sometime after 9:30am on May 2. When I found that part of the log, I saw this:

Code:

May 2 07:35:02 Miner1 anacron[30615]: Job `cron.daily' terminated
May 2 07:35:02 Miner1 anacron[30615]: Normal exit (1 job run)
May 2 08:17:01 Miner1 CRON[16925]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
May 2 08:24:20 Miner1 systemd[1]: Starting Cleanup of Temporary Directories...
May 2 08:24:20 Miner1 systemd-tmpfiles[19789]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
May 2 08:24:20 Miner1 systemd[1]: Started Cleanup of Temporary Directories.
May 2 09:17:01 Miner1 CRON[8112]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
[b]May 2 09:46:17 Miner1 avahi-daemon[821]: Withdrawing address record for 192.168.1.165 on enp0s31f6.
May 2 09:46:17 Miner1 avahi-daemon[821]: Leaving mDNS multicast group on interface enp0s31f6.IPv4 with address 192.168.1.165.
May 2 09:46:17 Miner1 avahi-daemon[821]: Interface enp0s31f6.IPv4 no longer relevant for mDNS.
[/b]May 2 10:17:01 Miner1 CRON[23962]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
May 2 10:23:30 Miner1 systemd[1]: Starting Daily apt download activities...
May 2 10:23:30 Miner1 systemd[1]: Started Daily apt download activities.
May 2 11:17:01 Miner1 CRON[32329]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
May 2 12:17:01 Miner1 CRON[8511]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
May 2 12:43:29 Miner1 rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="846" x-info="http://www.rsyslog.com"] start

So for some still to be determined reason, my machine decided to withdraw its DNS registration from my DNS which resulted in loss of name resolution and connectivity.

While not at all relevant to your situation, I just wanted to use this example of an issue that I had, how I found it, and what caused it.

I hope this helps.

urnzwy

newbie

Activity: 44

Merit: 0

Quote from: Stubo on May 04, 2018, 02:51:26 PM

Quote from: urnzwy on May 04, 2018, 02:03:59 PM

Found them! There is a lot in there... But I am not sure what I am looking for. There is some warnings I see in there, all the files look identical almost. Are you in the discord? I could send it to you on there? This is the last portion of it.

I am not in the discord. There is going to be a LOT of stuff in the syslog and most of it you can ignore. What you want to do is to zero in on the entries just before it froze. This is all done by timestamps. You can also look for entries that are hard errors but those may prove to be red herrings.

If you notice there are syslogs going back about a week. syslog is from today, syslog.1 is going to be yesterday, syslog.2.gz is the archived syslog from the day before that, etc. For the gz ones, just use "gunzip " as root to unzip them so that you can read them.

So start by recalling the day and time of the last freeze(s), and then figure out which log it would be in based upon the timestamp of the syslogs. Next, open whichever one(s) those are and find that day/time. You should then see additional clues (probably errors) that were logged. Once you find them, we can go from there.

Updated the previous post to include the last portion of the files.

It froze every day and all the files looks the same, so whatever this issue is it just happens over and over again.

Stubo

member

Activity: 224

Merit: 13

Quote from: urnzwy on May 04, 2018, 02:03:59 PM

Found them! There is a lot in there... But I am not sure what I am looking for. There is some warnings I see in there, all the files look identical almost. Are you in the discord? I could send it to you on there? This is the last portion of it.

I am not in the discord. There is going to be a LOT of stuff in the syslog and most of it you can ignore. What you want to do is to zero in on the entries just before it froze. This is all done by timestamps. You can also look for entries that are hard errors but those may prove to be red herrings.

If you notice there are syslogs going back about a week. syslog is from today, syslog.1 is going to be yesterday, syslog.2.gz is the archived syslog from the day before that, etc. For the gz ones, just use "gunzip " as root to unzip them so that you can read them.

So start by recalling the day and time of the last freeze(s), and then figure out which log it would be in based upon the timestamp of the syslogs. Next, open whichever one(s) those are and find that day/time. You should then see additional clues (probably errors) that were logged. Once you find them, we can go from there.

urnzwy

newbie

Activity: 44

Merit: 0

Quote from: Stubo on May 04, 2018, 01:15:59 PM

Quote from: urnzwy on May 04, 2018, 01:10:53 PM

m1@m1-desktop:~$ cat /etc/logrotate.d/rsyslog
/var/log/syslog
{
   rotate 7
   daily
   missingok
   notifempty
   delaycompress
   compress
   postrotate
      invoke-rc.d rsyslog rotate > /dev/null
   endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
   rotate 4
   weekly
   missingok
   notifempty
   compress
   delaycompress
   sharedscrip

Great, do you do have syslogs dating back a week to inspect. Namely these:

Code:

-rw-r----- 1 syslog adm 221063 May 4 11:03 syslog
-rw-r----- 1 syslog adm 480516 May 4 07:43 syslog.1
-rw-r----- 1 syslog adm 71338 May 3 10:28 syslog.2.gz
-rw-r----- 1 syslog adm 101993 May 2 08:56 syslog.3.gz
-rw-r----- 1 syslog adm 70681 May 1 07:35 syslog.4.gz
-rw-r----- 1 syslog adm 37431 Apr 30 19:00 syslog.5.gz
-rw-r----- 1 syslog adm 8234 Apr 29 07:35 syslog.6.gz
-rw-r----- 1 syslog adm 8185 Apr 28 07:35 syslog.7.gz

You should be able to go back through them and align your "freezes" with what is in them for those times.

Found them! There is a lot in there... But I am not sure what I am looking for. There is some warnings I see in there, all the files look identical almost. Are you in the discord? I could send it to you on there? This is the last portion of it.

May 2 08:54:13 m1-desktop rtkit-daemon[2515]: Successfully made thread 2514 of process 2514 (n/a) owned by '1000' high priority at nice level -11.
May 2 08:54:13 m1-desktop rtkit-daemon[2515]: Supervising 1 threads of 1 processes of 1 users.
May 2 08:54:13 m1-desktop dbus[821]: [system] Activating via systemd: service name='org.freedesktop.UPower' unit='upower.service'
May 2 08:54:13 m1-desktop systemd[1]: Starting Daemon for power management...
May 2 08:54:13 m1-desktop gnome-session[2410]: gnome-session-binary[2410]: WARNING: Could not parse desktop file print-applet.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session-binary[2410]: WARNING: Could not parse desktop file print-applet.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session[2410]: gnome-session-binary[2410]: WARNING: Could not parse desktop file indicator-printers.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session-binary[2410]: WARNING: Could not parse desktop file indicator-printers.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop dbus[821]: [system] Successfully activated service 'org.freedesktop.UPower'
May 2 08:54:13 m1-desktop systemd[1]: Started Daemon for power management.
May 2 08:54:13 m1-desktop gnome-session[2410]: gnome-session-binary[2410]: WARNING: Could not parse desktop file gnome-user-share-webdav.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session-binary[2410]: WARNING: Could not parse desktop file gnome-user-share-webdav.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session[2410]: gnome-session-binary[2410]: WARNING: Could not parse desktop file deja-dup-monitor.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session-binary[2410]: WARNING: Could not parse desktop file deja-dup-monitor.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session[2410]: gnome-session-binary[2410]: WARNING: Could not parse desktop file orca-autostart.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session-binary[2410]: WARNING: Could not parse desktop file orca-autostart.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session[2410]: gnome-session-binary[2410]: WARNING: Could not parse desktop file zeitgeist-datahub.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session-binary[2410]: WARNING: Could not parse desktop file zeitgeist-datahub.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session[2410]: gnome-session-binary[2410]: WARNING: Could not parse desktop file onboard-autostart.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session-binary[2410]: WARNING: Could not parse desktop file onboard-autostart.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session[2410]: gnome-session-binary[2410]: WARNING: Could not parse desktop file gnome-user-share-obexpush.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session-binary[2410]: WARNING: Could not parse desktop file gnome-user-share-obexpush.desktop or it references a not found TryExec binary
May 2 08:54:13 m1-desktop gnome-session[2410]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
May 2 08:54:13 m1-desktop gnome-session[2410]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
May 2 08:54:13 m1-desktop gnome-session[2410]: SSH_AUTH_SOCK=/run/user/1000/keyring/ssh
May 2 08:54:14 m1-desktop dbus[821]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service'
May 2 08:54:14 m1-desktop systemd[1]: Starting Manage, Install and Generate Color Profiles...
May 2 08:54:14 m1-desktop dbus[821]: [system] Successfully activated service 'org.freedesktop.ColorManager'
May 2 08:54:14 m1-desktop systemd[1]: Started Manage, Install and Generate Color Profiles.
May 2 08:54:15 m1-desktop rtkit-daemon[2515]: Supervising 1 threads of 1 processes of 1 users.
May 2 08:54:15 m1-desktop rtkit-daemon[2515]: Successfully made thread 2664 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:15 m1-desktop rtkit-daemon[2515]: Supervising 2 threads of 1 processes of 1 users.
May 2 08:54:16 m1-desktop dbus[821]: [system] Activating via systemd: service name='org.freedesktop.UDisks2' unit='udisks2.service'
May 2 08:54:16 m1-desktop systemd[1]: Starting Disk Manager...
May 2 08:54:16 m1-desktop udisksd[2670]: udisks daemon version 2.1.7 starting
May 2 08:54:16 m1-desktop dbus[821]: [system] Successfully activated service 'org.freedesktop.UDisks2'
May 2 08:54:16 m1-desktop systemd[1]: Started Disk Manager.
May 2 08:54:16 m1-desktop udisksd[2670]: Acquired the name org.freedesktop.UDisks2 on the system message bus
May 2 08:54:16 m1-desktop udisksd[2670]: Cleaning up mount point /media/m1/12D3-A869 (device 8:1 is not mounted)
May 2 08:54:16 m1-desktop org.gtk.vfs.AfcVolumeMonitor[2270]: Volume monitor alive
May 2 08:54:17 m1-desktop rtkit-daemon[2515]: Supervising 2 threads of 1 processes of 1 users.
May 2 08:54:17 m1-desktop rtkit-daemon[2515]: Successfully made thread 2714 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:17 m1-desktop rtkit-daemon[2515]: Supervising 3 threads of 1 processes of 1 users.
May 2 08:54:17 m1-desktop org.gnome.ScreenSaver[2270]: ** Message: Lost the name, shutting down.
May 2 08:54:19 m1-desktop rtkit-daemon[2515]: Supervising 3 threads of 1 processes of 1 users.
May 2 08:54:19 m1-desktop rtkit-daemon[2515]: Successfully made thread 2773 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:19 m1-desktop rtkit-daemon[2515]: Supervising 4 threads of 1 processes of 1 users.
May 2 08:54:22 m1-desktop rtkit-daemon[2515]: Supervising 4 threads of 1 processes of 1 users.
May 2 08:54:22 m1-desktop rtkit-daemon[2515]: Successfully made thread 2776 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:22 m1-desktop rtkit-daemon[2515]: Supervising 5 threads of 1 processes of 1 users.
May 2 08:54:26 m1-desktop rtkit-daemon[2515]: Supervising 5 threads of 1 processes of 1 users.
May 2 08:54:26 m1-desktop rtkit-daemon[2515]: Successfully made thread 2777 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:26 m1-desktop rtkit-daemon[2515]: Supervising 6 threads of 1 processes of 1 users.
May 2 08:54:32 m1-desktop rtkit-daemon[2515]: Supervising 6 threads of 1 processes of 1 users.
May 2 08:54:32 m1-desktop rtkit-daemon[2515]: Successfully made thread 2778 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:32 m1-desktop rtkit-daemon[2515]: Supervising 7 threads of 1 processes of 1 users.
May 2 08:54:34 m1-desktop rtkit-daemon[2515]: Supervising 7 threads of 1 processes of 1 users.
May 2 08:54:34 m1-desktop rtkit-daemon[2515]: Successfully made thread 2779 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:34 m1-desktop rtkit-daemon[2515]: Supervising 8 threads of 1 processes of 1 users.
May 2 08:54:37 m1-desktop rtkit-daemon[2515]: Supervising 8 threads of 1 processes of 1 users.
May 2 08:54:37 m1-desktop rtkit-daemon[2515]: Successfully made thread 2780 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:37 m1-desktop rtkit-daemon[2515]: Supervising 9 threads of 1 processes of 1 users.
May 2 08:54:39 m1-desktop rtkit-daemon[2515]: Supervising 9 threads of 1 processes of 1 users.
May 2 08:54:39 m1-desktop rtkit-daemon[2515]: Successfully made thread 2781 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:39 m1-desktop rtkit-daemon[2515]: Supervising 10 threads of 1 processes of 1 users.
May 2 08:54:41 m1-desktop rtkit-daemon[2515]: Supervising 10 threads of 1 processes of 1 users.
May 2 08:54:41 m1-desktop rtkit-daemon[2515]: Successfully made thread 2782 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:41 m1-desktop rtkit-daemon[2515]: Supervising 11 threads of 1 processes of 1 users.
May 2 08:54:43 m1-desktop rtkit-daemon[2515]: Supervising 11 threads of 1 processes of 1 users.
May 2 08:54:43 m1-desktop rtkit-daemon[2515]: Successfully made thread 2786 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:43 m1-desktop rtkit-daemon[2515]: Supervising 12 threads of 1 processes of 1 users.
May 2 08:54:45 m1-desktop rtkit-daemon[2515]: Supervising 12 threads of 1 processes of 1 users.
May 2 08:54:45 m1-desktop rtkit-daemon[2515]: Successfully made thread 2787 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:45 m1-desktop rtkit-daemon[2515]: Supervising 13 threads of 1 processes of 1 users.
May 2 08:54:47 m1-desktop rtkit-daemon[2515]: Supervising 13 threads of 1 processes of 1 users.
May 2 08:54:47 m1-desktop rtkit-daemon[2515]: Successfully made thread 2788 of process 2514 (n/a) owned by '1000' RT at priority 5.
May 2 08:54:47 m1-desktop rtkit-daemon[2515]: Supervising 14 threads of 1 processes of 1 users.
May 2 08:54:48 m1-desktop pulseaudio[2514]: [pulseaudio] backend-ofono.c: Failed to register as a handsfree audio agent with ofono: org.freedesktop.DBus.Error.ServiceUnknown: The name org.ofono was not provided by any .service files
May 2 08:54:48 m1-desktop rtkit-daemon[2515]: Successfully made thread 2790 of process 2790 (n/a) owned by '1000' high priority at nice level -11.
May 2 08:54:48 m1-desktop rtkit-daemon[2515]: Supervising 15 threads of 2 processes of 1 users.
May 2 08:54:48 m1-desktop pulseaudio[2790]: [pulseaudio] pid.c: Daemon already running.
May 2 08:54:48 m1-desktop rtkit-daemon[2515]: Successfully made thread 2796 of process 2796 (n/a) owned by '1000' high priority at nice level -11.
May 2 08:54:48 m1-desktop rtkit-daemon[2515]: Supervising 15 threads of 2 processes of 1 users.
May 2 08:54:48 m1-desktop pulseaudio[2796]: [pulseaudio] pid.c: Daemon already running.
May 2 08:54:48 m1-desktop dbus[821]: [system] Activating via systemd: service name='org.freedesktop.locale1' unit='dbus-org.freedesktop.locale1.service'
May 2 08:54:48 m1-desktop systemd[1]: Starting Locale Service...
May 2 08:54:48 m1-desktop gnome-session[2410]: (nautilus:2808): GLib-GIO-CRITICAL **: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed
May 2 08:54:48 m1-desktop gnome-session[2410]: (nautilus:2808): GLib-GIO-CRITICAL **: g_dbus_interface_skeleton_unexport: assertion 'interface_->priv->connections != NULL' failed
May 2 08:54:48 m1-desktop dbus[821]: [system] Successfully activated service 'org.freedesktop.locale1'
May 2 08:54:48 m1-desktop systemd[1]: Started Locale Service.
May 2 08:54:48 m1-desktop gnome-session[2410]: (nautilus:2808): Gtk-CRITICAL **: gtk_icon_theme_get_for_screen: assertion 'GDK_IS_SCREEN (screen)' failed
May 2 08:54:48 m1-desktop gnome-session[2410]: (nautilus:2808): GLib-GObject-WARNING **: invalid (NULL) pointer instance
May 2 08:54:48 m1-desktop gnome-session[2410]: (nautilus:2808): GLib-GObject-CRITICAL **: g_signal_connect_object: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed
May 2 08:54:48 m1-desktop gnome-session[2410]: (process:2814): indicator-application-service-WARNING **: Unable to get watcher name 'org.kde.StatusNotifierWatcher'
May 2 08:54:48 m1-desktop gnome-session[2410]: (process:2814): indicator-application-service-WARNING **: Name Lost
May 2 08:54:48 m1-desktop gnome-session-binary[2410]: Entering running state
May 2 08:54:48 m1-desktop kernel: [ 217.746122] FAT-fs (sda1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
May 2 08:54:48 m1-desktop udisksd[2670]: Mounted /dev/sda1 at /media/m1/12D3-A869 on behalf of uid 1000
May 2 08:54:48 m1-desktop dbus[821]: [system] Activating service name='org.freedesktop.fwupd' (using servicehelper)
May 2 08:54:49 m1-desktop org.freedesktop.fwupd[821]: (fwupd:2860): Fu-WARNING **: Failed to coldplug: UEFI firmware updating not supported
May 2 08:54:49 m1-desktop dbus[821]: [system] Successfully activated service 'org.freedesktop.fwupd'
May 2 08:54:49 m1-desktop gnome-session[2410]: (guake:2809): libglade-WARNING **: unknown attribute `swapped' for .
May 2 08:54:49 m1-desktop gnome-session[2410]: message repeated 21 times: [ (guake:2809): libglade-WARNING **: unknown attribute `swapped' for .]
May 2 08:54:49 m1-desktop gnome-session[2410]: INFO:guake.guake_app:Logging configuration complete
May 2 08:54:49 m1-desktop gnome-session[2410]: /usr/lib/python2.7/dist-packages/guake/guake_app.py:1785: GtkWarning: gtk_box_pack: assertion 'child->parent == NULL' failed
May 2 08:54:49 m1-desktop gnome-session[2410]: self.mainframe.pack_start(self.notebook, expand=True, fill=True, padding=0)
May 2 08:54:53 m1-desktop dbus[821]: [system] Activating service name='org.debian.apt' (using servicehelper)
May 2 08:54:53 m1-desktop AptDaemon: INFO: Initializing daemon
May 2 08:54:53 m1-desktop org.debian.apt[821]: 08:54:53 AptDaemon [INFO]: Initializing daemon
May 2 08:54:53 m1-desktop dbus[821]: [system] Successfully activated service 'org.debian.apt'
May 2 08:54:53 m1-desktop AptDaemon.PackageKit: INFO: Initializing PackageKit compat layer
May 2 08:54:53 m1-desktop org.debian.apt[821]: /usr/lib/python3/dist-packages/aptdaemon/worker/pkworker.py:35: PyGIWarning: PackageKitGlib was imported without specifying a version first. Use gi.require_version('PackageKitGlib', '1.0') before import to ensure that the right version gets loaded.
May 2 08:54:53 m1-desktop org.debian.apt[821]: from gi.repository import PackageKitGlib as pk
May 2 08:54:53 m1-desktop org.debian.apt[821]: 08:54:53 AptDaemon.PackageKit [INFO]: Initializing PackageKit compat layer
May 2 08:54:53 m1-desktop AptDaemon: INFO: UpdateCache() was called
May 2 08:54:53 m1-desktop org.debian.apt[821]: 08:54:53 AptDaemon [INFO]: UpdateCache() was called
May 2 08:54:53 m1-desktop gnome-session[2410]: (gnome-software:2822): GLib-GObject-CRITICAL **: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
May 2 08:54:53 m1-desktop AptDaemon.Trans: INFO: Queuing transaction /org/debian/apt/transaction/3c2c7e9039dd4e919f975e6a7dba4e3f
May 2 08:54:53 m1-desktop org.debian.apt[821]: 08:54:53 AptDaemon.Trans [INFO]: Queuing transaction /org/debian/apt/transaction/3c2c7e9039dd4e919f975e6a7dba4e3f
May 2 08:54:53 m1-desktop AptDaemon.Worker: INFO: Simulating trans: /org/debian/apt/transaction/3c2c7e9039dd4e919f975e6a7dba4e3f
May 2 08:54:53 m1-desktop org.debian.apt[821]: 08:54:53 AptDaemon.Worker [INFO]: Simulating trans: /org/debian/apt/transaction/3c2c7e9039dd4e919f975e6a7dba4e3f
May 2 08:54:53 m1-desktop AptDaemon.Worker: INFO: Processing transaction /org/debian/apt/transaction/3c2c7e9039dd4e919f975e6a7dba4e3f
May 2 08:54:53 m1-desktop org.debian.apt[821]: 08:54:53 AptDaemon.Worker [INFO]: Processing transaction /org/debian/apt/transaction/3c2c7e9039dd4e919f975e6a7dba4e3f
May 2 08:54:54 m1-desktop AptDaemon.Worker: INFO: Updating cache
May 2 08:54:54 m1-desktop org.debian.apt[821]: 08:54:54 AptDaemon.Worker [INFO]: Updating cache
May 2 08:55:07 m1-desktop AptDaemon.Worker: INFO: Finished transaction /org/debian/apt/transaction/3c2c7e9039dd4e919f975e6a7dba4e3f
May 2 08:55:07 m1-desktop org.debian.apt[821]: 08:55:07 AptDaemon.Worker [INFO]: Finished transaction /org/debian/apt/transaction/3c2c7e9039dd4e919f975e6a7dba4e3f
May 2 08:55:51 m1-desktop gnome-session[2410]: ** (update-notifier:3760): WARNING **: log file empty (logrotate?) /var/log/dpkg.log
May 2 08:55:51 m1-desktop gnome-session[2410]: ** (update-notifier:3760): WARNING **: log file empty (logrotate?) /var/log/apt/term.log
May 2 08:56:22 m1-desktop anacron[771]: Job `cron.daily' started
May 2 08:56:22 m1-desktop anacron[3949]: Updated timestamp for job `cron.daily' to 2018-05-02
May 2 08:56:22 m1-desktop cracklib: no dictionary update necessary.
May 2 08:56:22 m1-desktop systemd[1]: Reloading LSB: Apache2 web server.
May 2 08:56:22 m1-desktop apache2[4008]: * Reloading Apache httpd web server apache2
May 2 08:56:22 m1-desktop apache2[4008]: *
May 2 08:56:22 m1-desktop systemd[1]: Reloaded LSB: Apache2 web server.
May 2 08:56:23 m1-desktop rsyslogd: [origin software="rsyslogd" swVersion="8.16.0" x-pid="781" x-info="http://www.rsyslog.com"] rsyslogd was HUPed

Stubo

member

Activity: 224

Merit: 13

Quote from: urnzwy on May 04, 2018, 01:10:53 PM

m1@m1-desktop:~$ cat /etc/logrotate.d/rsyslog
/var/log/syslog
{
   rotate 7
   daily
   missingok
   notifempty
   delaycompress
   compress
   postrotate
      invoke-rc.d rsyslog rotate > /dev/null
   endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
   rotate 4
   weekly
   missingok
   notifempty
   compress
   delaycompress
   sharedscrip

Great, do you do have syslogs dating back a week to inspect. Namely these:

Code:

-rw-r----- 1 syslog adm 221063 May 4 11:03 syslog
-rw-r----- 1 syslog adm 480516 May 4 07:43 syslog.1
-rw-r----- 1 syslog adm 71338 May 3 10:28 syslog.2.gz
-rw-r----- 1 syslog adm 101993 May 2 08:56 syslog.3.gz
-rw-r----- 1 syslog adm 70681 May 1 07:35 syslog.4.gz
-rw-r----- 1 syslog adm 37431 Apr 30 19:00 syslog.5.gz
-rw-r----- 1 syslog adm 8234 Apr 29 07:35 syslog.6.gz
-rw-r----- 1 syslog adm 8185 Apr 28 07:35 syslog.7.gz

You should be able to go back through them and align your "freezes" with what is in them for those times.

urnzwy

newbie

Activity: 44

Merit: 0

m1@m1-desktop:~$ cat /etc/logrotate.d/rsyslog
/var/log/syslog
{
   rotate 7
   daily
   missingok
   notifempty
   delaycompress
   compress
   postrotate
      invoke-rc.d rsyslog rotate > /dev/null
   endscript
}

/var/log/mail.info
/var/log/mail.warn
/var/log/mail.err
/var/log/mail.log
/var/log/daemon.log
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
/var/log/lpr.log
/var/log/cron.log
/var/log/debug
/var/log/messages
{
   rotate 4
   weekly
   missingok
   notifempty
   compress
   delaycompress
   sharedscrip

urnzwy

newbie

Activity: 44

Merit: 0

Stubo

member

Activity: 224

Merit: 13

Quote from: urnzwy on May 04, 2018, 09:51:55 AM

Haha, you and me both.. Straight up driving me crazy.

I had enabled the system restart timer for 720 min / 12 hours yesterday to see if it would restart and not freeze (as it does about every 18 hours). It tried to restart and froze the systems instead.

Created the new directory -

m1@m1-desktop:~$ sudo su -
root@m1-desktop:~# cd /var/log
root@m1-desktop:/var/log# touch test.txt
root@m1-desktop:/var/log# ls test*
test.txt

Ugh. I found this which may be relevant:
https://unix.stackexchange.com/questions/395879/files-in-var-log-are-only-writing-to-file-1-syslog-is-empty-but-not-syslog-1

Can you make sure your log rotate daemon is running:

Code:

m1@Testy:~$ ps -ef |grep rsys
syslog 828 1 0 Apr30 ? 00:00:00 /usr/sbin/rsyslogd -n
m1 22431 22172 0 13:36 pts/22 00:00:00 grep --color=auto rsys

And then post your /etc/logrotate.d/rsyslog? Also, what files are in your /var/log dir?

Code:

m1@Testy:~$ ll /var/log
total 2052
drwxrwxr-x 13 root syslog 4096 May 4 07:35 ./
drwxr-xr-x 15 root root 4096 Oct 9 2017 ../
-rw-r--r-- 1 root root 0 Feb 17 08:09 alternatives.log
-rw-r--r-- 1 root root 5119 Dec 17 09:39 alternatives.log.1
drwxr-x--- 2 root adm 4096 May 4 07:35 apache2/
-rw-r----- 1 root adm 0 Apr 17 2017 apport.log
drwxr-xr-x 2 root root 4096 Feb 17 08:09 apt/
-rw-r----- 1 syslog adm 73135 May 4 13:33 auth.log
-rw-r----- 1 syslog adm 113222 Apr 29 07:30 auth.log.1
-rw-r----- 1 syslog adm 1548 Apr 26 08:35 auth.log.2.gz
-rw-r----- 1 syslog adm 6214 Apr 8 07:30 auth.log.3.gz
-rw-r----- 1 syslog adm 7009 Apr 1 07:30 auth.log.4.gz
-rw-r--r-- 1 root root 4099 Apr 30 12:21 boot.log
-rw-r--r-- 1 root root 57457 Jul 19 2016 bootstrap.log
-rw-rw---- 1 root utmp 384 May 2 12:59 btmp
-rw------- 1 root utmp 384 Apr 3 08:56 btmp.1
drwxr-xr-x 2 root root 4096 Dec 17 10:03 cups/
drwxr-xr-x 2 root root 4096 Apr 26 2016 dist-upgrade/
-rw-r----- 1 root adm 31 Jul 19 2016 dmesg
-rw-r--r-- 1 root root 0 Feb 17 08:09 dpkg.log
-rw-r--r-- 1 root root 1016 Dec 31 11:45 dpkg.log.1
-rw-r--r-- 1 root root 32032 Oct 26 2017 faillog
-rw-r--r-- 1 root root 4042 Aug 18 2017 fontconfig.log
drwxr-xr-x 2 root root 4096 Jul 19 2016 fsck/
-rw-r--r-- 1 root root 1892 Apr 30 12:20 gpu-manager.log
drwxrwxr-x 2 root root 4096 Dec 17 10:03 installer/
-rw-r----- 1 syslog adm 389222 May 4 12:51 kern.log
-rw-r----- 1 syslog adm 589783 Apr 29 03:22 kern.log.1
-rw-r----- 1 syslog adm 18762 Apr 26 08:31 kern.log.2.gz
-rw-r----- 1 syslog adm 88713 Apr 8 06:48 kern.log.3.gz
-rw-r----- 1 syslog adm 143888 Apr 1 00:23 kern.log.4.gz
-rw-rw-r-- 1 root utmp 292292 May 4 13:33 lastlog
drwxr-xr-x 2 root root 4096 May 1 07:35 lightdm/
-rw-r----- 1 syslog adm 0 Feb 17 08:09 mail.err
-rw-r----- 1 syslog adm 140 Feb 17 07:55 mail.err.1
-rw-r----- 1 syslog adm 1819 Apr 30 18:26 mail.log
-rw-r----- 1 syslog adm 330 Apr 29 06:40 mail.log.1
-rw-r----- 1 syslog adm 219 Apr 26 16:32 mail.log.2.gz
-rw-r----- 1 syslog adm 314 Apr 7 01:07 mail.log.3.gz
-rw-r----- 1 syslog adm 291 Mar 31 23:49 mail.log.4.gz
-rw-r--r-- 1 root root 55 Apr 30 12:21 prime-offload.log
-rw-r--r-- 1 root root 30 Apr 30 12:21 prime-supported.log
drwx------ 2 speech-dispatcher root 4096 Feb 18 2016 speech-dispatcher/
-rw-r----- 1 syslog adm 3576 May 4 13:33 syslog
-rw-r----- 1 syslog adm 12788 May 4 07:35 syslog.1
-rw-r----- 1 syslog adm 2413 May 3 07:35 syslog.2.gz
-rw-r----- 1 syslog adm 2729 May 2 07:35 syslog.3.gz
-rw-r----- 1 syslog adm 104280 May 1 07:35 syslog.4.gz
-rw-r----- 1 syslog adm 2448 Apr 30 07:35 syslog.5.gz
-rw-r----- 1 syslog adm 2928 Apr 29 07:35 syslog.6.gz
-rw-r----- 1 syslog adm 51881 Apr 28 05:39 syslog.7.gz
drwxr-xr-x 2 root root 4096 Jun 20 2017 teamviewer12/
drwxr-x--- 2 root adm 4096 Dec 17 10:03 unattended-upgrades/
drwxr-xr-x 2 root root 4096 May 19 2016 upstart/
-rw-rw-r-- 1 root utmp 5760 May 4 13:33 wtmp
-rw-rw-r-- 1 root utmp 84096 Apr 30 15:55 wtmp.1
-rw-r--r-- 1 root root 20686 Apr 30 12:21 Xorg.0.log
-rw-r--r-- 1 root root 21932 Apr 30 12:20 Xorg.0.log.old
-rw-r--r-- 1 root root 8774 Apr 26 2017 Xorg.1.log
-rw-r--r-- 1 root root 47236 Aug 13 2017 Xorg.failsafe.log

urnzwy

newbie

Activity: 44

Merit: 0

Quote from: Stubo on May 04, 2018, 05:36:42 AM

Quote from: urnzwy on May 03, 2018, 04:08:50 PM

Both my rigs have no logs. Neither are set to clear logs on reboot, so they should be there if they are. Only logs I have seen are the ones I posted that show up in miner_watchdog

m1@m1-desktop:~$ /var/log$ ll sys*
bash: /var/log$: No such file or directory

This is truly strange and I kind of want to get the bottom of it. I wonder if you have a read-only filesystem as Ubuntu should be logging tons of stuff to /var/log:

Code:

m1@Testy:/var/log$ ls
alternatives.log dist-upgrade lightdm syslog.4.gz
alternatives.log.1 dmesg mail.err syslog.5.gz
apache2 dpkg.log mail.err.1 syslog.6.gz
apport.log dpkg.log.1 mail.log syslog.7.gz
apt faillog mail.log.1 teamviewer12
auth.log fontconfig.log mail.log.2.gz unattended-upgrades
auth.log.1 fsck mail.log.3.gz upstart
auth.log.2.gz gpu-manager.log mail.log.4.gz wtmp
auth.log.3.gz installer prime-offload.log wtmp.1
auth.log.4.gz kern.log prime-supported.log Xorg.0.log
boot.log kern.log.1 speech-dispatcher Xorg.0.log.old
bootstrap.log kern.log.2.gz syslog Xorg.1.log
btmp kern.log.3.gz syslog.1 Xorg.failsafe.log
btmp.1 kern.log.4.gz syslog.2.gz
cups lastlog syslog.3.gz

Try writing a file as root like this:

Code:

m1@Testy:/var/log$ sudo su -
root@Testy:~# cd /var/log
root@Testy:/var/log# touch test.txt
root@Testy:/var/log# ls test*
test.txt

Haha, you and me both.. Straight up driving me crazy.

I had enabled the system restart timer for 720 min / 12 hours yesterday to see if it would restart and not freeze (as it does about every 18 hours). It tried to restart and froze the systems instead.

Created the new directory -

m1@m1-desktop:~$ sudo su -
root@m1-desktop:~# cd /var/log
root@m1-desktop:/var/log# touch test.txt
root@m1-desktop:/var/log# ls test*
test.txt

These were in my Watchdog window upon loading today

Rig 1 -

tail -f /home/m1/nvoc_logs/watchdog-screenlog.0
m1@m1-desktop:~$ tail -f /home/m1/nvoc_logs/watchdog-screenlog.0
Watchdog for nvOC v0019-2.0 - Community Release
Version: v0019-2.0.011

LOG FILE: (Showing the last 10 recorded entries)
cu 10:30:51|cuda-9 Set Device to current
cu 10:30:51|cuda-9 Resetting device
cu 10:30:51|cuda-5 Using device: GeForce GTX 1070 (Compute 6.1)
cu 10:30:51|cuda-5 Set Device to current
cu 10:30:51|cuda-5 Resetting device
cu 10:30:51|cuda-10 Using device: GeForce GTX 1070 (Compute 6.1)
cu 10:30:51|cuda-10 Set Device to current
cu 10:30:51|cuda-10 Resetting device
m 10:30:53|ethminer Speed 0.00 Mh/s gpu/0 0.00 gpu/1 0.00 gpu/2 0.00 gpu/3 0.00 gpu/4 0.00 gpu/5 0.00 gpu/6 0.00 gpu/7 0.00 gpu/8 0.00 gpu/9 0.00 gpu/10 0.00 gpu/11 0.00 gpu/12 0.00 [A0+0:R0+0:F0] Time: 00:00

Rig 2 -

tail -f /home/m1/nvoc_logs/watchdog-screenlog.0
m1@m1-desktop:~$ tail -f /home/m1/nvoc_logs/watchdog-screenlog.0
Watchdog for nvOC v0019-2.0 - Community Release
Version: v0019-2.0.011

LOG FILE: (Showing the last 10 recorded entries)
ℹ 10:32:31|cuda-4 Solution found; Submitted to us-east.ethash-hub.miningpoolhub.com
ℹ 10:32:31|cuda-4 Nonce: 0xf1a1cb19d6cee3e0
ℹ 10:32:31|stratum Accepted.
m 10:32:31|ethminer Speed 359.41 Mh/s gpu/0 26.52 gpu/1 27.76 gpu/2 27.85 gpu/3 33.39 gpu/4 27.85 gpu/5 27.76 gpu/6 27.76 gpu/7 27.76 gpu/8 21.84 gpu/9 27.66 gpu/10 27.85 gpu/11 27.76 gpu/12 27.66 [A29+0:R0+0:F0] Time: 00:06
ℹ 10:32:32|cuda-6 Solution found; Submitted to us-east.ethash-hub.miningpoolhub.com
ℹ 10:32:32|cuda-6 Nonce: 0x5fc7829a336d53eb
ℹ 10:32:32|stratum Accepted.
m 10:32:33|ethminer Speed 359.51 Mh/s gpu/0 26.61 gpu/1 27.85 gpu/2 27.76 gpu/3 33.39 gpu/4 27.85 gpu/5 27.76 gpu/6 27.85 gpu/7 27.76 gpu/8 21.84 gpu/9 27.66 gpu/10 27.76 gpu/11 27.76 gpu/12 27.66 [A30+0:R0+0:F0] Time: 00:06
m 10:32:35|ethminer Speed 359.41 Mh/s gpu/0 26.61 gpu/1 27.85 gpu/2 27.76 gpu/3 33.29 gpu/4 27.85 gpu/5 27.76 gpu/6 27.85 gpu/7 27.76 gpu/8 21.84 gpu/9 27.66 gpu/10 27.76 gpu/11 27.76 gpu/12 27.66 [A30+0:R0+0:F0] Time: 00:06
CRITICAL: Thu May 3 10:32:50 MST 2018 - GPU Utilization is too low: restarting 3main...

zloy_hulk

newbie

Activity: 40

Merit: 0

Quote from: papampi on April 25, 2018, 05:40:33 PM

Quote from: zloy_hulk on April 25, 2018, 02:25:05 PM

Hello!
First of all, thank you for this freeware os.

I have a quastion about working this os with nvidia p104 cards.
I have systems with only P104 cards. So, I have to connect monitor to the integrated video.
My systems can't work properly with these cards, nvidia x-server fails or can't apply oc for the cards. I tryied "p106 full headless mode" but it didn't help.
How to get system with P104 cards working?

P104 and P102 will be added to next version, for now,
As soon as rig starts and gnome-terminal opens, close it.
Open and edit /home/m1/3main

Change:

Code:

if grep -q "P106-100" /tmp/tempa;
then
___1050_or_1050ti="YES"
P106_100="YES"
fi

To:

Code:

if grep -q -E 'P106|P104|P102' /tmp/tempa;
then
___1050_or_1050ti="YES"
P106_100="YES"
fi

Reboot,
After start it should update Xorg and ask you to disconnect monitor and then it will reboot in 5 seconds.
Should start mining ok
You can then connect with ssh

Hello. Thank you. My system with P104 can work now and don't reboot.
But cards can't be overclocked(( OC settings don't apply to P104 cards. When I try to apply some oc manually (smth like this: nvidia-settings -a GPUMemoryTransferRateOffset=1000), nvidia-settings shows error.
What to do?

Stubo

member

Activity: 224

Merit: 13

Quote from: thaelin on May 04, 2018, 04:25:57 AM

Quote from: CryptAtomeTrader44 on May 03, 2018, 07:05:28 PM

Bad news about Equihash :

Bitmain launch Equihash ASIC this day. 10 KSol/s consumming only 300W !

What do you think about this ASIC ?

https://shop.bitmain.com/product/detail?pid=00020180503154806494uGcSyiu806FD

I said that I do not come to promote them, I did not buy ASIC but it is quite clear that this case will pose a huge problem. Much worse than that of the ETH miner of the same company.

Only the Monéro community reacted in opposition to the bitmain ASICS. I simply wish to have your opinion on this issue which may make GPU mining obsolete on this algorithm rather quickly.

At this rate, only Neoscrypt and Cryptonight V7 will remain to be mined via CPU and GPU. Not a good deal for decentralization as a cryptocurrency target.

One rig 22mhX6 for 132MH drawing 680w VS 10Kh @300W is going to be a threat? Where?
Oh and each unit does cost 2K and you can only have one for now. Hmmmmm.
thay

The scary thing is that they are not sold out yet and it has been about 20 hours since they went on sale. This tells me that they must be selling a very large quantity. We all know that that the difficulty for equihash based coins will go way up when they start coming online in mid to late June, but I wonder about the prices of those coins short, mid and long term. I have several of them that I am "hodling" so this really casts a shadow of unknown on the best time to unload them.

As for how to react now, I suppose the best course of action is to read up on coins that we care about to see if there are any plans to change the algo to "asic proof" them. Also, try to find coins that can be mined with nvidia GPUs that are already asic proof like RVN.

Just my 2 cents...

Stubo

member

Activity: 224

Merit: 13

Quote from: urnzwy on May 03, 2018, 04:08:50 PM

Both my rigs have no logs. Neither are set to clear logs on reboot, so they should be there if they are. Only logs I have seen are the ones I posted that show up in miner_watchdog

m1@m1-desktop:~$ /var/log$ ll sys*
bash: /var/log$: No such file or directory

This is truly strange and I kind of want to get the bottom of it. I wonder if you have a read-only filesystem as Ubuntu should be logging tons of stuff to /var/log:

Code:

m1@Testy:/var/log$ ls
alternatives.log dist-upgrade lightdm syslog.4.gz
alternatives.log.1 dmesg mail.err syslog.5.gz
apache2 dpkg.log mail.err.1 syslog.6.gz
apport.log dpkg.log.1 mail.log syslog.7.gz
apt faillog mail.log.1 teamviewer12
auth.log fontconfig.log mail.log.2.gz unattended-upgrades
auth.log.1 fsck mail.log.3.gz upstart
auth.log.2.gz gpu-manager.log mail.log.4.gz wtmp
auth.log.3.gz installer prime-offload.log wtmp.1
auth.log.4.gz kern.log prime-supported.log Xorg.0.log
boot.log kern.log.1 speech-dispatcher Xorg.0.log.old
bootstrap.log kern.log.2.gz syslog Xorg.1.log
btmp kern.log.3.gz syslog.1 Xorg.failsafe.log
btmp.1 kern.log.4.gz syslog.2.gz
cups lastlog syslog.3.gz

Try writing a file as root like this:

Code:

m1@Testy:/var/log$ sudo su -
root@Testy:~# cd /var/log
root@Testy:/var/log# touch test.txt
root@Testy:/var/log# ls test*
test.txt

papampi

full member

Activity: 686

Merit: 140

Linux FOREVER! Resistance is futile!!!

Quote from: thaelin on May 04, 2018, 04:25:57 AM

Quote from: CryptAtomeTrader44 on May 03, 2018, 07:05:28 PM

Bad news about Equihash :

Bitmain launch Equihash ASIC this day. 10 KSol/s consumming only 300W !

What do you think about this ASIC ?

https://shop.bitmain.com/product/detail?pid=00020180503154806494uGcSyiu806FD

I said that I do not come to promote them, I did not buy ASIC but it is quite clear that this case will pose a huge problem. Much worse than that of the ETH miner of the same company.

Only the Monéro community reacted in opposition to the bitmain ASICS. I simply wish to have your opinion on this issue which may make GPU mining obsolete on this algorithm rather quickly.

At this rate, only Neoscrypt and Cryptonight V7 will remain to be mined via CPU and GPU. Not a good deal for decentralization as a cryptocurrency target.

One rig 22mhX6 for 132MH drawing 680w VS 10Kh @300W is going to be a threat? Where?
Oh and each unit does cost 2K and you can only have one for now. Hmmmmm.
thay

Its equihash not ethash ...

thaelin

newbie

Activity: 64

Merit: 0

Quote from: CryptAtomeTrader44 on May 03, 2018, 07:05:28 PM

Bad news about Equihash :

Bitmain launch Equihash ASIC this day. 10 KSol/s consumming only 300W !

What do you think about this ASIC ?

https://shop.bitmain.com/product/detail?pid=00020180503154806494uGcSyiu806FD

I said that I do not come to promote them, I did not buy ASIC but it is quite clear that this case will pose a huge problem. Much worse than that of the ETH miner of the same company.

Only the Monéro community reacted in opposition to the bitmain ASICS. I simply wish to have your opinion on this issue which may make GPU mining obsolete on this algorithm rather quickly.

At this rate, only Neoscrypt and Cryptonight V7 will remain to be mined via CPU and GPU. Not a good deal for decentralization as a cryptocurrency target.

One rig 22mhX6 for 132MH drawing 680w VS 10Kh @300W is going to be a threat? Where?
Oh and each unit does cost 2K and you can only have one for now. Hmmmmm.
thay

LuKePicci

jr. member

Activity: 128

Merit: 1

Quote from: Stubo on May 03, 2018, 06:45:41 AM

That is a good point, Thay. I was very surprised to learn how much some GPUs pull through the PCI slot and also that it varies by GPU and MFR. If we assume 50w per card (may even be low) and another 80w for the mobo, that gives us 680w. That is what I would consider to be the max usable for a 850w PSU (80% of rated output).

EDIT: IMO, trying to get a 12 GPU rig to be rock stable is an exercise in frustration. I have read dozens of messages on this thread (and others) of folks having all kinds of oddball problems with rigs that use more than 8 GPUs. This includes not only nvOC, but also Windows, SMOS, and HiveOS. It can be done, but it comes with an inherent lack of stability. If I were you, I would split it up into 2 rigs and get on with mining.

Added just two hours ago the 9th gpu to my rig, let me dream for a while as long as it don't crash. Btw it's a dual 850w psu rig, the psu powering the first 6-gpu runs also the mobo, 670w by itself from power socket, the other half is intended to work with 7-gpu, it's running only 3 right now. No kind of cable meltdown or overheating since November, so I'll keep crossing fingers. Still I would really like to check how much of the 100w budget my cards are getting through sata cables vs vga ones.

CryptAtomeTrader44

full member

Activity: 340

Merit: 103

It is easier to break an atom than partialities AE

Bad news about Equihash :

Bitmain launch Equihash ASIC this day. 10 KSol/s consumming only 300W !

What do you think about this ASIC ?

https://shop.bitmain.com/product/detail?pid=00020180503154806494uGcSyiu806FD

I said that I do not come to promote them, I did not buy ASIC but it is quite clear that this case will pose a huge problem. Much worse than that of the ETH miner of the same company.

Only the Monéro community reacted in opposition to the bitmain ASICS. I simply wish to have your opinion on this issue which may make GPU mining obsolete on this algorithm rather quickly.

At this rate, only Neoscrypt and Cryptonight V7 will remain to be mined via CPU and GPU. Not a good deal for decentralization as a cryptocurrency target.

urnzwy

newbie

Activity: 44

Merit: 0

Quote from: Stubo on May 03, 2018, 02:42:21 PM

Quote from: urnzwy on May 03, 2018, 01:28:46 PM

Quote from: Stubo on May 03, 2018, 11:40:04 AM

Quote from: urnzwy on May 03, 2018, 09:52:03 AM

Quote from: thaelin on May 03, 2018, 04:28:27 AM

Not sure this will be relevant but your system of 12 cards using one 850 psu for the risers is how I killed two psu. I only had 7 cards running and it was too much for the Sata channels to handle. One psu will be good for 6 sata devices so I think you are browning out the main psu. Once I dropped back on card count, no more problems. In the end, I gave up on the Server psu's and went with dual 1000w psu's.

thay

The 850W PSU only runs the motherboard and one card and it's riser. I have three PSU's per rig. Two 1600W (6 cards and their risers each) and the 850W as described. I am no were near the amount of power the power supplies are capable of, so should be good there.

This is one of the rigs - https://imgur.com/a/WRfTksJ

That is a really nice (and big) rig. Did you find anything in syslog (as per my previous post)?

m1@m1-desktop:~$ sudo less /var/log/dmesg
(Nothing has been logged yet.)

Is all I get. I am using 19.2

There are lots of logs in there. In particular, I would like to see what was logged to syslog at the times when it freezes. You should find about a week's worth, some gzipped up:

Code:

m1@Testy:/var/log$ ll sys*
-rw-r----- 1 syslog adm   4328 May  3 15:38 syslog
-rw-r----- 1 syslog adm  12251 May  3 07:35 syslog.1
-rw-r----- 1 syslog adm   2729 May  2 07:35 syslog.2.gz
-rw-r----- 1 syslog adm 104280 May  1 07:35 syslog.3.gz
-rw-r----- 1 syslog adm   2448 Apr 30 07:35 syslog.4.gz
-rw-r----- 1 syslog adm   2928 Apr 29 07:35 syslog.5.gz
-rw-r----- 1 syslog adm  51881 Apr 28 05:39 syslog.6.gz
-rw-r----- 1 syslog adm 105756 Apr 27 07:35 syslog.7.gz

Both my rigs have no logs. Neither are set to clear logs on reboot, so they should be there if they are. Only logs I have seen are the ones I posted that show up in miner_watchdog

m1@m1-desktop:~$ /var/log$ ll sys*
bash: /var/log$: No such file or directory

Stubo

member

Activity: 224

Merit: 13

Quote from: urnzwy on May 03, 2018, 01:28:46 PM

Quote from: Stubo on May 03, 2018, 11:40:04 AM

Quote from: urnzwy on May 03, 2018, 09:52:03 AM

Quote from: thaelin on May 03, 2018, 04:28:27 AM

Not sure this will be relevant but your system of 12 cards using one 850 psu for the risers is how I killed two psu. I only had 7 cards running and it was too much for the Sata channels to handle. One psu will be good for 6 sata devices so I think you are browning out the main psu. Once I dropped back on card count, no more problems. In the end, I gave up on the Server psu's and went with dual 1000w psu's.

thay

The 850W PSU only runs the motherboard and one card and it's riser. I have three PSU's per rig. Two 1600W (6 cards and their risers each) and the 850W as described. I am no were near the amount of power the power supplies are capable of, so should be good there.

This is one of the rigs - https://imgur.com/a/WRfTksJ

That is a really nice (and big) rig. Did you find anything in syslog (as per my previous post)?

m1@m1-desktop:~$ sudo less /var/log/dmesg
(Nothing has been logged yet.)

Is all I get. I am using 19.2

There are lots of logs in there. In particular, I would like to see what was logged to syslog at the times when it freezes. You should find about a week's worth, some gzipped up:

Code:

m1@Testy:/var/log$ ll sys*
-rw-r----- 1 syslog adm   4328 May  3 15:38 syslog
-rw-r----- 1 syslog adm  12251 May  3 07:35 syslog.1
-rw-r----- 1 syslog adm   2729 May  2 07:35 syslog.2.gz
-rw-r----- 1 syslog adm 104280 May  1 07:35 syslog.3.gz
-rw-r----- 1 syslog adm   2448 Apr 30 07:35 syslog.4.gz
-rw-r----- 1 syslog adm   2928 Apr 29 07:35 syslog.5.gz
-rw-r----- 1 syslog adm  51881 Apr 28 05:39 syslog.6.gz
-rw-r----- 1 syslog adm 105756 Apr 27 07:35 syslog.7.gz

Topic: [OS] nvOC easy-to-use Linux Nvidia Mining - page 29. (Read 418249 times)