Pages:
Author

Topic: [ANN] MemoryCoin - page 21. (Read 100345 times)

sr. member
Activity: 420
Merit: 250
August 19, 2013, 08:17:19 AM
@ SlyWax: Thank you
legendary
Activity: 1470
Merit: 1030
August 19, 2013, 07:25:39 AM
Nice stuff by the way FreeTrade.
But you are rounding the display ?
Because the sum is not correct (because of the fractional part I guess).

Thanks, yes there's rounding down going on - the numbers are usually pretty large so it shouldn't matter too much.
sr. member
Activity: 248
Merit: 251
August 19, 2013, 06:49:19 AM
Stas, you should run it from the commande line :
memorycoind --daemon -debugvote=1
or
memorycoin-qt -debugvote=1

But you should check first your .memorycoin folder for a grantawards folder, in witch the most recent version of memorycoin will put the grant logs.

Nice stuff by the way FreeTrade.
But you are rounding the display ?
Because the sum is not correct (because of the fractional part I guess).
sr. member
Activity: 420
Merit: 250
August 19, 2013, 06:19:22 AM
@SlyWax: I have voted for the Pool.

I get an error when I am running this command "-debugvote=1" though the console.
Is there a version where it works?
where do I get it?

Thanks
sr. member
Activity: 248
Merit: 251
August 19, 2013, 06:00:51 AM
Now that we have some nice script, let's try something :

I'm calling you, the small miners, to make a revolution and take those grant from the hand of the wealthiest.
We need to kick the butt of those hidden rich people who are taking our grant away!

That is why I'll open a new REVOLUTION POOL GRANT MINING.

The pool will give you back a % of the grant proportional to your vote (coin in the voting address).
You have to vote for this pool address :

MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb

The address has to be your first choice (send the smallest amount to this address), so that I can calculate your reward.
Feel free to vote for other address like memorycoin foundation as second choice.

When we reach a grant, I'll calculate your share and send it to you.
For the few first grant, I'll double check manually to see that every thing is working well (so expect some delay), then I'll go on fully automatic, so you get your reward earlier.
For this work I'll only take 1 coin from the grant, and it might be even lower after some time if automatic works flawlessly.


PS: I'm reusing the previous grant address since it wasn't used anyway.


We have already 4667 votes in one day.
We can do it !
Don't miss your spot and get the reward by voting for the pool now.
sr. member
Activity: 332
Merit: 250
August 19, 2013, 04:54:22 AM
Is the stability issue still being worked on? New releases used to come every day but now I haven't seen one for a while.
The software has gotten a bit more reliable with the last few releases but I still get runtime errors or it hangs on a grant-block.
My 6-core and 4-core still cant run all night long without stopping Sad

Yes - got an update here and I'm going to be posting further updates here - this thread is becoming very crowded with many different issues, and I don't want to spam the main altcoins forum with continual MC posts -

http://21stcenturymoneytalk.org/index.php/topic,38.0.html

I see a list with known problems there, but no new client Sad
I have taken my 6-core and 4-core machines off this coin and put them on something that runs overnight without crashing.
Looking at the difficulty that has dropped down again, more miners have done this too or their machines hang and they don't know they are not mining.
As soon as there is a stable release I will get back on board again.
legendary
Activity: 1470
Merit: 1030
August 18, 2013, 01:45:28 PM
legendary
Activity: 1470
Merit: 1030
August 18, 2013, 09:46:42 AM
Is there a way to find the results of rounds of voting - either just the latest, or historical?

Start the latest version with the -debugvote=1 switch - should have these available on the web soon.
hero member
Activity: 560
Merit: 500
August 18, 2013, 08:45:44 AM
Is there a way to find the results of rounds of voting - either just the latest, or historical?
hero member
Activity: 518
Merit: 521
August 18, 2013, 08:27:16 AM
I bet you find the 2MB Scrypt is the dominant time factor.

I bet you'll find (on a CPU) the 64MB Scrypt takes twelve times as long as the 2MB Scrypt which takes ten times as long as the 128K Scrypt, so that when the 128K Scrypt is run 120 times interleaved with the 2MB Scrypt that is run 12 times and the 64MB Scrypt that is run once, they each take 1/3 of the time required for the overall hash.

I meant the largest memory Scrypt you are using. So if 64MB, then it would use the most time agreed if you were running them each the same number of times. Now I see you are running the shorter Scrypts more times to compensate. And still the 6GB on the GPU means it can run 96 threads on the 64MB Scrypt to defeat memory latency (and take advantage of the 10 times higher main memory bandwidth in the GPU), whereas the CPU can't. So 2/3 of your scrypts the GPU can trounce the CPU by 100 to 1000 times in theory.

