[PASC] PascalCoin: Induplicatable NFT

[Vorksholk]

Thanks Vork.

I seem to have a problem: the proxy isn't updating the headerout.txt file when a block is found on the network.
In the console, the miner notify is working just fine.

Did anyone encounter the same issue?
Thanks!

So you're seeing miner-notify with PascalProxyv1.jar, but the file "headerout.txt" in the same directory as PascalProxyv1.jar isn't changing? Try deleting it and running PascalProxyv1.jar again, does it reappear?

Thanks for all the work. Hope it's worthwhile your time to do it. :-)

Any way to put back the MH display into the proxy_smxx miners? It's not showing anything other than the shares.

That's weird, the proxy_smxx miners are the exact same code as before except the filename to write data to has changed (and on my machines, I'm seeing the hashrate printed out).

[1714827176]

1714827176

[1714827176]

1714827176

[1714827176]

1714827176

[1714827176]

1714827176

[1714827176]

1714827176

[Vorksholk]

Thank you very much for what you are doing!
Can you help, I can not start mining. Can not figure out where to save files from the "PascalCoin_CUDA_ProxyMiner" folder. And in what sequence they run. Thank you. And please forgive me for my bad english.

You can leave all of the files in PascalCoin_CUDA_ProxyMiner where they are--just extract the zip file somewhere. You run the proxy first, give it the information it asks about (host will be 127.0.0.1, port will be 4009, number of GPUs to support is the number of cards you want to mine with, and your miner name is the miner name you enter in the PascalCoin wallet), and then run the PascalCoinCUDA_ProxyMiner_smXX.exe miner in the same directory. Multiple GPUs will have to be launched from the command line with an argument, so make sure you cd to the directory they are in first to ensure their working directory is correct.

[thedreamer]

