Writing Twice

[danny91]

Hey, not sure if this a bug or something i'm doing wrong.

When plotting (In direct mode) i have noticed it will freeze at 0.??% and it will stay at that percentage until it has filled all the space on the drives you have plotting. Once it has filled them it then starts again from the beginning and actually starts plotting. This i'm guessing roughly doubles the time. Only on the second pass does the percent start going up. The free space on the drives does not decrease anymore at this point.

Example mine was stuck on 0.7% for roughly 12 hours on 2 3TB and 1 2TB drives. After 12 hours it had wrote 3 plot files (one to each the correct size) then it started again and the percent started increasing.

During the "First" pass the GPU remains at 0% load and on the second round it is actually used.

During the second round no Reads are done from the drives (from what i can tell from watching it) Meaning its not trying to optimise what it wrote the first time.

Any input / help would be appreciated! Thanks

Intel i7 4790K 16GB Ram GTX 970

[StaticRip]

Did you happen to find a solution?

I have the same problem with my 5TB drive it filled up to 4.4TB then the nonces dropped to 500/min and the % started going up too.

Intel i7 3700 24GB RAM Rx 480 8GB

Restart for now?

[bhamon]

I experienced the same problem when I tested it during development. Back then, the plotting performances were so bad with this writing strategies that I nearly removed the whole feature.

Based on what you say, it may be a multiple allocation with fragmentation issue. A solution would be to pre-allocate the output file to the final size. I'll try that as soon as possible.

[arihancc]

@StaticRip No, haven't found a solution yet other than 1) wait and let it do its thing 2) use xplotter instead.

@bhamon Would it be possible to do it like xplotter does when run as admin? It makes the file the correct size instantly. Also if you would like me to test anything that might fix it just let me know!

[bhamon]

@arihancc Yes it would help me a lot, I can provide you a version with a quick fix for tests purposes. Which OS are you running? Which arch (x86, x64)?

[arihancc]

@bhamon Hey Windows 10 x64 :)

[bhamon]

@arihancc Can you test that pre-release?

[arihancc]

Hi just been trying it out. It seems to have the same issue.

[bhamon]

@arihancc Sorry for that, there was a problem in the pre-allocation for files larger than 2GB. Can you try this one ?

[arihancc]

@bhamon Hey, Same issue. It allocated the file looking at the file size but still froze at 0.58%

[bhamon]

@arihancc At this stage, the fact it "frozes" is just because it is writing to disk the first N plots (N varies depending on the staggerSize you used). What is the content of your device.txt file and the command line you're using?

[arihancc]

My "Run script"

gpuPlotGenerator generate direct D:\\Plots\3662907886258315336_31269440_1228800_8192
pause

Devices.txt 1 0 1024 128 512

Using these it froze for roughly 32 minutes before the percentage started going up from 0.82%.

[bhamon]

@arihancc Can you try this version? You have to launch it with administrative rights to have a large writting speed enhancement (from an eternity to 1min per plots on my rather old computer). If you see "Missing administrative rights, fallback to slow writing." in the console output, the proper code section hasn't been loaded.

[arihancc]

@bhamon Hey that seems to be working! Only thing is for windows (right click run as admin) the run script requires to look like this or you get that it cant find gpugenerator.

@setlocal
@cd /d %~dp0
gpuPlotGenerator generate direct D:\\Plots\3662907886258315336_31269440_1228800_8192
@pause

(just encase you wanted to add it to the docs, then you can simply right click run as admin the bat file.)

Thanks so much for trying to figure out the issue! :)

[bhamon]

@arihancc Glad to hear it.

Next step is to find a workaround for linux and OSX. I'll need some more beta testers.

[de-luxe]

@bhamon Quite sure you will find a lot of testers if you ask for it here: https://forums.burst-team.us/topic/58 Thats the thread i created for your plotter on the burst forums.

[disrvptor]

Using this version just crashed on Windows 10 x64.

