[ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000

[Elmit]

Hi Guys,

I'm trying to get my rig running as efficiently as possible.

I've got 22TB running via external usb 2/3 hard drives but I'm
getting poor mining results yielding less then 1-2k Burst per day.

The biggest problem has been finding a miner than runs well with
4Gb ram (tried upto 14gb) with vista 64 / windows 7. I'm using Runaurufu
miner but doesn't seem to work well with burst.ninja. Blago runs good for an hour
but will often crash I think due to ram or OS.

My total drive scan time is 220+ seconds and I think this is the problem?
I'm often the last to submit deadlines and missing out on the faster blocks.

I've been re-plotting my drives these past few days as I found two of my first plotted
drives had lots of small plots and that was slowing down the whole setup.

Any other tips? Do's or Don'ts or anything that might help.
I was considering de-casing the external drives and setting them up as sata.

Change the USB 2.0 HDD to USB 3.0 or SATA conection, and try the latest Blago miner version, it fix the memory leak in W7 i think. Some people reported bad mining results with W7 too, better switch to W8.1 or a GNU/Linux distro like Debian or Ubuntu.

Edit: You can try optimizing the plots too!
Edit2: The difficulty is very HIGH now, i only mine like 500 Burst yesterday

RAM is important, try to get more and use a staggering size that fits to the amount of RAM you use.

[riskyfire]

Hi Guys,

I'm trying to get my rig running as efficiently as possible.

I've got 22TB running via external usb 2/3 hard drives but I'm
getting poor mining results yielding less then 1-2k Burst per day.

The biggest problem has been finding a miner than runs well with
4Gb ram (tried upto 14gb) with vista 64 / windows 7. I'm using Runaurufu
miner but doesn't seem to work well with burst.ninja. Blago runs good for an hour
but will often crash I think due to ram or OS.

My total drive scan time is 220+ seconds and I think this is the problem?
I'm often the last to submit deadlines and missing out on the faster blocks.

I've been re-plotting my drives these past few days as I found two of my first plotted
drives had lots of small plots and that was slowing down the whole setup.

Any other tips? Do's or Don'ts or anything that might help.
I was considering de-casing the external drives and setting them up as sata.

Change the USB 2.0 HDD to USB 3.0 or SATA conection, and try the latest Blago miner version, it fix the memory leak in W7 i think. Some people reported bad mining results with W7 too, better switch to W8.1 or a GNU/Linux distro like Debian or Ubuntu.

Edit: You can try optimizing the plots too!
Edit2: The difficulty is very HIGH now, i only mine like 500 Burst yesterday

RAM is important, try to get more and use a staggering size that fits to the amount of RAM you use.

Thank you. I'm trying all the suggestions. My stagger on my recently plotted drives are 16K / 20K, I plotted them on
another system with more ram but even when using the ram out of this pc 12Gb, I'm still having problems.

I thought the stagger only effected the plot file write rate, not the read rate?

Does anyone have a good working setup vista 64 / win 7?

[Merick]

Just an FYI,
The stagger as related to RAM is a Windows issue.  Linux does not have these problems.  But  ibeleive Blago's latest update handles the Windows file caching issues, which is related to stagger size.

Increasing stagger size puts your drive closer or into its sequential read performance band.  The lower the stagger the more you will be operating within the random read rate of the drive.

Under Linux and DCCT's base code, stagger has no effect on system RAM usage.  I have ~20 Plot files, ranging in size from 500GB to 1TB all optimized (large stagger)and they happily mine away for 7 days straight without used system RAM going over 1GB.  I'm sure it will run longer than 7 days, but I like to fiddle to much, and I'm sure the miner uses less than 1GB but that's the number I remember seeing this after-noon.  My mining box also runs a PLEX media server so RAM is being used by that also.

TLDR:

Large Stagger will affect Windows 7 mining performance, Blago's newest miner addresses this issue.  Windows 8/8.1 also reduces this issue.

Stagger size under Linux is a variable that increases or decreases read rate, no effect on system RAM usage (DCCT / Urray Code).

Good-Luck

[riskyfire]

Just an FYI,
The stagger as related to RAM is a Windows issue.  Linux does not have these problems.  But  ibeleive Blago's latest update handles the Windows file caching issues, which is related to stagger size.

Increasing stagger size puts your drive closer or into its sequential read performance band.  The lower the stagger the more you will be operating within the random read rate of the drive.

Under Linux and DCCT's base code, stagger has no effect on system RAM usage.  I have ~20 Plot files, ranging in size from 500GB to 1TB all optimized (large stagger)and they happily mine away for 7 days straight without used system RAM going over 1GB.  I'm sure it will run longer than 7 days, but I like to fiddle to much, and I'm sure the miner uses less than 1GB but that's the number I remember seeing this after-noon.  My mining box also runs a PLEX media server so RAM is being used by that also.

TLDR:

Large Stagger will affect Windows 7 mining performance, Blago's newest miner addresses this issue.  Windows 8/8.1 also reduces this issue.

Stagger size under Linux is a variable that increases or decreases read rate, no effect on system RAM usage (DCCT / Urray Code).

Good-Luck

Hi,

I've just installed Ubuntu but I'm not familiar with linux os and the file system.
I think second from bottom line is correct usage ? not sure what I'm missing.

[haitch]

Just an FYI,
The stagger as related to RAM is a Windows issue.  Linux does not have these problems.  But  ibeleive Blago's latest update handles the Windows file caching issues, which is related to stagger size.

Increasing stagger size puts your drive closer or into its sequential read performance band.  The lower the stagger the more you will be operating within the random read rate of the drive.

Under Linux and DCCT's base code, stagger has no effect on system RAM usage.  I have ~20 Plot files, ranging in size from 500GB to 1TB all optimized (large stagger)and they happily mine away for 7 days straight without used system RAM going over 1GB.  I'm sure it will run longer than 7 days, but I like to fiddle to much, and I'm sure the miner uses less than 1GB but that's the number I remember seeing this after-noon.  My mining box also runs a PLEX media server so RAM is being used by that also.

TLDR:

Large Stagger will affect Windows 7 mining performance, Blago's newest miner addresses this issue.  Windows 8/8.1 also reduces this issue.

Stagger size under Linux is a variable that increases or decreases read rate, no effect on system RAM usage (DCCT / Urray Code).

Good-Luck

Hi,

I've just installed Ubuntu but I'm not familiar with linux os and the file system.
I think second from bottom line is correct usage ? not sure what I'm missing.

Do "chmod +x mine_dev_v2.sh" (only need to do this once), then "./mine_dev_v2.sh  <the rest of the command line>"

H.

[riskyfire]

Just an FYI,
The stagger as related to RAM is a Windows issue.  Linux does not have these problems.  But  ibeleive Blago's latest update handles the Windows file caching issues, which is related to stagger size.

Increasing stagger size puts your drive closer or into its sequential read performance band.  The lower the stagger the more you will be operating within the random read rate of the drive.

Under Linux and DCCT's base code, stagger has no effect on system RAM usage.  I have ~20 Plot files, ranging in size from 500GB to 1TB all optimized (large stagger)and they happily mine away for 7 days straight without used system RAM going over 1GB.  I'm sure it will run longer than 7 days, but I like to fiddle to much, and I'm sure the miner uses less than 1GB but that's the number I remember seeing this after-noon.  My mining box also runs a PLEX media server so RAM is being used by that also.

TLDR:

Large Stagger will affect Windows 7 mining performance, Blago's newest miner addresses this issue.  Windows 8/8.1 also reduces this issue.

Stagger size under Linux is a variable that increases or decreases read rate, no effect on system RAM usage (DCCT / Urray Code).

Good-Luck

Hi,

I've just installed Ubuntu but I'm not familiar with linux os and the file system.
I think second from bottom line is correct usage ? not sure what I'm missing.

Do "chmod +x mine_dev_v2.sh" (only need to do this once), then "./mine_dev_v2.sh  <the rest of the command line>"

H.

Thanks, I got through the permissions problem.

But I think I need the numeric ip of burst.ninja or the format to enter it as an url in mine_dev_v2.sh ?


Edit: I get the same error with V1 miner too?
the original default ip works but I have no idea which pool this is for.

[Crypto_Lobbyist]

What's new, guys?

From technical analyse will we break 500 satoshis soon? Any predictions?

[haitch]

Just an FYI,
The stagger as related to RAM is a Windows issue.  Linux does not have these problems.  But  ibeleive Blago's latest update handles the Windows file caching issues, which is related to stagger size.

Increasing stagger size puts your drive closer or into its sequential read performance band.  The lower the stagger the more you will be operating within the random read rate of the drive.

Under Linux and DCCT's base code, stagger has no effect on system RAM usage.  I have ~20 Plot files, ranging in size from 500GB to 1TB all optimized (large stagger)and they happily mine away for 7 days straight without used system RAM going over 1GB.  I'm sure it will run longer than 7 days, but I like to fiddle to much, and I'm sure the miner uses less than 1GB but that's the number I remember seeing this after-noon.  My mining box also runs a PLEX media server so RAM is being used by that also.

TLDR:

Large Stagger will affect Windows 7 mining performance, Blago's newest miner addresses this issue.  Windows 8/8.1 also reduces this issue.

Stagger size under Linux is a variable that increases or decreases read rate, no effect on system RAM usage (DCCT / Urray Code).

Good-Luck

Hi,

I've just installed Ubuntu but I'm not familiar with linux os and the file system.
I think second from bottom line is correct usage ? not sure what I'm missing.

Do "chmod +x mine_dev_v2.sh" (only need to do this once), then "./mine_dev_v2.sh  <the rest of the command line>"

H.

Thanks, I got through the permissions problem.

But I think I need the numeric ip of burst.ninja or the format to enter it as an url in mine_dev_v2.sh ?

I've not used the linux miner, so won't be a lot of help but can you ping burst.ninja ? You can also try via IP - burst.ninfa is at 192.198.95.54

H.

[riskyfire]

I've got the same issue with numeric ip 192.198.95.54:8124

Should I be using dev 1 miner?

[haitch]

I've got the same issue with numeric ip 192.198.95.54:8124

Should I be using dev 1 miner?

No idea - I use Blago's miner on windows.

[Elmit]

riskyfire:

I would recommend that you use screen on Linux, ... that keeps the window running, while you may have lost the connection. Maybe you want to logout of your monitor, then screen will keep it running!

I use therefore following screens (if not with screen, than use tabs):

1. screen/tab  BurstWallet
cd ~/burst/burst_1.2.2
nohup java -cp burst.jar:lib/*:conf nxt.Nxt &

2. screen/tab  plotter
Usage:
/media/ronald/Seagate-1-4T/burstminer/dcct_miner/plot -k KEY [-d DIRECTORY] [-s STARTNONCE] [-n NONCES] [-m STAGGERSIZE] [-t THREADS]

Example calculation:
4 TB, available: 3906798052
3906798052 / 256 nounces = 15260929.890625
Only possible number must be devideable by 40,000 (=my staggering size): 381.5
=> 40,000 x 381 = 15240000

BurstMiner:
cd ~/media/ronald/Seagate-1-4T/
nohup ~/media/ronald/Seagate-1-4T/burstminer/dcct_miner/plot -k 17762102779501773438 -s 0 -n 15240000 -m 40000 -t 4

Link that file:
ln -s /media/ronald/Seagate-1-4T/plots/*  /home/ronald/burst/plots/


3. screen/tab mining
rm ~/mine-log
mv ~/mine-log-date ~/mine-log-date-2015-01-19==14-00   (my last log file)
cd ~/burst/burst-miner-r4
./burstminer >> ~/mine-log

4. screen/tab logconverter  (because the original logfile has no timestamp !!!)
tail -f ~/mine-log | while read line; do echo `date` "$line" ; done >> ~/mine-log-date

5. screen/tab burstmenu
Here I created my own tasks, df, top, ....

the burst-miner-r4 needs a config file

cat mining.conf
 {
    "poolUrl" : "mininghere.com:8124",
    "submissionMaxDelay" : 15,
    "submissionMaxRetry" : 3,
    "socketTimeout" : 60,
   "maxBufferSizeMB" : 768,
    "plots" :
    [
       "/home/ronald/burst/plots"
   ]
 }


from each harddisk's plotfile I make   ln -s  to /home/ronald/burst/plots
that has the advantage, if I take out/add a new hard disk, I do not need to do anything.

(and you may consider to use my pool ;-)  )

[Amarok1987]

is anybody else having a lot of trouble downloading the blockchain? I have been downloading for over 3 hours and thats after downloading the most up to date db file.

[Merick]

I've got the same issue with numeric ip 192.198.95.54:8124

Should I be using dev 1 miner?

No idea - I use Blago's miner on windows.

With DCCT on  burst.ninja or any of Urays code pools

you can either edit the .sh file or put this into a command window that is open to the directory that contains the miner.

./mine_pool_all burst.ninja:8124 /path1/ /path /path3 ....
I'm lazy and just have this txt pasted into a txt document.  I browse to the miner folder on my Linux box, right click, open command line here... paste the text.. and start mining/.  I check the pool GUI a few times a day, but other than that I just ignore the box.  I'm hoping to leave it alone and get 30 days up-time, I'm at 7 right now

My exact string.  Each ending path contains my plot files.
DCCTs code has no way of adjusting minimum submitted deadline for Uray pools (submit all) without adding an IF statement and recompiling.  DCCT does have a best share option, but I do not think the pool communication is formatted for Uray and Cat style pools, anyways, I am getting off topic.

*You can also use Uray's r4 code, which offers a config file for adjusting pool locations and other variables.

Do something like this, and it will work.
Your screen shutting off has no affect on your mining ability.
./mine_pool_all burst.ninja:8124 /media/merick/4tbseaz9/1 /media/merick/red2/ /media/merick/red3 /media/merick/red4 /media/merick/2TBCUDA/1

*these are the commands that the .sh file is running

[Kartojal]

I think i need translate my Burst GNU/Linux documentation from spanish to English, you will have it in a few days

[ticote]

I founded a new crowdfunding project thinking in the future, just for our future fun.

It´s the Ferrari Sharing project; when BURST reached 1$ value, a Ferrari will be buy and shared for everyone who pledge for this crowdfunded project.

As soon as one of our genious developers launch the ATPoll, we will use it for decide the model and the colour of the Ferrari.

https://i.imgur.com/o7MV5v2.jpg

Hope to see you driving a Ferrari.

[bobafett]

some people have realy funny ideas  

[bensam1232]

Just a FYI, my account 'Bensam123' has been compromised. If you receive any sort of weird messages (outside the normal paranoia), they aren't from me. I'm currently working with a admin to get it restored.

[bobafett]

Now at 36% funded. I still need your help!



If you want how to install the crowdfund extension, loot at burstcoin.info Guides.
thx

Update and News:
Burstcoin.de is now conneted and online. 70% are now translated. I think i will got it until tomorrow.

270k to go in the CF. Please do some donations!!!! This is very much work and this will bring us and the price up. So please help to make this a success!

How to donate? please look into my footer.
You can also support me by sending direct to my Burst Account: BURST-AJ63-3W8L-FGBT-2ALZE

Thanks!!!!

[Sema89]

I have daily 1000+ instances (all are c3.8xlarge) Can I create plots 16tb for each instance and copy the AMI image and start him in other 999 instances? The problem is I have 6hrs to make that and all instances will turn off after 6 hrs of work. And tomorrow I need do it again.
Can I use generated plots in other instances? Or they must be unique?

[Kartojal]

I have daily 1000+ instances (all are c3.8xlarge) Can I create plots 16tb for each instance and copy the AMI image and start him in other 999 instances? The problem is I have 6hrs to make that and all instances will turn off after 6 hrs of work. And tomorrow I need do it again.
Can I use generated plots in other instances? Or they must be unique?

You can't use the same plot for mining, you will mine like one instance. But you can try to do some plotting and save it, and connect when the instances are up! The plots are uniqe because the "start nonce" !

First plot:
 start nonce 0
 total nonces  4398046511104 (16 TB i think)

Second plot:
start nonce 4398046511105 (one nonce more that before )
total nonces 4398046511104

Third plot:
start nonce 8796093022210
total nonces 4398046511104

[...]


You can't connect with all these instances at the same time and send a script?

Edit: wow, 1000 instances .... 16 tb each... 16.000 TB lol with that i can do wonders