Looking at the files, the headerout.00 and datain00.txt are the same time , but datain01.txt is an older date. (Using 2 GPU's on a test rig).
Runing different proxy_smxx miners.

Looks like the files are not updating as fast as the blocks are solved though

[anorganix]

So you're seeing miner-notify with PascalProxyv1.jar, but the file "headerout.txt" in the same directory as PascalProxyv1.jar isn't changing? Try deleting it and running PascalProxyv1.jar again, does it reappear?

Exactly, this is the issue.
If I delete the the txt and restart the proxy it is okay, but I can't leave it unattended as I am missing possible blocks.
Mining with old solution at the moment.

[Eyedol-X]

Well it appears to be updating correctly for me on 2 systems and each system appears to be hashing at same rate

1 system has 2 gpu's both showing reported hash about the same speed and both finding nonces at close to a similar rate, one has 34 now and the other has 36

On a totally different system with 1 GPU, Similar to GPU in above system, has about 33 nonces and was started just after my first system.

No blocks yet but I looked at text files and watched the live update to each window when finding a nonce, on the multiple GPU system they all seem to update at same time.

[ICOcountdown.com]

New PascalCoin Build 1.0.8  - CROSS COMPATIBLE

Works with Windows and Linux

Full source code (MIT license) at Github: https://github.com/PascalCoin/PascalCoin

Windows installer and Ubuntu Desktop 16.04 Binaries at SourceForge: https://sourceforge.net/projects/pascalcoin

Build 1.0.8.0 - 2016-10-20
--------------------------
- Cross compatible
- Can compile with Delphi or Lazarus (Free Pascal)
- New storage system. No more access database
- Network hashrate calculation

Remember... if you enjoy it... make a donation to the project:
BTC 16K3HCZRhFUtM8GdWRcfKeaa6KsuyxZaYk   

Much appreciated - very cool we can use it on linux now.

[thedreamer]

I see a lot of submitted shares from the GPU's liek this :

GPU 0 submitted a share [payload: xxxxxxxx00 nonce: -1311227863 timestamp: 1477171165]

They are showing a negative nonce, some positive.

Any ideas?

[Vorksholk]

Well it appears to be updating correctly for me on 2 systems and each system appears to be hashing at same rate

1 system has 2 gpu's both showing reported hash about the same speed and both finding nonces at close to a similar rate, one has 34 now and the other has 36

On a totally different system with 1 GPU, Similar to GPU in above system, has about 33 nonces and was started just after my first system.

No blocks yet but I looked at text files and watched the live update to each window when finding a nonce, on the multiple GPU system they all seem to update at same time.

Yup, you're right. Given the design of the standalone miners, the proxy needs to create a different headerout.txt file for each GPU, since that data includes the miner name (which needs to be different for each GPU mining). Will update tonight, hopefully.

I see a lot of submitted shares from the GPU's liek this :

GPU 0 submitted a share [payload: xxxxxxxx00 nonce: -1311227863 timestamp: 1477171165]

They are showing a negative nonce, some positive.

Any ideas?

Negative nonces aren't a problem. Bit of a Comp-Sci lesson: "negative" numbers are actually just "large" numbers interpreted in such a way that they're negative. For example, with 8 bits, the largest number I can represent is 11111111, which is 255. Or I can interpret it as a negative number, in which case (a bit of a simplification here), it's -1. 11111110 is -2. 11111101 is -3. Etc. It's called two's complement.

The idea is that, if I want negative numbers, I can take my normal range (0 to 255, in the case of 8-bit numbers), and partition about half of it as negative numbers. In this way, I can have numbers from -128 to 127. Similarly with 32-bit numbers, we could either have all positive integers from 0 to 2^32, or have negative numbers and positive numbers, which span from -2^31 to 2^31 - 1.

In this way, -1 in a 32-bit signed integer is the same as 2^32 - 1 in an unsigned integer. In hex, the number FFFFFFFF is either 4,294,967,295 or -1, depending on whether you interpret it as a signed or unsigned integer. The binary -- 11111111111111111111111111111111 -- is the same either way. The way JSON decoding works, a number larger than 2^31-1 isn't seen as a 32-bit integer, because 2^31 would require more than 31 bits plus a sign bit to represent, assuming we're operating with signed bits. So instead, we just give it a negative number which represents the same bit pattern, and it's happy.

The pascal network itself uses unsigned integers--Cardinals--but the JSON decoder expects signed 32-bit integers. As such, approximately half of the nonces will actually be negative when interpreted as signed ints. They're not invalid or different, the negative number is just another way to express the same bit pattern as a positive number in a different system.

[thedreamer]

Ahh. Gotcha. TY. Testing a multi gpu rig vs a single see how many blocks they solve.

[Vorksholk]

Ahh. Gotcha. TY. Testing a multi gpu rig vs a single see how many blocks they solve.

I ran a two-gpu rig overnight and it got the exact same number of blocks as a single-GPU rig (all GPUs are the same), and I looked more into this, so I know for sure multi-GPU rigs for the moment are only effectively mining with the power of one GPU. I'm testing a fix right now.

[thedreamer]

Ahh. Gotcha. TY. Testing a multi gpu rig vs a single see how many blocks they solve.

I ran a two-gpu rig overnight and it got the exact same number of blocks as a single-GPU rig (all GPUs are the same), and I looked more into this, so I know for sure multi-GPU rigs for the moment are only effectively mining with the power of one GPU. I'm testing a fix right now.

Ahh. That explains it. Even though in the .jar proxy it shows as shares being submitted by individual / different GPU's.

[jiggytom]

wonder what the miner "ocminer" plans to do with boat loads of coins he has mined

Sell @ $0.20 +/- IMHO.

Total, or per coin? lol

[Vorksholk]

Ahh. Gotcha. TY. Testing a multi gpu rig vs a single see how many blocks they solve.

I ran a two-gpu rig overnight and it got the exact same number of blocks as a single-GPU rig (all GPUs are the same), and I looked more into this, so I know for sure multi-GPU rigs for the moment are only effectively mining with the power of one GPU. I'm testing a fix right now.

Ahh. That explains it. Even though in the .jar proxy it shows as shares being submitted by individual / different GPU's.

Right--the problem stems from each GPU hashing the same data. Effectively two GPUs will hash slightly faster than one with the current system if they are slow enough that they don't complete a kernel run every second, because the timestamp will then be different at some points during both miners' running. However, GPUs fast enough to complete one or more kernel grinds a second will mostly duplicate each others' work, because the headerout file contains the miner name (like VorkGPUs01 or VorkGPUs00), so both GPUs are hashing the same 164 bytes of input data, adding their own 4-byte nonces which are deterministically produced (so two miners would produce the same nonce iteration, assuming the same kernel launch parameters (block and grid size, which are currently hard-coded into the binaries and set at what seemed to be the most efficient parameters on 9xx and 10xx cards during my testing), as well as the same 4-byte timestamp.

Still waiting to find a block with my new solution, but everything appears to be working correctly. Just a dumb oversight on my part, just waiting to get a block from both GPUs on the test system to make sure everything's kosher

[thedreamer]

Right--the problem stems from each GPU hashing the same data. Effectively two GPUs will hash slightly faster than one with the current system if they are slow enough that they don't complete a kernel run every second, because the timestamp will then be different at some points during both miners' running. However, GPUs fast enough to complete one or more kernel grinds a second will mostly duplicate each others' work, because the headerout file contains the miner name (like VorkGPUs01 or VorkGPUs00), so both GPUs are hashing the same 164 bytes of input data, adding their own 4-byte nonces which are deterministically produced (so two miners would produce the same nonce iteration, assuming the same kernel launch parameters (block and grid size, which are currently hard-coded into the binaries and set at what seemed to be the most efficient parameters on 9xx and 10xx cards during my testing), as well as the same 4-byte timestamp.

Still waiting to find a block with my new solution, but everything appears to be working correctly. Just a dumb oversight on my part, just waiting to get a block from both GPUs on the test system to make sure everything's kosher

Looks like you got a few blocks the past hour.

[Vorksholk]

Right--the problem stems from each GPU hashing the same data. Effectively two GPUs will hash slightly faster than one with the current system if they are slow enough that they don't complete a kernel run every second, because the timestamp will then be different at some points during both miners' running. However, GPUs fast enough to complete one or more kernel grinds a second will mostly duplicate each others' work, because the headerout file contains the miner name (like VorkGPUs01 or VorkGPUs00), so both GPUs are hashing the same 164 bytes of input data, adding their own 4-byte nonces which are deterministically produced (so two miners would produce the same nonce iteration, assuming the same kernel launch parameters (block and grid size, which are currently hard-coded into the binaries and set at what seemed to be the most efficient parameters on 9xx and 10xx cards during my testing), as well as the same 4-byte timestamp.

Still waiting to find a block with my new solution, but everything appears to be working correctly. Just a dumb oversight on my part, just waiting to get a block from both GPUs on the test system to make sure everything's kosher

Looks like you got a few blocks the past hour.

Yup, but I have multiple systems mining under the same name. My test rig got 1 block with GPU #1, and if I get 1 block with GPU #0 I can be pretty sure everything is perfect.

The update will require new CUDA mining binaries too, btw.

[Vorksholk]

Found a block on both miners and all of my debugging shows nothing but good results, so here's the proxy version 2 with cuda miners updated to support proxy v2:

https://github.com/Vorksholk/PascalCoin-CUDA/releases/download/v1.03/CUDA_Pascal_v1.03.zip

AMD miner coming in the next few hours.

[ICOcountdown.com]

wonder what the miner "ocminer" plans to do with boat loads of coins he has mined

Sell @ $0.20 +/- IMHO.

Total, or per coin? lol

It isn't actually OCminer it is someone else using his name.

[thedreamer]

Found a block on both miners and all of my debugging shows nothing but good results, so here's the proxy version 2 with cuda miners updated to support proxy v2:

https://github.com/Vorksholk/PascalCoin-CUDA/releases/download/v1.03/CUDA_Pascal_v1.03.zip

AMD miner coming in the next few hours.

How can you tell if GPU 0 or GPU 1 found a block?

And I can not wait for the AMD GPU miner.

[Vorksholk]

Found a block on both miners and all of my debugging shows nothing but good results, so here's the proxy version 2 with cuda miners updated to support proxy v2:

https://github.com/Vorksholk/PascalCoin-CUDA/releases/download/v1.03/CUDA_Pascal_v1.03.zip

AMD miner coming in the next few hours.

How can you tell if GPU 0 or GPU 1 found a block?

And I can not wait for the AMD GPU miner.

If you're using a name exclusively for a single rig, then you can just look at what the number is after the name. If you're mining with multiple pascal wallets on multiple machines all using the same miner name, then you need to pay attention to which nonce shows up in the any pascalcoin wallet when that block is announced in the logs, and see which of your machines with the gpu listed in the miner name (VorkGPUs00 for example is the name all of my GPUs I have at device #0 in my rigs are mining with, VorkGPUs01 is for all GPUs at device #1) mined that nonce by looking at the output in the proxy (or converting to hex and finding it in the miner output itself).

[thedreamer]

Ahh yeah. Forgot about the numerical convention after the 8=char walletname.