I am expecting roughly, 0.33 x 10 + 0.67 x 100 (or 1000), so roughly the GPU 70 - 700 times faster.

I will get back to you when I have something concrete to grab your attention, even if it proves I was wrong, so that the issue is resolved.

Thanks, looking forward to it. Consider also that the clock is ticking for any GPU implementations. Should have 90% minted within a year, and 10% the next year. It would be regrettable if GPUs or ASICs were to capture the 10% and/or the 2%/year distribution, but not catastrophic.

I am thinking 99% of the 2% per annum could go to GPUs.

Tangentially, I don't understand how you expect to maintain interest in your coin for enough years for it to gain traction, when 90% will already will awarded in one year. You need new adopters continuously, not just the few who got in early.
member
Activity: 102
Merit: 11
August 18, 2013, 07:14:23 AM
Hi,

Something is wrong :-(

I started my client with the -gen switch and started mining, after a night I got 2 blocks and the client crashed.

After start it again and synchronize with the network, I don't have my 45 MCoins any more :-(


I was checking the get miner info from time to time and was geting around 10 mh and the "green" tick was alwas on.  I thought that I was on the safe side.

How can I check that everything is fine, and not get the sad surprise the day after?

Cheers
  MC
legendary
Activity: 1470
Merit: 1030
August 18, 2013, 02:31:20 AM
I bet you find the 2MB Scrypt is the dominant time factor.

I bet you'll find (on a CPU) the 64MB Scrypt takes twelve times as long as the 2MB Scrypt which takes ten times as long as the 128K Scrypt, so that when the 128K Scrypt is run 120 times interleaved with the 2MB Scrypt that is run 12 times and the 64MB Scrypt that is run once, they each take 1/3 of the time required for the overall hash.

I will get back to you when I have something concrete to grab your attention, even if it proves I was wrong, so that the issue is resolved.

Thanks, looking forward to it. Consider also that the clock is ticking for any GPU implementations. Should have 90% minted within a year, and 10% the next year. It would be regrettable if GPUs or ASICs were to capture the 10% and/or the 2%/year distribution, but not catastrophic.
hero member
Activity: 518
Merit: 521
August 18, 2013, 01:20:45 AM
Well it's anticipated that specialized hardware will be able to run parts of the algorithm more efficiently. However to run the whole hash efficiently you'd need to run all three parts efficiently (four counting SHA512), and specialized hardware to do that would look a lot like . . . . . . a CPU.

I bet you find the 2MB Scrypt is the dominant time factor.


I would have been interested in a detailed discussion on these points 2 weeks ago when there was more scope for re-engineering.

Understood. I just discovered my deeper insight into Scrypt and Litecoin this week.

I will get back to you when I have something concrete to grab your attention, even if it proves I was wrong, so that the issue is resolved.
sr. member
Activity: 248
Merit: 251
August 18, 2013, 01:05:45 AM
Now that we have some nice script, let's try something :

I'm calling you, the small miners, to make a revolution and take those grant from the hand of the wealthiest.
We need to kick the butt of those hidden rich people who are taking our grant away!

That is why I'll open a new REVOLUTION POOL GRANT MINING.

The pool will give you back a % of the grant proportional to your vote (coin in the voting address).
You have to vote for this pool address :

MVTEoEoiMwtXEeHDUYfuwA9ZvbKSH8Jfqb

The address has to be your first choice (send the smallest amount to this address), so that I can calculate your reward.
Feel free to vote for other address like memorycoin foundation as second choice.

When we reach a grant, I'll calculate your share and send it to you.
For the few first grant, I'll double check manually to see that every thing is working well (so expect some delay), then I'll go on fully automatic, so you get your reward earlier.
For this work I'll only take 1 coin from the grant, and it might be even lower after some time if automatic works flawlessly.


PS: I'm reusing the previous grant address since it wasn't used anyway.
legendary
Activity: 1470
Merit: 1030
August 18, 2013, 01:02:37 AM

I am not sure until I run some tests, but my strong belief (based on good analysis) is that that you are hitting memory latency in your CPU with the 2MB Scrypt, but the GPU will not be. Thus it is going to toast your CPU. This is not a minor problem, rather I conjecture it is total failure to get what you intended. The reason I suspect this, is because the GPU can run 6 x 1024 MB ÷ 2 MB = 3096 threads and thus entirely mask away the latency. Whereas you do nothing to mask the latency on the CPU as far as I can see in your code.


Well it's anticipated that specialized hardware will be able to run parts of the algorithm more efficiently. However to run the whole hash efficiently you'd need to run all three parts efficiently (four counting SHA512), and specialized hardware to do that would look a lot like . . . . . . a CPU.


You appear to have a serious fail here, but I would need to build a CPU miner to test my hypothesis.

Interested in any diagnostics you're seeing on the CPU miners we've got available.


If instead you don't want to share synergy or simply have other priorities demanding your attention, then that is fine too.

I would have been interested in a detailed discussion on these points 2 weeks ago when there was more scope for re-engineering. As it stands now, the show is on the road so I don't want to be switching the engine unless it's clear the one we've got is failing. If you can demonstrate that you will have the pleasure of my undivided attention.
hero member
Activity: 518
Merit: 521
August 18, 2013, 12:57:46 AM
I think it is better I let you launch as is, then later when I build my test suite, I will confirm if I was correct or incorrect.

Agreed?

I don't have the time immediately right now to create a build environment and compile and test your code, thus the best I could offer would be code or pseudo-code and without a test suite you are not likely to believe my hypothesis, thus you wouldn't be motivated to make my code work properly.

So at least I made you aware of this possibility, then we deal with it later when I have the goods in hand.
hero member
Activity: 518
Merit: 521
August 18, 2013, 12:45:00 AM

It doesn't need to be linear, because the FLOPS cost in GPUs is so much lower than in a CPU system.

It appears to me that what happens in a GPU (which is why Intel's hyperthreading is faster than just 4 hardware cores) is that when there are many logical threads, then thread blocks on main memory latency are not a factor, because some other thread can run which has already loaded its main memory access into cache. Thus the GPU is always able to achieve the 200+GB/s main memory throughput, because the latency is masked by the probability of numerous threads.


So it's not just that the improvements in adding cores are not linear . . . it's that they appear to be converging to an upper value, suggesting that they're hitting a limitation other than cycles per second. I'm assuming that's related to memory access, either cache memory size or main memory access.  I'm assuming too that a GPU will hit that limit too, and any increased performance because of wider memory bus, speed or cache would be offset by the slower cores.

I am not sure until I run some tests, but my strong belief (based on good analysis) is that that you are hitting memory latency in your CPU with the 2MB Scrypt, but the GPU will not be. Thus it is going to toast your CPU. This is not a minor problem, rather I conjecture it is total failure to get what you intended. The reason I suspect this, is because the GPU can run 6 x 1024 MB ÷ 2 MB = 3096 threads and thus entirely mask away the latency. Whereas you do nothing to mask the latency on the CPU as far as I can see in your code.

You make other good points and I don't have the time to give them the attention they deserve immediately. I'm sure there are improvements to be made in the hashing algorithm to make it more GPU resistant, but I'm more concerned with having one that is 'good enough' rather than a perfect one that might fork the coin or cause loss of momentum.

I think yours is worse than Litecoin's by a factor of 10 or 100, i.e. 100 to 1000 times slower CPU than the GPU since Litecoin is already 10 times slower CPU than GPU!  Shocked At least Litecoin stays within L2 cache, and it is not just the memory bandwidth but the TLB and L2 cache reloads that run 100+ cycles that kill you.

You appear to have a serious fail here, but I would need to build a CPU miner to test my hypothesis.


I am going to avoid talking about your holistic design because we have some disagreement,

Yes, there's a lot we disagree on. Have you considered implementing your ideas in a new coin? That's what I did when I decided all the other coins had it wrong!

Yes I am, but as I said, if I can help you and at the same time benefit from having my idea tested earlier, then it is win-win for both us, in spite of our disagreement on orthogonal features of MemoryCoin. There is no need for me to comment further about your grants. Best is you try it, then we all learn from the result. I wouldn't copy your grants, nor your 2% deflationary coin, so there is no competition coming from me against MemoryCoin on those features. I am delighted you introduced a coin with continuous inflation (albeit only 2%) and not ridiculously high as Inflatacoin, so if you get adoption then it opens the door for a coin with slightly higher rate of inflation.

If instead you don't want to share synergy or simply have other priorities demanding your attention, then that is fine too.
sr. member
Activity: 248
Merit: 251
August 17, 2013, 11:53:53 PM
Here is a new script,

It's meant to recap every thing when you come back to your mining PC.
What I like about it is that if I've mined some block since the last time I checked, it will display a blue bar with the number of coin mined for this period.
There is always some suspense when I run it, and the good thing is I don't have to remember my last balance to see if I catched something.

The output :
path to .memorycoin -- the date/time you executed the sript
New minted coin or balance change since last run (nothing if nothing new)
Stats: {
    "blocks" : 2993,
    "currentblocksize" : 1000,
    "currentblocktx" : 0,
    "difficulty" : 0.00023274,
    "errors" : "",
    "generate" : true,
    "genproclimit" : X,
    "hashespersec" : xx.xxxxxx,
    "pooledtx" : 0,
    "testnet" : false
}
Confirmed Balance: xxx.xxxxxxxx
Immature Balance:  xxx.xxxxxxxx        TX:  x
Total Balance:          xxx.xxxxxxxx 

Last 3 minted date :
date in your local time (system pref)

Blocks since start ( date of start UTC ) : XXX
Connections: XXX
--
Save the sript below to a file named mpeek for example, type : chmod 700 mpeek to make it executable.
To use it type ./mpeek or just mpeek if it's in your $PATH.
replace the line "miner=memorycoind" with "miner=/pathTo/theNameOfYourExe" if you changed the name of the memorycoin executable.

Code:
#!/bin/bash
coindir=~/.memorycoin
miner=memorycoind

echo ${coindir} -- $(date)

conf=$(${miner} getbalance)
transaction=$( ${miner} listtransactions "" 9999 )
immature=$( echo "${transaction}" | grep -A1 immature | grep amount  | awk -F':' '{ print $2 }'| awk -F',' '{ s1+=$1 }END { printf "%5.8f", s1 }')
total=$(echo "scale=4;${conf} + ${immature}" | bc)
mybalance=$(cat ${coindir}/mybalance)

if test ! "$mybalance" = "$total"
then
   echo -en "\033[46m                      "
   minted=$(echo "scale=8;${total} - ${mybalance}" | bc)
   echo -e "${minted} \033[0m"
   echo -n "${total}">${coindir}/mybalance
fi

echo "Stats: $(${miner} getmininginfo)"
printf "Confirmed Balance: %*s\n" 13 "${conf}"
printf "Immature Balance:  %*s" 13 "${immature}"
echo "        TX: " $(echo "${transaction}" | grep immature | wc -l)
printf "Total Balance:     \033[32m%*s \033[0m \n" 13 "${total}"
echo
echo Last 3 minted date :
echo "${transaction}" | egrep -A9 "\"generate\"|immature" | grep timereceived | tail -n 3 | cut --delimiter=":" --fields=2 | while read VAR ; do date -d "@$VAR" ; done
echo

numligneA=$( grep -n "Startup time:" ${coindir}/debug.log |tail -n 1 )
numligne=$( echo "${numligneA}" | awk -F: '{printf $1}' )
numligneDate=$( echo "${numligneA}" | awk -F: '{print $3":"$4":"$5}' | sed 's/^ *//g' )

echo -en "Blocks since start ( \033[35m${numligneDate} UTC\033[0m ) : "
tail -n +${numligne}  ${coindir}/debug.log | grep SetBestChain: | grep -c date

echo "Connections: $(${miner} getconnectioncount)"
echo

Edit : you have to run it once to initialize the balance.
legendary
Activity: 1470
Merit: 1030
August 17, 2013, 11:29:30 PM
The MemoryCoin Foundation -
http://memorycoin.org/foundation/
legendary
Activity: 1470
Merit: 1030
August 17, 2013, 10:00:57 PM

It doesn't need to be linear, because the FLOPS cost in GPUs is so much lower than in a CPU system.

It appears to me that what happens in a GPU (which is why Intel's hyperthreading is faster than just 4 hardware cores) is that when there are many logical threads, then thread blocks on main memory latency are not a factor, because some other thread can run which has already loaded its main memory access into cache. Thus the GPU is always able to achieve the 200+GB/s main memory throughput, because the latency is masked by the probability of numerous threads.


So it's not just that the improvements in adding cores are not linear . . . it's that they appear to be converging to an upper value, suggesting that they're hitting a limitation other than cycles per second. I'm assuming that's related to memory access, either cache memory size or main memory access.  I'm assuming too that a GPU will hit that limit too, and any increased performance because of wider memory bus, speed or cache would be offset by the slower cores.

You make other good points and I don't have the time to give them the attention they deserve immediately. I'm sure there are improvements to be made in the hashing algorithm to make it more GPU resistant, but I'm more concerned with having one that is 'good enough' rather than a perfect one that might fork the coin or cause loss of momentum.

I am going to avoid talking about your holistic design because we have some disagreement,

Yes, there's a lot we disagree on. Have you considered implementing your ideas in a new coin? That's what I did when I decided all the other coins had it wrong!
Pages:
Jump to: