Topic: [ANN] [PASC] PascalCoin, true deletable blockchain - V3 Hardfork on block 210000 - page 361. (Read 990837 times)

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.

Looks like you got a few blocks the past hour.

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

Total, or per coin? lol

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

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. Gotcha. TY. Testing a multi gpu rig vs a single see how many blocks they solve.

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.


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.

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?

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

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.

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.

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

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.

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?


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).

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.

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!

Awesome, Thanks!

I believe I have it working on a dual GPU system and will wait and see the results!

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.

Alright, here's the CUDA miner with the working proxy: https://github.com/Vorksholk/PascalCoin-CUDA/releases/download/v1.02/CUDA_Pascal_v1.02.zip

VirusTotal: 0/55 https://virustotal.com/en/file/a7c451c3a19c4052cdf10d974da057f51bdb957734bb47c29115044741540648/analysis/1477111465/

These instructions are slightly different than the previous GPU miner! Take note!
1. You must already have PascalCoin installed. If you don't have it, download it from sourceforge here: https://sourceforge.net/projects/pascalcoin/. Once it is installed, run the PascalCoinWallet.exe provided in the download.
2. You must be using a 256-bit secp256k1 key. This is the default behavior of the PascalCoin wallet.
3. Your miner name must be exactly 8 characters long. The miner expects that the input is exactly 176 total bytes (which is achieved by using a secp256k1 key and a 10-character name)  NOTE: NOT 10 like before! 8 characters, because the last two will be used to identify each GPU!
4. You must have RPC enabled in your client (any port of your choosing, default is 4009)
5. You must run the proxy miner (PascalProxyv1.jar) in the same directory as the PascalCoinCUDA_ProxyMiner_smXX.exe file you run (everything is where it needs to be if you just extract the provided zip).

To run the proxy, just double-click on it on Windows, or in Linux do
How does this work? The proxy connects to the PascalCoin wallet, grabs the current mining data, and then creates a headerout.txt file for the miner(s) to use. In return, the miner(s) write their shares to files called datainXX.txt, where XX is the GPU number (starting at 00, and going through 99). The miners use the device argument (0 if none is provided) to determine which device to use, and that's the file they write out to. The proxy waits for changes in those datainXX files, and then ferries the results back to the PascalCoin wallet.

You will notice that the PascalCoin wallet log constantly says "Sending Error JSON RPC id () : Error: Proof of work is higher than target" whenever you find a share. This is because the proxy's behavior is to submit any target 24000000 share, and since the target is 29xxxxxx, only about 1 in 2^5 = 32 shares will be an actual block. At a target of 2Axxxxxx, that'd be 2^6 or 64 shares. At a target of 2Bxxxxxx, that'll be 2^7 or 128 shares. etc.

Whenever I can get around to it, the OpenCL miner will work with this proxy.

Bottom line: you no longer need to rely on my modified PascalCoin wallet. You can use the official one from the developer, and run the proxy. The proxy won't work with old versions of the miner, but it will work with the version included in the zip linked above.