@M5M400
I'm having an issue connecting to supportxmr with an address starting with "8". The pool replies with "invalid address supplied" and does not allow connection.

Story: I generated a secondary address in my wallet to dedicate to mining (using the command address new) and the address generated started with "8". That was refused by supportxmr.

Then I created a new account in the same wallet. Again the address generated started with 8 and was refused by the pool.

Both addresses shall be valid as they were generated with the cli wallet.

Any ideas ?

Thanks,
bytiges.

I've seen those puppies and they're sweet. The ROI was 45 days. It's much more now that they're in the wild.
At current prices, they're too expensive, however.

Edit: I wonder if there's a jocker in the Baikal asics too. Now that monero is going to v7, I am very curious to see if the baikal asic is programmable (i.e. an fpga design).

In theory, if could very easily be just a bunch of super-fast memory tied to an fpga that can be *easily* updated via firmware updates.

If that is the case, it will take a little more tweaking to defeat them: I mean jacking up the memory requirements beyond what baikal has on board or changing the algo completely, and going with something totally different.

---------------------------------------------------------------------------------

I'm sorry it did not work for you. I'll try to give you my rationale in the hope that it helps you find the issue.

So, one thing I noticed is that I cannot "start" or "restart" the watchdog right after a reboot. I log on the ssh console then issue the commands and it hangs. However, if I wait enough time after reboot I can (re)-start it and it works normally. Bear in mind I'm only testing with a rig with a single GTC1070 in it. I noticed that the rigs with 13 GTX1060 that I have in production can take much longer time to init and start mining. I have not tested watchdog there yet.

I also noticed that rc.local must have finished for watchdog to be able to start. I think that this is because /etc/init.d/watchdog has a dependency on $all. I however modified my dependencies to be only $local_fs and $network (perhaps this is it). Here's my /etc/init.d/watchdog header
So my fix was to edit the rc.local to add a fixed delay and a restart of the watcdog, but send it in background with the (...)& construct. This way the rc.local script has the chance of terminating. Perhaps you need to increase the delay (just see how much time after reboot you're able to start the watchdog manually).

Regarding the insertion of the modules, you don't need to make it by hand. You only need a single "iTCO_wdt" module in /etc/default/watchdog. It will be inserted with modprobe and will pull all dependent modules.  Here's my /etc/default/watchdog file:
And for reference, here's the fixed watchdog.service:
I also set the nowayout option for the watchdog module, so that there's no way to stop the watchdog once activated.
Hope that helps.

@papampi:

I found a solution for starting watchdog from rc.local. Just call it like this:this will sleep a little before restarting watchdog, but it will do so in the background and allow for rc.local to terminate beforehand.

Now, on a intel mobo I'm loading the iTCO_wdt module and the dmesg output looks good:
bytiges.

@papampi:

the /dev/watchdog* device is created by the module (one device per loaded module is created). /etc/default/watchdog is where you specify the watchdog module to load at watchdog start.

both /etc/init.d/watchdog and the systemctl service look there and load it.

What happens at boot when you use rc.local is that the "start" command gets stuck and never returns. After some time you can do stop and start again and it works then, but not immediately after boot, which is "puzzling" me.

I tried to add a delay (120sec) in rc.local and it won't start watchdog regardless. So I'm trying variations here atm.

watchdog install fails because /etc/init.d/gpu by th00bear does not complain to lsb requirements. You need to add the following to the header (from line 3 onwards):

Also there's an unbalanced quote in /lib/systemd/system/watchdog.service. The execstartpre line should have a single quote at the end ('):
after that apt-get install watchdog (or apt-get -f install to fix it).

then

#systemctl start watchdog

then check that it's running with

#systemctl status watchdog

and finally enable at boot with

#systemctl enable watchdog

and don't forget to fine-tune with /etc/watchdog.conf
also a hardware driver needs to be specified in /etc/default/watchdog.
The drivers are in /lib/modules/$(uname -r)/kernel/drivers/watchdog
Usually (proper) mainboard manuals have the type of watchdog installed. On intel hardware, usually iTCO_wdt works.
You can use the softdog.ko module, but it's not as effective

After all this, I tried rebooting my nvoc rig and watchdog start is stuck in starting state. If I stop and start it by hand on the console, it will start but it won't start by itself. Perhaps there's an issue related to nvoc or not (my other ubuntu boxes start normally).

I tried looking for a fix for about an hour now, and still nogo. :/

