bensam123
|
|
January 27, 2015, 04:14:27 PM |
|
Another question, if you're plotting with the GPU plotter with 'direct write' so it optimizes and plots at the same time, how much slower does it go then normal plotting? It also looks like it freezes when you start plotting, but it's still writing to the disk, no status text is updated. Does stagger size matter with 'direct write'? If it's properly defraged couldn't you effectively have a stagger size of like 1024 and it wouldn't matter?
Bump on this... It takes so long to plot, a few questions help a lot.
|
|
|
|
Merick
|
|
January 27, 2015, 04:41:16 PM |
|
Another question, if you're plotting with the GPU plotter with 'direct write' so it optimizes and plots at the same time, how much slower does it go then normal plotting? It also looks like it freezes when you start plotting, but it's still writing to the disk, no status text is updated. Does stagger size matter with 'direct write'? If it's properly defraged couldn't you effectively have a stagger size of like 1024 and it wouldn't matter?
Bump on this... It takes so long to plot, a few questions help a lot. https://burstforum.com/index.php?threads/gpu-plot-generator.45/This thread should answer your questions. Specific details in the middle of that thread https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-12#post-3252Hopefully these conversation can move to the forum and off of this thread for better organization. Good-Luck
|
|
|
|
mmmaybe
|
|
January 27, 2015, 05:10:47 PM Last edit: January 27, 2015, 05:22:21 PM by mmmaybe |
|
New article, front page on a major crypto site: "What happened to Ethereum?"... https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/One of the promising applications of the block chain technology are smart contracts. Different startups have been working on launching smart contracts, like Ethereum, but it would appear that a small crypto startup has beaten everyone else to it. Their tweet: CCN claims to have more than 12,000 on their email list and 300,000 unique visitors. They have +23,000 followers on Twitter.
|
|
|
|
xizmax
|
|
January 27, 2015, 05:19:32 PM |
|
146 Shares already. Nice work mate!
|
|
|
|
bensam123
|
|
January 27, 2015, 05:23:08 PM Last edit: January 27, 2015, 05:38:58 PM by bensam123 |
|
Another question, if you're plotting with the GPU plotter with 'direct write' so it optimizes and plots at the same time, how much slower does it go then normal plotting? It also looks like it freezes when you start plotting, but it's still writing to the disk, no status text is updated. Does stagger size matter with 'direct write'? If it's properly defraged couldn't you effectively have a stagger size of like 1024 and it wouldn't matter?
Bump on this... It takes so long to plot, a few questions help a lot. https://burstforum.com/index.php?threads/gpu-plot-generator.45/This thread should answer your questions. Specific details in the middle of that thread https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-12#post-3252Hopefully these conversation can move to the forum and off of this thread for better organization. Good-Luck I already checked through that thread and read the relevant posts. It doesn't answer the above questions though as I was asking for other peoples experience with direct write and stagger size with direct write. That thread is also not active, so it's sorta pointless to post there. Also, I finished optimizing one of my plots using the optimizer. However the newly 'optimized' plot is now smaller then the old plot by 5GB and of course the sizes don't match when I start up blagos miner. Is this normal? Did something go wrong along the way? Hmmm... after adjusting the name of the file it only finishes 3s faster then the old plots (also it appears to be corrupt now).
|
|
|
|
mmmaybe
|
|
January 27, 2015, 05:30:43 PM |
|
New article, front page on a major crypto site: "What happened to Ethereum?"... https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/One of the promising applications of the block chain technology are smart contracts. Different startups have been working on launching smart contracts, like Ethereum, but it would appear that a small crypto startup has beaten everyone else to it. Their tweet: CCN claims to have more than 12,000 on their email list and 300,000 unique visitors. They have +23,000 followers on Twitter. 146 Shares already. Nice work mate! Gonna contact them about an error in the article, yes, really nice that we are getting noticed!
|
|
|
|
Merick
|
|
January 27, 2015, 06:11:54 PM |
|
Another question, if you're plotting with the GPU plotter with 'direct write' so it optimizes and plots at the same time, how much slower does it go then normal plotting? It also looks like it freezes when you start plotting, but it's still writing to the disk, no status text is updated. Does stagger size matter with 'direct write'? If it's properly defraged couldn't you effectively have a stagger size of like 1024 and it wouldn't matter?
Bump on this... It takes so long to plot, a few questions help a lot. https://burstforum.com/index.php?threads/gpu-plot-generator.45/This thread should answer your questions. Specific details in the middle of that thread https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-12#post-3252Hopefully these conversation can move to the forum and off of this thread for better organization. Good-Luck I already checked through that thread and read the relevant posts. It doesn't answer the above questions though as I was asking for other peoples experience with direct write and stagger size with direct write. That thread is also not active, so it's sorta pointless to post there. Also, I finished optimizing one of my plots using the optimizer. However the newly 'optimized' plot is now smaller then the old plot by 5GB and of course the sizes don't match when I start up blagos miner. Is this normal? Did something go wrong along the way? Hmmm... after adjusting the name of the file it only finishes 3s faster then the old plots (also it appears to be corrupt now). Benchmark Comparison - Direct vs Buffer - https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-11#post-3014Why Direct is Slower than Buffer - https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-11#post-3034Plot size will remain the same after optimization, if it is not then something went wrong along the way. Did you run out of disc space? Information about Stagger setting when Direct Plotting - https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-13#post-3348During a direct right method, the stagger setting is used to setup a ram buffer for pre-ordering of the nonces. In your example, a stagger size of 1024 during a direct right method will just use 1024KB of RAM for the nonce buffer re-ordering. In this thread and the thread on the forums a few people have complained about the reliability of the direct right method, also the performance hit for direct right compared with just plotting and optimizing does not appear to be worth it. Maybe someone else can add some information to this topic. Just because no one has posted in the BurstForum thread about the GPU plotter doesn't mean it's dead. This seems like the perfect type of question to ask in a Burst forum within the GPU plotter post. I'm guessing the regulars have had their questions answered you would be a perfect candidate to awaken the thread and maybe Cryo will answer your questions directly
|
|
|
|
pinballdude
|
|
January 27, 2015, 07:07:58 PM Last edit: January 27, 2015, 07:22:22 PM by pinballdude |
|
(edit)
running the 1.2.1 precompiled jar gives me other results than running my compiled version of 1.2.1, using my fork at github, which *should*'ve been updated with the 1.2.1 on the burst github.
I will compare sources and trace back and see what's the cause, either i merged in something in a bad way, or i didn't pull stuff out correctly, or the compile process itself was wrong somehow, or perhaps the jar in the 1.2.1 archive has not been built with the exact 1.2.1 sources on github. Will go hunt for answes and be back once i know what i did wrong. Until further notice, you can assume i made an error somewhere.
my fork stumbles upon block 60414, while the burst.jar in the 1.2.1 distro has no issues with that block.
sorry for all the noise... just kinda confused, never had this kind of problem before.
|
|
|
|
xizmax
|
|
January 27, 2015, 07:14:57 PM |
|
Currently on 60524 here, no issues. Sorry for not being of much help :/
|
|
|
|
Blago
|
|
January 27, 2015, 07:22:31 PM |
|
stuck again, this time at 60413 which is my latest block , and it matches exactly the one at the block explorer that is current - however, i get no more blocks than that, and that's on all 3 wallets again. If i am alone having this problem, i'll revert to the pre-built 1.2.1 to see if that is better. all 3 wallets are showing errors like this, and it seems that these errors always show up when my chain stops being updated : 2015-01-27 20:04:14 INFO: tx with id 1488316772753571631 found 2015-01-27 20:04:14 INFO: get timestamp for tx with id 1488316772753571631 found nxt.at.AT_Exception: Calculated md5 and recieved md5 are not matching at nxt.at.AT_Controller.validateATs(AT_Controller.java:404) at nxt.BlockchainProcessorImpl.accept(BlockchainProcessorImpl.java:682) at nxt.BlockchainProcessorImpl.pushBlock(BlockchainProcessorImpl.java:647) at nxt.BlockchainProcessorImpl.access$400(BlockchainProcessorImpl.java:51) at nxt.BlockchainProcessorImpl$1.run(BlockchainProcessorImpl.java:171) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.runAndReset(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) 2015-01-27 20:04:58 INFO: tx with id 1488316772753571631 found 2015-01-27 20:04:58 INFO: get timestamp for tx with id 1488316772753571631 found nxt.at.AT_Exception: Calculated md5 and recieved md5 are not matching at nxt.at.AT_Controller.validateATs(AT_Controller.java:404) at nxt.BlockchainProcessorImpl.accept(BlockchainProcessorImpl.java:682) at nxt.BlockchainProcessorImpl.pushBlock(BlockchainProcessorImpl.java:647) at nxt.BlockchainProcessorImpl.access$400(BlockchainProcessorImpl.java:51) at nxt.BlockchainProcessorImpl$1.run(BlockchainProcessorImpl.java:171) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.runAndReset(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) 2015-01-27 20:05:21 INFO: tx with id 1488316772753571631 found 2015-01-27 20:05:21 INFO: get timestamp for tx with id 1488316772753571631 found nxt.at.AT_Exception: Calculated md5 and recieved md5 are not matching at nxt.at.AT_Controller.validateATs(AT_Controller.java:404) at nxt.BlockchainProcessorImpl.accept(BlockchainProcessorImpl.java:682) at nxt.BlockchainProcessorImpl.pushBlock(BlockchainProcessorImpl.java:647) at nxt.BlockchainProcessorImpl.access$400(BlockchainProcessorImpl.java:51) at nxt.BlockchainProcessorImpl$1.run(BlockchainProcessorImpl.java:171) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask.runAndReset(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) i will now try to revert to the precompiled burst.jar on one of the pc's and see if that fixes the problems. if it is, it's just me having broken my burst fork. i suspect not though, but who knows, perhaps i merged in 1.2.1 in a bad way, missing something important. Anyone else stuck at 60413?, and what wallet version are you using? sorry for all the noise... just kinda confused, never had this kind of problem before. i have same messages, but daemon works fine nxt.wellKnownPeers=198.199.103.145; 178.62.39.204; burst.cryptoport.io; 192.155.252.202; 37.58.107.74; 119.81.165.138; 119.81.44.170; 119.81.44.171
|
Relax, I’m russian!... BURST-B2LU-SGCZ-NYVS-HZEPK
|
|
|
crazyearner
Legendary
Offline
Activity: 1820
Merit: 1001
|
|
January 27, 2015, 09:10:31 PM |
|
Beta pool at pool.burstcoining.com:8124 is back up. Looks like the wallet was upset due to that v1.2.0 fork so I cleaned out unconfirmed transactions and rescanned the blockchain.
Nice to see your back up and running you should become active in Burst irc chat so that people can keep in contact with you if something happens and can update memebers.
|
|
|
|
vbcs
Full Member
Offline
Activity: 137
Merit: 100
AT - Automated Transactions - CIYAM Developer
|
|
January 27, 2015, 10:38:00 PM |
|
(edit)
running the 1.2.1 precompiled jar gives me other results than running my compiled version of 1.2.1, using my fork at github, which *should*'ve been updated with the 1.2.1 on the burst github.
I will compare sources and trace back and see what's the cause, either i merged in something in a bad way, or i didn't pull stuff out correctly, or the compile process itself was wrong somehow, or perhaps the jar in the 1.2.1 archive has not been built with the exact 1.2.1 sources on github. Will go hunt for answes and be back once i know what i did wrong. Until further notice, you can assume i made an error somewhere.
my fork stumbles upon block 60414, while the burst.jar in the 1.2.1 distro has no issues with that block.
sorry for all the noise... just kinda confused, never had this kind of problem before.
Have you tried compiling the source code of the original 1.2.1 release burstdev uploaded here and compare the resulted jar with the one included in the release??
|
1ELCU3hahFLMPPqsoHS2Mg2Rqjya6VXjAW
|
|
|
pinballdude
|
|
January 27, 2015, 10:55:18 PM |
|
(edit)
running the 1.2.1 precompiled jar gives me other results than running my compiled version of 1.2.1, using my fork at github, which *should*'ve been updated with the 1.2.1 on the burst github.
I will compare sources and trace back and see what's the cause, either i merged in something in a bad way, or i didn't pull stuff out correctly, or the compile process itself was wrong somehow, or perhaps the jar in the 1.2.1 archive has not been built with the exact 1.2.1 sources on github. Will go hunt for answes and be back once i know what i did wrong. Until further notice, you can assume i made an error somewhere.
my fork stumbles upon block 60414, while the burst.jar in the 1.2.1 distro has no issues with that block.
sorry for all the noise... just kinda confused, never had this kind of problem before.
Have you tried compiling the source code of the original 1.2.1 release burstdev uploaded here and compare the resulted jar with the one included in the release?? The jar burstcoin put up is as far as i can tell excatly the same jar that i can produce with the sources put up to github. burstcoin have done nothing wrong whatsoever. My problem was in my windows compile batch file, i seem to have forgotten to add paths to all source, so for a few files, i was linking older AT stuff with newer AT stuff, and the mix didn't quite work well in all situations as one would expect. the windows javac does not understand /nxt/*/*.java - so i had written all the subdirs under /nxt one by one, but had missed out on the new AT directory so those classes was linked up from what i suppose was slightly older versions in my classes directory. I am building and testing now, and it seems like i am down to all classes in the jar file being byte for byte the same, except the ones where i have actually made changes, and the changes match up. And, of course, my wallets work once again.
|
|
|
|
Hellsgremlin
|
|
January 27, 2015, 11:19:54 PM Last edit: January 27, 2015, 11:50:50 PM by Hellsgremlin |
|
Is anyone else bothered by the fact that this entire community does almost all of its communication VIA this 1 Thread instead of in a Full forum.
A: Information is Hard to find B: 15 different conversations Burying Newcomer questions C: Important information is burryed
Can we start using a forum instead of 1 thread? Im registered at Bursttalk forums, Its sad how long questions sit unanswered in the support threads & how little activity is seen there but instead i have to look through 900+ pages of thread to find information I previously read and now need!
Is there a good reason we refuse to be like every other crypto coin and develop our own community in our own forum?
|
|
|
|
xizmax
|
|
January 27, 2015, 11:24:34 PM |
|
Is anyone else bothered by the fact that this entire community does almost all of its communication VIA this 1 Thread instead of in a Full forum.
A: Information is Hard to find B: 15 different conversations Burying Newcomer questions D: Important information is burryed
Can we start using a forum instead of 1 thread? Im registered at Bursttalk forums, Its sad how long questions sit unanswered in the support threads & how little activity is seen there but instead i have to look through 900+ pages of thread to find information I previously read and now need!
Is there a good reason we refuse to be like every other crypto coin and develop our own community in our own forum?
Your points are valid. You are welcome to join us over at https://burstforum.com/index.php and make it a better place! I admit I am guilty of not being active over there as well. P.S. I hope C wasn't something bad
|
|
|
|
mmmaybe
|
|
January 28, 2015, 12:18:15 AM Last edit: January 28, 2015, 12:32:55 AM by mmmaybe |
|
Hey, Today I am going to deploy the first AT use case: The Lottery AT. I created a new account ( BURST-2Z98-XJU6-A2UA-FDKZP ), which will be used to send funds to the Lottery without participating in the draw. That way we can "kickstart" the lottery with an amount for the first draw to create more interest and winnings for the winner of the first decentralized lottery using AT. So any funds send to that address will be send back to Lottery AT account. I am thinking the ticket size to cost 2000 burst. The lottery fees for processing the txs are about 15burst. So the final amount to participate to the lottery will be 2015 burst. If you think the ticket amount is too big or too small please say so. The lottery will pay the winner the total worth of tickets purchased approx. every 1 week plus all extra that were sent to the special address to help seed the Lottery payout When participating to the lottery, the AT will create a random ticket for you after 15 blocks. The ticket is sent back to the participant through a normal tx with the ticket ( in hex format ) included as a message. Due to a limitation of the AT txs only one ticket can be send back as a message to each participant per block, although if you send more in one block the AT always draws a ticket for each different tx, so that limitation does not mean you will not get more tickets per block per tx if you make multiple purchases. I created a .html file which needs to be copied under the directory /html/ui/ inside burst folder. After you copy the html file you can use the browser to access it ( http://localhost:8125/atlotteries.html ). The html displays the lottery state (current winner account, total current winnings e.t.c) and provides also a button for quick ticket purchase. Here is a screenshot of the resulted .html : https://i.imgur.com/Pz8H2SQ.png If you are using http://localhost:8125 to access your burst wallet then download this version: https://mega.co.nz/#!KcZiTBBS!V5SobUhbDGu7Dcw2un1jGszIM3Scl0e3feK9wduKPlU else if you are using http://127.0.0.1:8125 to access burst wallet this version: https://mega.co.nz/#!GBhwCTAD!NucXtJh7o9h-4R_gJafnY7xVlgbKJ5IEZ0tA7AYadyM Also here you can see the lottery's code that will be deployed here : http://pastebin.com/xiDdMzEGRegards - vbcs Don't forget to participate in LuckyAT, BURST's decentralized lottery! The price is now 54,465 BURST vbcs explains above how you do to buy a ticket (or two ) As you all know, LuckyAT is an Automated Transaction (AT), the first of it's kind. Our developers managed to beat coins as Ethereum and Counterparty to implement this "Smart Contract". That's why we are getting all the media attention recently, like today's https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/. But already BURST supports a number of various ATs, one being crowdfunding. So LuckyAT is going to continue to run and find a winner about once a week, automatically, but at the same time we need to get the other ATs started. The PR Team has discussed with the developers (vbcs and CIYAM) about this, and we decided to go for - crowdfunding. Crowdfunding has become really popular recently, it's basically asking when one asks a group for financial support for something, but the thing is that this has never been done on a blockchain, decentralized and without any "authority". BURST is first again - it's possible to do by code! In the future everyone can download the the BURST client and set up a crowdfunding case. You set up a BURST account, set the rules for it and let people decide if they want to support it by sending coins to the account or not. That's really awesome, I think, that people will be able to do that, ask for money for writing a book, or for shopping, or traveling to Mars, or to aid the victims of some earthquake in a foreign country. Decentralized But that's the future, and first we have to launch it and do the first one, so the question is: What should our first crowdfunding case be for? What do you think...? Of course it's possible to say Ebola, coz it's horrible and people are dying form it, but on the other hand we need something smaller and manageable the first time - and hopefully something that benefits BURST and is meaningful for the community. Like when we started with a simple, but at the same time very real, lottery. Things we talked about as the first crowdfunding case was support for a promo video, or creating a "Dev fund" (since the developers didn't do any pre-mine or IPO, they don't have $15 mill like Ethereum does), or money to a hire a programmer to code a combined plotter and miner with an easy-to-understand GUI to finally end all mining questions... Since it's the community who's going to have to support the case in the end, it's important to hear what everyone thinks we should do as the first case - so it becomes successful. So enough of me writing to long again - perhaps we'll make a separate thread for this later - but let's begin with to hear what you would support and take it from there. ***edit: also posted at burstforum: https://burstforum.com/index.php?threads/first-luckyat-and-now-crowdfunding-implementing-the-next-at.602/ - use whatever place you want
|
|
|
|
Elmit
|
|
January 28, 2015, 06:05:06 AM |
|
How to become a node?
I followed the NXT instructions, but admin.html seems to be broken!!!
|
|
|
|
bensam123
|
|
January 28, 2015, 06:08:04 AM |
|
Benchmark Comparison - Direct vs Buffer - https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-11#post-3014Why Direct is Slower than Buffer - https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-11#post-3034Plot size will remain the same after optimization, if it is not then something went wrong along the way. Did you run out of disc space? Information about Stagger setting when Direct Plotting - https://burstforum.com/index.php?threads/gpu-plot-generator.45/page-13#post-3348During a direct right method, the stagger setting is used to setup a ram buffer for pre-ordering of the nonces. In your example, a stagger size of 1024 during a direct right method will just use 1024KB of RAM for the nonce buffer re-ordering. In this thread and the thread on the forums a few people have complained about the reliability of the direct right method, also the performance hit for direct right compared with just plotting and optimizing does not appear to be worth it. Maybe someone else can add some information to this topic. Just because no one has posted in the BurstForum thread about the GPU plotter doesn't mean it's dead. This seems like the perfect type of question to ask in a Burst forum within the GPU plotter post. I'm guessing the regulars have had their questions answered you would be a perfect candidate to awaken the thread and maybe Cryo will answer your questions directly Apparently I looked over a couple key posts. I'm testing out direct write right now, I'll let you guys know how it goes since the optimize failed. Plotting more then one drive at the same time while optimizing is much easier and less time consuming then bunny hopping files across two drives. It appears as though the wallet is now using like 1GB~ of memory. Is anyone else getting this? Is this normal?
|
|
|
|
bobafett
|
|
January 28, 2015, 06:14:00 AM |
|
i just bought a lottery ticket. hope that i be the lucky one. äh i´m a little confused. do i enter in the amount field for the lottery 1 for 1 ticket oder 2015 for 1 ticket? I just tried with 1 and i send 1 burst. i think thats wrong?! Can some explain and can someone clear this point in the manuel for the lottery?
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
|
January 28, 2015, 06:31:08 AM |
|
Can some explain and can someone clear this point in the manuel for the lottery?
Have let vbcs know about your difficulty to see if he can make the instructions clearer but if you click Buy Now then you just need to click Okay after that (no need to type in any numbers at all).
|
|
|
|
|