Application Error (from Event Viewer)

Faulting application name: gpuPlotGenerator.exe, version: 0.0.0.0, time stamp: 0x593e60a5
Faulting module name: ntdll.dll, version: 10.0.15063.0, time stamp: 0xb79b6ddb
Exception code: 0xc0000006
Fault offset: 0x0000000000019325
Faulting process id: 0x2a08
Faulting application start time: 0x01d2e38a6ee3d2c1
Faulting application path: U:\gpuPlotGenerator-bin-win-x64-4.0.5c\gpuPlotGenerator.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: 08ac820f-9d73-49f6-b83f-27087d57db71
Faulting package full name: 
Faulting package-relative application ID: 

Followed by the following Application Error

Windows cannot access the file U:\gpuPlotGenerator-bin-win-x64-4.0.5c\libstdc++-6.dll for one of the following reasons: there is a problem with the network connection, the disk that the file is stored on, or the storage drivers installed on this computer; or the disk is missing. Windows closed the program gpuPlotGenerator.exe because of this error.

Program: gpuPlotGenerator.exe
File: U:\gpuPlotGenerator-bin-win-x64-4.0.5c\libstdc++-6.dll

The error value is listed in the Additional Data section.
User Action
1. Open the file again. This situation might be a temporary problem that corrects itself when the program runs again.
2. If the file still cannot be accessed and
    - It is on the network, your network administrator should verify that there is not a problem with the network and that the server can be contacted.
    - It is on a removable disk, for example, a floppy disk or CD-ROM, verify that the disk is fully inserted into the computer.
3. Check and repair the file system by running CHKDSK. To run CHKDSK, click Start, click Run, type CMD, and then click OK. At the command prompt, type CHKDSK /F, and then press ENTER.
4. If the problem persists, restore the file from a backup copy.
5. Determine whether other files on the same disk can be opened. If not, the disk might be damaged. If it is a hard disk, contact your administrator or computer hardware vendor for further assistance.

Additional Data
Error value: C000009C
Disk type: 3

devices.txt: 1 0 1152 192 6144

Console

U:\gpuPlotGenerator-bin-win-x64-4.0.5c>gpuPlotGenerator.exe generate buffer "U:\plots\16298267262655615423_16384000_4096000_8192"
--------------------------
GPU plot generator v4.0.5c
--------------------------
Author:   Cryo
Bitcoin:  138gMBhCrNkbaiTCmUhP9HLU9xwn5QKZgD
Burst:    BURST-YA29-QCEW-QXC3-BKXDL
----
Loading platforms...
Loading devices...
Loading devices configurations...
Initializing generation devices...
    [0] Device: GeForce GTX 1050 Ti (OpenCL 1.2 CUDA)
    [0] Device memory: 288MB
    [0] CPU memory: 288MB
Initializing generation contexts...
    [0] Path: U:/plots/16298267262655615423_16384000_4096000_8192
    [0] Nonces: 16384000 to 20479999 (1000GB 0MB)
    [0] CPU memory: 2GB 0MB
----
Devices number: 1
Plots files number: 1
Total nonces number: 4096000
CPU memory: 2GB 288MB
----
Generating nonces...
0.00% (0/4096000 remaining nonces), 0.00 nonces/minutes, ETA: 7y 42w 2d 10h 40m 0s...Computing plots
Writting nonces
55.38% (2268288/4096000 remaining nonces), 19644.53 nonces/minutes, ETA: 1h 33m 2s...

Update 1: It may have been a Windows issue with the RAID0 setup on that drive. Still verifying. Update 2: It happened again. I'll try running it in a non-admin console. Update 3: It was my hardware. The Intel RAID controller I have sucks.

[bhamon]

@disrvptor Glad you've found the source of your problem.

@arihancc Yes, it comes from the fact that running it as Administrator chnages your cwd.

New version (4.1.0) is out. I'll provide Linux/MacOS binaries soon. Let me know if you find issues.