EDIT: RE: Blacklisted modules:
There's no need to remove blacklisted modules. /etc/default/watchdog contains the module name to load and watchdog start will load it regardless of blacklist. This is something that cannot be automated because there's not reliable way to know if a hardware watchdog module is present. Some modules load and assume they work, creating the /dev/watchdog* devices. Other will check and fail. It's a mess in general.

@papampi re: hardware watchdog

Sorry for being brief here, but I'll try to give you some pointers.

you should look at ubuntu package watchdog and the watchdogd daemon. When implemented correctly (I hope it is) with the help of the kernel is should work as hardware watchdog timer (on mobos where the hardware watchdog can be enabled in bios or where it's enabled by default).

It works by starting watchdogd which is a daemon that will reset a watchdog (hardware bit in the cpu/mobo) once a minute. Once started, if watchdogd does not reset the timer, a hardware reset occurs.

Sometimes it's possible that there's a hardware issue with the gpus where a simple reset will not be good and you might need a physical power on-off.

hth, bytiges.

In an attempt to maximize hashing returns, I'm trying to use SALFTER_MPH autoswitching instead of the WTM one

The issue I have with it is that it jumps too much between similar coins. This results in pool hopping and difficulty readjustment on each hop. To counter the problem, I have set a long delay between checks.

Is there a better way to set it up, and to maximize the profit ? I'm using 1070s here.

You got lucky. Can you endure 2 months at 0 earnings ? Can you endure 1 year at 0 earnings ? 2 years ?
I'd solo mine only with 100+ asics farm, but that's me.

BTW: Mind your temps. Your third PCB is too hot. You're braced up for trouble.

To those looking for alternative pools:

When I had the D3s in my basement, I got interested in p2pool for dash. I mined on a few public nodes, but at the end some nodes were actually non paying at all.

So at the end I set up a personal p2pool node and mined with it for a few weeks. It was more profitable than the other pools. Payments were immediate at maturity, given directly from the miner fees as they came trough.

I there's interest, I could spin the node up again and give you the IP address to mine on. No fees or strings attached. I'll do it out of curiosity and personal fun.

Please reply if interested.

This is not good news. I sold all my D3s when they were making $10/day net, and BTC as soaring above 17000, dash was 1400. I sold them at a net loss of 20% each. Seems it was a good call, after all.

Thanks again.
So it should be safe to assume that ref and aftermarket are about the same, except for the slower memory. Did you use the same registry tools (and .reg files) that you used in the ref card (I guess they're the same)?

Thank you for sharing.
What is the tension you can run the hynix memory at ? Can it hold 875 or 900mV ? What is the power needs (higher or lower than the ref) ?

@HabBear lol, bitcointalk is a nest of venial creatures.

@gentlemand you you're right, I've been using google and site: for bitcointalk extensively. the problem is that it finds a lot of irrelevant posts too, from a myriad of other threads. Topics on the forum are well separated on their own and when lookng for a say a "setting" or a "script" in relation to some card or the hashrate or drivers versions, you end up with a lot of irrelevant posts from other threads and this requires you to search inside the search results.

Being able to search withing the specific thread is much more precise, specially for things that you've seen before and know the thread where you saw them.

Like I said, when visualizing a thread, the search box is limited to the thread only, so that works. Thanks to TryNinja for pointing that out.

Well,

Searching page by page, in a 1000 page thread, or even 200 page is not what I have in mind.
Also, the "All" pages disappears when a thread gets around 50 or so pages (this is understandable).

Even using google, it very hard to find information because you cannot limit the scope to a single thread.

Thanks for the hint on using the search while looking at a thread. The answer was too simple, so I could not see it

Is there a way to search inside a single thread ?

So, what makes of aftermarket cards are out there ?
I know of Sapphire. Others ?
Also, what memory they're using ?

Hadn't seen it with ETN. What I found strange is that the backlog was about 40minutes but it still meant several hours before my transactions were in the blockchain. I tried with different levels too and same result. Weird, but I guess miners choose a random set of transaction and not always yours is included in it.

I quote myself, and the situation with  ETN is getting worse. Yes, there's big backlog on the chain, but also, I have pending transfers that are not getting trough both outgoing from my wallet and also incoming from the mining pool.

Now, the incoming transactions is what is bothering me. They're shown as "pending" at the pool and the blockchain explorer shows that they're pending with 0 confirmations. It has been 5 hours now and it's way beyond the 40 minutes backlog.

The blocks from the pool are quite large (3.9MB) too.

What could be causing this ?

Anyone care to repost the scripts for autostarting mining ?

thanks.