Yup, plot generation all hinges on CPU power.

To a point stagger size will speed up plot generation--a stagger of 100 will be far faster than a stagger of 10. However, once you get over 1000 or so, the benefit from higher staggers mostly lies simply in the time it takes to parse each file.

Yeah, those files are fine. With 8GB of RAM, either not enough of it is free, you are on a 32-bit version of Java (or OS!) or your -Xmx value is too small. Either way, stagger isn't too important, it just makes parsing the files a tad faster.

What are the names of your plot files?

Sure

There is a faster plotter courtesy of dcct, however is uses linux-specific assembly for the shabal hash, so it hasn't yet been ported and compiled for/on Windows. Your best bet it simply to put the miner command in a loop, so when it crashes it just starts back up:

Ah well, 1000 with 2048 work, or do you need to go down to 1024 for steps?

Yeah, with rising difficulty chances are fairly slim for that to solo mine anything.

For pool mining, you're gonna need more than 250GB to get shares on a regular basis, 1TB or more would be preferred.

For solo mining, I'd recommend 8+ TB.

Here's the kicker for why POC mining is attractive:

With a GPU, say, a R9 290x, you are pulling at least 300W for the card to run. The card itself costs around $550, and on $0.15/kWh pricing, it would cost $394.20 to run at full load yearly. This means after a bit over a year, your costs are split 50/50 between hardware and electricity, assuming you didn't invest in additional cooling and cooling upkeep. If all mining went south, you could sell your card, but you take a loss on that electricity. However, if you were mining with a hard drive which costs $7/year to run for a $300 drive, then if everything goes south, you can recoup a large portion of your investment. Most hard drives have a minimum of 2 years of warranty.

Additionally, the amount of network security possible from POC given the same amount of capital invested into mining as with POW is much higher, as the majority of that money goes towards actual hardware, and miners have very little reason (very little maintenance cost) to keep their hard drive rigs running. In comparison, miners may shut off GPU rigs when they produce too much heat, or consume more electricity than they pay for.

Hard drive mining is more eco-friendly. Each dollar invested into mining requires far less power to run, and each thus each 'dollar of security' (because what protects cryptocurrency networks is the cost to perform a 51% attack) requires less power, and less upkeep. Graphics cards don't 'perform better'; it's comparing apples to oranges. The reason Bitcoin is so secure is because it has significant amounts of hardware behind it--and that hardware costs money. Keep in mind, there aren't really the equivalent of ASICs for storage. The best TB/dollar storage is tape storage, which would be impractical for BURST mining, considering all the seeking involved. Considering only hardware practical for mining, consumer hardware is king--enterprise hardware has higher $/TB costs. It doesn't matter how many kH, MH, GH, TH, PH... a network has, it matters how much money it costs to acquire hardware to provide that much hashing power. I could create a coin which had a hashing function so simple that a GPU could run 20GH/s, but that doesn't make it any more secure. Network security is a cat-and-mouse-game, and all that matters is the cost for a third-party to deploy hardware in enough quantity to provide more than 50% of the network's computational power. If my coin has 20GH/s on a R9 290x, then for each R9 290x they deploy, they get that hash rate too.

Do you have a 64-bit version of Java installed? If not, just reduce 4000m to 2000m and then reduce 8191 to 4096, or 2048.

Shouldn't take longer than an hour even on slow internet connections. What block are you on?

How much free memory do you have in your machine? 4000m will require nearly 4GB of free RAM to allocate properly. If you don't have sufficient memory for this, just change '8191' to '1024'.

Yup, that's why you get errors in reading the files, but they're harmless, just noting that the plot file isn't complete.

Yeah, change -Xms1000m to -Xms4000m to allocate more memory.

In the standard naming convention for plotfiles, you have:
address_startingNonce_noncesInFile_noncesPerRound
In the above, add the startingNonce to the noncesInFile (both from your most recent plot) to get the next startingNonce for your next plot.

So for example, if your most recent (aka highest startingNonce) file looked like this:
address_4095500_4095500_8191
Then your next plot should be
address_8191000_4095500_8191
Where 4095500 controls the size of that file (in this case, 1TB) and 8191 controls the amount of RAM used in generation (2GB with the linux plotter), and where 'address' is representative of your actual numerical address (which is generated by run_dump).

If you stop a plot before it finishes, there's not really a way to 'resume' (other than calculating the ending nonce, and then merging the files). However, it doesn't matter, you can just start generating the next plot as you would if the previous plot finished correctly. The only issue is overlapping plots, but gaps mean nothing, all that matters is the total number of nonces.

Nope, a 1k block deadline could only mine a block that has waited a bit over 16 minutes since the last one.

Core 18 was released, though it's very similar to Core 17. I've heard good things about the latest drivers for people on R9 290x cards, though I don't have an R9 270 to do any testing on, so I can't tell you for sure. Driver updates usually don't reduce performance, though there's been a few counterexamples.

How many peers are you connected to?