|
Message-ID: <CAAepdCbD0NTs8sawATTaQr9COzt5+pmJKzyCuS3wAw9i-xO3uA@mail.gmail.com>
Date: Fri, 26 Jul 2013 21:57:10 +0100
From: Rafael Waldo Delgado Doblas <lord.rafa@...il.com>
To: john-dev@...ts.openwall.com
Subject: Parallella: Litecoin mining
Hello,
Second daily report.
Accomplishments:
1. Start to move Scrypt.c to Epiphany.
Priorities:
1. Move Scrypt.c to Epiphany.
3. Get one instance of Scrypt runing on one Ephipany core.
3. Expand to the rest of cores.
4. Get a detailed decryption of Scrypt.c. (I have sent a mail to cKolivas).
Regards,
Rafael.
Well at this point I know what I should modified in CGMiner (I hope). I I'm
available to run Scrypt in one core looks really easy expand to the rest of
cores because of how is CGMiner coded. I didn’t get the detailed
description of Scrypt yet but even if I don’t have it, I could start to
work con Scrypt port.
Each epiphany core has 32K and the cKolivas scyrpt implementation needs
128,5K plus the executable binary image size. LiteCoin has the next Scrypt
parameters:
r = 1
p=1
N=1024
If I look in the reference implementation: "V" will need 128KB, "XY" 256B
and "B" 128B then I the reference implementation will need ~128,37KB plus
the executable binary image size.
The Alexander's escrypt-tmto1 needs ~64K plus the executable binary image
size then even with this TMTO ratio is not enough to work with Parallella.
I was thinking in raise the CPU use in escrypt-tmto1 but is there a better
way to get Scrypt on Parallella without raise cpu use? Do I losse
something? Have I missed anything?
BTW: The only function that we need to port to Epiphany is:
scrypt_1024_1_1_256_sp(data, scratchbuf, ostate);
data is the plaintext
scratchbuf is a memory area to store V XY and B.
ostate is the hash.
scratchbuf will be inside of the epiphany core.
Regards,
Rafael.
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.