The new one stores a lot more in memory before it writes to disk. I'm guessing this helps cut down on the disk seeking a lot.
Oh thanks, I missed that because I had already set SSIZE by hand to max out the memory. |
|
|
|
Is it better to use different plot directories with the same miner? or is it faster if we open a new miner per every hard rive?
I get better results with separate miners, but you have to use a C-based miner because multiple java-based miners can hose the memory. |
|
|
|
The plot optimizer utility
The new version is a LOT faster! What makes this faster? The read and write loops look exactly the same, except for getting rid of pread, which I assume is for compatibility rather than speed. |
|
|
|
I'm finding a lot of blocks with this version wow!  How much space do you have committed to plots? What frequency are you finding them at? |
|
|
|
Thanks, now I remember that rewardassignment.html thing. I had to change it when I went to pool mining. Now for the real question - how do I get into that wallet to get those 70,000 coins back into my other wallet?
If you could do that without knowing the password, burstcoin would be broken. |
|
|
|
i found block #13667 solo. Deadline was 454. Saw it in my wallet. Recieved new block for work #13668. After few hours that block (and coins) disapeared from wallet... Orphaned or stale blocks |
|
|
|
|
He may mean that the configuration is not trustworthy, which is likely a valid criticism.
|
|
|
|
If there was a short block, and you submitted nonces after the block changed, but before your miner refreshed the network state, it can submit something that would have been a fine deadline for the previous block, but garbage for the next one. Ah, got it. Thanks. |
|
|
|
|
Three times out of 487 blocks, my delays have been extremely high: 2895272710288, 2430140351990, 3755717744454. This is with 22TB of plots. Any idea what's going on there?
|
|
|
|
Economic clustering is part of some anti-51% attack code in nxt that isn't fully implemented yet, and currently only logs stuff.
Thanks. |
|
|
|
Is this part of the code basically saying that everyone gives up after 40 minutes? What decides the block at that point, assuming that ever happens? diff -c -r burstcoin/src/java/nxt/Constants.java nxt/src/java/nxt/Constants.java
*** burstcoin/src/java/nxt/Constants.java 2014-09-12 11:07:45.511618758 -0400
--- nxt/src/java/nxt/Constants.java 2014-09-15 16:22:51.854149186 -0400
***************
*** 90,96 ****
public static final String ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyz";
! public static final int EC_RULE_TERMINATOR = 2400; /* cfb: This constant defines a straight edge when "longest chain"
rule is outweighed by "economic majority" rule; the terminator
is set as number of seconds before the current time. */
--- 84,90 ----
public static final String ALPHABET = "0123456789abcdefghijklmnopqrstuvwxyz";
! public static final int EC_RULE_TERMINATOR = 600; /* cfb: This constant defines a straight edge when "longest chain"
rule is outweighed by "economic majority" rule; the terminator
is set as number of seconds before the current time. */
|
|
|
|
38s was the winning deadline :-) Compare the block times in your wallet
38s was block 13743. 126s is block 13742. Oh of cause. Must have mixed them up. Thanks, guys. This led me to find an error in my log parser. My delay was actually 207s. |
|
|
|
Looks like pool 1 has been stuck for the past couple of days. |
|
|
|
No, it's not worked from the begining  Have you created passphrase.txt and generated address.txt, as outlined in Readme.txt? |
|
|
|
So , which do we aprrove optimizing the stagger size? I've missed that info - why bigger stagger size is better?
The stagger size is the number of hashes from a given nonce that are recorded contiguously on the disk. A single contiguous read is faster and easier on the disk mechanism than a lot of short reads interrupted by disk seeks. |
|
|
|
Burst isn't the only coin on a downtrend, BTC and others are too
It's worth remembering some of the EPIC crashes BTC/USD has gone through, too.  |
|
|
|
This does not work for incomplete plotfiles.
I have this in my modified version. I'm not certain it's correct, because I'm testing on a humungous plot, but I think it should work: // Get the number of completed staggers in the file (drops the
// final stagger if incomplete.)
struct stat sh
fstat(fh, &sh);
unsigned long long int completed_plots = (sh.st_size / PLOTSIZE);
nonces = completed_plots - (completed_plots % stagger);
|
|
|
|
thanks, merge is indeed a misleading name, i thought at first that it merge two plots as well
You could concatenate completed plots as long as they combine to a consecutive set of nonces and you name the resulting file accordingly. |
|
|
|
|
Show Posts
