Topic: █▓▒░-< [ZPOOL.CA][BTC Multipool] The miners multipool >-░▒▓█ Paid 925+ BTC - page 132. (Read 217687 times)

Did you try out the latest neoscrypt miner just put out by ghostlander? Says 100% increase in efficency

https://bitcointalksearch.org/topic/m.13953935


edit... oh but I guess that is for GPU's not CPU...

cpuminer-win64-generic.exe = ** cpuminer-multi-argon2 1.0.1-dev by testz **
couminer.exe = ** cpuminer-multi 1.2-dev by Tanguy Pruvot (tpruvot@github) **

on a side note, I don't even want to mention it... but today... has been a lot better than yesterday and AFAIK, there has only been one reset today on sha and none on scrypt...

I have disabled a few coins on each which I think are problematic to the issue and results have been positive.

Inventory won't change for a couple days and then I'll re-enable one at a time to see who it actually is.

@JaredKaragen - I wonder what CPU miners you use? I seem to have problems running a lot of pre-compiled CPU optimised miners, so it may be the case I will have to learn to compile these things on windows.

As I understand it, the profitability displayed on the wallet pool status page is a past 24 hour figure. The profitability listed on the coins on the pool page are the currency profitability figures that causes the miner switch. The fact you are switching sounds like you have set it up right. Don't forget qubit, another good GPU algo.

put c=BTC, d=4096 as your password

Ok I'm mining X11,X13 and X15 and putting my hashing speed's in Mh/sec into my password and the miner is switching algo's

but if I then use the figures that show on the web page under "Pool Status/profitability" and my hash speed's to check if the miner switches at the right time I am finding that it does not, this is making me want to put false Mh/sec my password  so the miner switches according to the profitability figure that the web page gives

am I expecting too much accuracy here and should I just put my real hashing speeds in the password and leave it at that ?

cheers

Hello!
So I am sure you've been asked this. But I am struggling getting into your pool. I have an antminer S7 I put the pool as -o stratum+tcp://mine.zpool.ca:3333 My worker is my Bitcoin address, and password is xx. But I cannot get my miner to start working the pool on my Bitmain dashboard or find my worker on the ZPool site. Have you had anyone else experince this? Thank you!

Why is Qubit algo mining UNITUS? It is not on any exchange and therefore worthless

Ive been running into issues specifically with SSD drives;

The system goes all ham and locks up until it does some crazy hacking to the SSD drive.   Happens after a bunch of large file downloads/transfers, and deletions.

The only way to make this behavior go away is to do a deep level format using a special tool; and "start over" with the SSD so to speak.

When the system locks up;  its almost as if it is trying to write cached data that has piled up.   Happens while downloading torrents;  or playing videos over the course of 30min+.  The videos are 300Mb 30 min shows;  or 1Gb 60 min shows;  so they arent all that demanding on the drive...

but this is a problem I have gotten every SSD ive tried so far; to do.  Its rather annoying to have to earase and reload an image;  only to find out i need to reconfigure everything in the OS again to my new configs.  They can be anywhere from a 15 sec delay to 1 min before the HDD activity light stops hacking like crazy and the system works as it should again.

My high-speed hub isnt where I live;  so I download there;  and xfer it to my PC at home....   Sometimes Ill do 36Gb stints/day depending on how well the connection is working and how many people are eating up my bandwidth =P  The node for my parents' neighborhood has no FAP/restrictions on it;  as well as a smaller population density sharing the node.

This kind of mass input/deletion with large filesizes is normally a super bad thing to do to an SSD;  as per the manufacturers.

so... its normally working balls-to-the-wall 24/7... And surprisingly Win10 has been super stable and keeping uptimes well past a month with no issues at all.

zpool started off on one machine and is now running on 3. The stratum server has only the stratum and front end/db processes running on 8 core Xeon , 32gb ram & ssds. Coins are split up over 2 machines, each, 12 core Xeons, 64 gb, just not on SSD's simply because bitcoin is an ass of a blockchain and the SSD's weren't big enough to be comfortable especially in a RAID configuration. None of them swap out at all and carry a load of ~0.4, ~15-20% CPU usage and ~30% RAM usage. All housed within the same data center.

ulimits have been adjusted way out to 102400 and a couple of the stratums use ~50k of the limit.

They appear to handle it without issue... but I wouldn't be surprised if there is something with the threading...

I do get the disconnects on my usb miners, so I don't think it is anything to do with hash rate. I generally only see the problem on the sha256 port (but don't use scrypt). I wonder what the specs of the server are? There are a lot of wallets running on the server, and a lot of stratum client connections to serve. That means a large number of active threads, and even with a lot of cores there is going to be a large run queue. Also, all those wallets are going to use a lot of RAM, so the system maybe swapping. I've only started learning about wallet RPC calls, but I have noticed that sometimes they can be slow to respond, and that's with only a handful of wallets running.
So it sounds like crackfoo may be right about the stratum processes needing to handle the situation more gracefully.

EDIT: And I suppose a lot of fast coins require more frequent getblocktemplate calls?

FURTHER EDIT: It's over 15 years since I was analysing performance issues on an 8 CPU server on a system that run 100's of processes. The system was only using 80-90% CPU, so it took quite a bit of convincing to get them to spend a few $million on upgrading to a 24 CPU server. The performance issues where solved on the new box. So it just goes to show, that on a complex interdependent system, processing capacity can be hit without seeing 100% CPU usage. They where big boxes in those days!

In the case of the RPC call being called in user space by the stratum process, this has to be served by a system thread in the kernel, to be served by the wallet user threads, for a response to be sent through another system thread, to be picked up again by the stratum user threads. On a system with a large run queue to be served, that may take some time.