Topic: [ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000 - page 859. (Read 2171078 times)

The pool has issued shares for fractional ownership of it.
Dividends will begin once a portion of the shares have sold.
The asset number is 11375670541237055652

BurstMultipool.com was unexpectedly restarted by OVH and offline for a short time - it is back online now.  Please point your miners and help generate buy pressure.  Completely optimized, automated payouts.

I have also set up the startup scripts so in the future restarts by the VPS provider will result in the pool coming right back online

Yeah I'm aware of that, but it has been stuck at 108.75 million for about 24 hours...

Gotcha.
I'll take a look into testing this tomorrow. Once the GPU plot I have going currently finishes.
[/quote]

I didn't forget... Plot file just finished.

I ran your test with some smaller plot files:
My plots appear to be fine (on Linux) generated with the 14.4 catalyst driver, as compared to the same plot generated with the CPU

I'll test out v2.0.1 and see if there are any changes.

block rew reduced from 10k to 9500/block

Hey guys. Does anyone know why the block explorer still says we have only 108 million coins mined?

Shouldn't we be somewhere near 120mil now?

If we are on 14.4 then do we need to delete anything generated with the GPU plotter and start over?

I'm running JBOD in a single large plot with 4x 4TB Seagate hdd's, 16TB total. Started last night around 9:32 PM PST, now is nearly 3TB filled at the moment. That could be a possibility, one of the disk might close to being done on the array.

So, this is just a cosmetic update? I don't know if it's just me, but my system would use 3GB total in the first 6 hours. Then later on, it would use double at 6~6.5GB and degradation of speed, also causes my miner to crash too. Is it possible there is a memory leak in the plotter? I'm running AMD 13.9 driver with 2.9.1 APP SDK.

Thank you bipben

amazing work

Maybe the CLOCKS_PER_SEC value doesn't match the actual clock() values on your platform (function that I use to retrieve the time). I will use the time() function instead.

Here is the new version:

GPU plot generator v2.0.1

Warning: to the AMD owners, the 14.4 catalyst driver cause a major bug. The generated files are corrupted. I will investigate on this problem. In the meantime, I recommend you to switch back your driver to the 13.12 version.

Changelog:
- Nonces display corrected (XX/YY nonces).
- Using time() function rather than clock() in nonces/minute computation.
- Nonces/minutes repeated at the end of the generation process to keep a trace of it after execution.
- ETA and elapsed time added.

Windows x86 binaries: https://mega.co.nz/#!TVEVjQ5L!Uyd2HuPTZSP9eARwjiChjd1P6BMWHQtYT0SGGHLrnuI
Sources: https://mega.co.nz/#!2RUwHAyC!IOxfTZk9PsRdPS7Z3a76MAT4vT3ygvp--r_dVQ5GaD4

your HDD filling up ? It's about half as fast on the inner cylinders as on the outermost.
(I'm not a native speaker, so bear with me if that word doesn't even exist.)

What does lowering or raising the hashes do? Seem like the nonce/min degrade over time. I was doing 11.7k nonce/min for the first 6 hours, then now I'm doing 11k nonce/min.

(already answered on http://burstforum.com/index.php?threads/gpu-plot-generator.45/page-2 )

Please use the new forum for support .. it is much less cluttered and a lot easier to navigate. I like it - thank you very much for initiating http://burstforum.com  !!

--

hm… I have plotted with the 3 modes available;

(java) ./run_generate.sh 99999999999999999999 19660849152 49152 3072 4
(linux-binary) ./plot 99999999999999999999 19660849152 49152 3072 4
(gpu-plotter) ./gpuplot generate 0 2 plots/ 99999999999999999999 19660849152 49152 3072 128 8160
(gpu-plotter) ./gpuplot generate 0 2 plots/ 99999999999999999999 19660849152 49152 3072 128 3072 (to check wether its this parameter)

and the gpu-generated file is exactly the same size, but differs on all the spots I've checked, e.g.

for i in 1024 2048 4096 892179 ; do cmp -i $i javafile gpufile ; done

whereas the linuxfile and javafile are identical.

I'm using 3x R9-280x on CentOS 6.5;

2.6.32-431.29.2.el6.centos.plus.x86_64
amd-catalyst-14-4-rev2-linux-x86-x86-64-may6
AMD-APP-SDK-linux-v2.9-1.599.381-GA-x64

compiling had a steep learning curve but it in the end it was just the LD_FLAGS that needed fiddling.
gpu-plotter starts up and runs normally without any hitch.

So.. can I mine with these files ? Or will I be IP-blocked..

But a BIG thank you for the effort !!

If this is working properly, I will be able to shut down the FIVE i7 6cores that I am using now and will get the equivalent of ~12 such machines with the power draw of just 3 280x GPUs.. (3x 300W = 900 W versus (theoretical, I don't have so many "spare idles") 12x 230W = 2760W).
 


oh, and just in case somebody wants to build under CentOS or Redhat linux, this would be the makefile you need:

--

unexport LC_ALL
LC_COLLATE=C
LC_NUMERIC=C
export LC_COLLATE LC_NUMERIC
#
#
OPENCL_INCLUDE = /opt/AMDAPPSDK-2.9-1/include
OPENCL_LIB = /opt/AMDAPPSDK-2.9-1/lib/x86_64
#CC = /c/_data/cryo/_apps/mingw/bin/g++
CC = g++
CC_FLAGS = -ansi -pedantic -W -Wall -std=c++0x -O3 -I$(OPENCL_INCLUDE)
#LD = /c/_data/cryo/_apps/mingw/bin/g++
LD = g++
#LD_FLAGS = -fPIC -L$(OPENCL_LIB) -static-libgcc -static-libstdc++ -lOpenCL
LD_FLAGS = -fPIC -L$(OPENCL_LIB) -static-libgcc -lOpenCL
ECHO = echo
MKDIR = mkdir
CP = cp
RM = rm

SRC = $(wildcard *.cpp)
OBJ = $(SRC:.cpp=.o)
EXEC = gpuplot

all: $(EXEC)

dist: all
   @$(ECHO) Generating distribution
   @$(MKDIR) -p bin/kernel
   @$(CP) kernel/util.cl bin/kernel
   @$(CP) kernel/shabal.cl bin/kernel
   @$(CP) kernel/nonce.cl bin/kernel
   @$(CP) README bin/README

rebuild: distclean all

$(EXEC): $(OBJ)
   @$(ECHO) Linking [$@]
   @$(LD) -o $@ $^ $(LD_FLAGS)

%.o: %.cpp
   @$(ECHO) Compiling [$<]
   @$(CC) -o $@ -c $< $(CC_FLAGS)

clean:
   @$(ECHO) Cleaning project
   @$(RM) -f *.o

distclean: clean
   @$(ECHO) Dist cleaning project
   @$(RM) -f $(EXEC)
   @$(RM) -Rf bin/kernel
   @$(RM) -f bin/README


--

and you need to have a "bin" directory to receive the "kernel" dir, and you have to have the gpuplot binary along with this "kernel" folder to use it. The binary must be set-uid root;

mkdir bin
make dist
chown root gpuplot
chmod 4555 gpuplot
cp -r gpuplot kernel


HOORAY !

Anyone else getting "No deadline" using burst-pool?

All was going good, just a few minutes ago seeing "no deadline" as it reads through the plots.

On a linux machine and using dcct's miner.

Download your miner again Your file missing, i have this file in my folfer. And download x64 java, than use path to java like this:

Perfect, i will try!  

P.S

Mine always on http://burst-pool.cryptoport.io or another pool?


It does not work, it makes me error:

Error: Could not find or load main class pocminer_pool.POCMiner

@chris

sometimes it's a problem with your RAM and Java. Don't understand the details either. Try my code above and it will restart the mining process automatically.

You need to generate : example

first disc --> 0 8000
second disc ---> 8001 16000

And google SYMLINK or SOFTLINK

its uses to mine as one big capacity..

example for 1 TB

1 TB --> 1000GB--> (1000*1024*1024)/256 = your nonces