If you want help you'll have to provide a lot more info than just a compile output
out of any context.

Also if you don't understand that error, you're probably in over your head.

I have to agree. There have been a lot of scam miners posted recently and your post look just  like them:

- closed source
- posted by a newbie user
- targetting newbie miners (only newbies use GUI miners)
- slick ANN
- giving reassurances of trustworthiness

As it stands you've followed the same path as scammers and you can expect to be treated as one
until a trusted third party can vouch for you and your product. The developpers of the software
you imported would be a credible start. I'd like to know what they think of you collecting a dev fee
from their software.

I never trust anyone who says "you can trust me".

You ignored the first paragraph.

Mind your manners, learn how to read, stop picking nits and don't hijack the thread
to start a flame war. Any merit your post might have otherwise had was lost by your
inflammatory attitude.

I could have gone into long technical detail of split phase but the simplified description
makes it easier to understand how how 240v is achieved and was not the central point of
my post. You're the reckless one bragging about running 240v through 120v recepticals.
An electrician would rip you a new one for that.

Getting back on topic and where I started was that an electician, by law, must either do the work
to add 240v circuits, or certify it before it can be connected to the grid.

Depending on the jurisdiction you would have to do more than "consult" an electrician.
You nay be required to have an electrician either do the work or certify it.

But yes 240V is just using the +120 and -120 (red & black) with heavier gauge wiring and a
bigger dual pole breaker. That's how the stove and dryer do it.

That's a lot of capital overhead for a product with a limited lifecycle.

Running a new miner on old hardware is always a challenge. Backward compatibility
isn't always maintained. If your son has any technical skills it would be a good challenge
to get it working.

The error you see could be either incompatible compilation or intensity too high.
Pagefile is not an issue in this case because those cards don't have anywhere near 8 GB each.

If this were Nvidia GPUs it would be necessary to make sure the miner is compiled to support
old hardware. Current default compilation and pre-built Windows binaries may not do so.

New software may not even be able to run on old hardware, This is more likely with new algos.
You may need to use a miner that's been around for a while and would be likely to still have the
legacy code to support old cards.

Once you get it compiled you need to adjust the intensity (usually -i) when starting. Intensity is
important and is different for every card and every algo and is usually chosen automatically by
the miner based on the card model and the algo selected. New miners may not have intensity
information for old cards so it would have to be set manually using trial and error.

I don't know how old your son is or how tech-savvy he is but this could be a good challenge
with lots of learning opportunities.

I'm not so negative about Nicehash, they provide an open market with willing participants on both sides
with them, as brokers, in the midle taking a cut. The effects on the overall crypto market are due to the actions of
their users more than their presence. However, they do tend to act like the elephant in the room at times by
making their own rules. That attitude never seemed to hurt Microsoft despite the anti-Microsoft cults.

The main market effect of Nicehash is the same as any auto-exchange pool. It tends to hurt altoins due
to persistent dumping for BTC. But it creates opportunities at the other end where altcoin specuators can
pick them up more cheaply when the pools dump them.

But I digress.

What is this Nicehash support issue? Did they do something stupid that requires specific miner support?

This looks interesting, the code has the same origin but cpuminer-opt's version of scrypt is
Pooler's code highly optimized for the original scrypt algo. I can't simply copy & paste wownero
but I might be able to use it to find all the places in the Pooler code where R needs to be inserted.
This is a lot of work because Pooler has multiple implementations for different CPU architectures
and uses ASM. I'm weak in x86 asm so it will be diffficult.

I've opened an issue for it but there's no guarantee I'll ever do it.

https://github.com/JayDDee/cpuminer-opt/issues/199

Thanks for the info.

I'm not very familair with the scrypt code but I took a look. Based on the name of the function
"scrypt_1024_1_1_256" I assume those are the parameters N, r, p & hashsize. 1024 is the default
N but can be changed from the command line. I found no mention of r or p paramenetrs in the code
so I assume they are hardcoded at 1, as implied by the naming of the function..

This would suggest that "-a scrypt:8192" won't work for scrypt8k. Have you tried?

A second question without following up on your first, you're just trolling.

You definitely need more RAM with a 8C/16T CPU, especially if you want to mine with it.
I recommend 512MB per thread to handle the most memory hard algos.

Smartphone miners are all scams because nobody with a clue takes smartphone mining
seriously. The apps target naive newbies who would fall for "make money fast" scams.

Mining is a compute intensive program that requires heavy duty compute power that
can handle a full load continously. Anything portable is intentionally designed opposite.
They are designed to use as little power as possible to conserve battery life and don't
have the cooling capacity to run hard for any length of time.

I've got it working for both as 2 seperate algos. Many thanks

Suprnova has a bad habit of reusing algo names. When he made a veil miner he just
added the veil code without changing the algo name.

That's interesting. It doesn't for me with suprminer.

See my previous post, I may have a workaround to avoid the veil code with gin.

Thanks but that's the miner I'm using and it works for veil.

That extra code is only called after a job is received, with GIN the the job never comes.

Edit: OK I've found somehing. If I try mining GIN with X16R I get a job, so the x16rt code
in suprminer is breaking the protocol. I should be able to work around this by defining seperate
algos.

Gin & veil both claim they use X16RT but they are listed seperately at zergpool.
Suprminer X16RT only works for VEIL.

For GIN the miner hangs after setting stratum difficulty message, waiting for work that never comes.
I've waiting several minutes. I've seen delays of a few seconds on occasion for
some algos/pools but eventually the work arrives. With GIN it never arrives.
It's the same at zergpool and zpool.

Clearly there's a difference if zergpool lists it seperately but what is it and how to
make it work?

Anyone test AVX2? Any algo with Lyra2 is good for testing as it has both AVX2 and SSE2 versions.
AVX2 on  Ryzen 1xxx is slower than SSE2.

Stale shares  are always possible if a new job from the pool crosses paths with a share
submitted by the miner using the old job.

The likelyhood of stale shares is directly porportional to the network latency including
processing at either end.

This should only result in a single share, sometimes 2 in quick succession, being stale
before the new job is received.

Stale shares could be reduced with software. Before submitting a share check if the job is
still valid.  There is nothing to gain except maybe perception. Aside from the overhead of
added checking before submission there is also the risk of throwing away a share that might
have been accepted. It's better to just submit it and hope for the best, there's nothing to lose.

Not without a lot more info.

A high barrier to entry is good for those inside the barrier. It's called protectionism.
It seems to be a trend.

Try -a scrypt:8192

If that doesn't work, it's a custom version of scrypt which would be too much work.