@rds said in Which will produce more revenue??:

If you could rent, for $1, any one of these miners, which would you choose and why?

10. 1000TB of plots. The scan time is 500 seconds.

1$ / 100 TB is what timeframe ?
At the moment, a rental of 1 PB for 10$ per day would be (barely) profitable.
Operating 1PB for 10$/day is impossible.

Option 10 will have a higher revenue than all others.

You will find the best deadline buried in these plotfiles after you scanned the whole volume.
The probability to find the best deadline that is buried in this stack within 500seconds is 1.
For 240 seconds it is 0.48 , so the "excess" volume of 520 TB is helping, just not with a factor of 1.

For a more accurate factor, you'd need to analyze the historical block time distribution as it is not symmetrical (more "fast" than "slow" blocks). Anyone fluent in R ?

@bluebook said in random plotting question...:

Hypothetically, if i was to run 2 identical mining rigs for two separate accounts, if i plotted nonces 0 to 200,000,000 on each of them, would they generate the same d/l's on each block, or is the contents of the plot file affected by the accid used to generate the file?

I ask as lots of miners will have nonces 0 to X as people generally start at 0 and work upwards, but can't figure out whether if 2 people submit the same fastest d/l for that block, the person with the oldest accid wins, or the first to submit.

I have a feeling that the plot file contents is affected by the accid (meaning each nonce between 0 to X is different depending on what accid is plotted for and the size plotted), rather than multiple people submitting the same winning d/l and it being down to a second roll of the dice as to whether they win the block or not

A plot files's content is a function of the account-id.
So, two different accounts with identical plot size will report vastly different deadlines for a specific block.
In the long run, and I think of 10k blocks here (a month), the statistical average of all deadlines will be very close for both accounts, as they have the same plotsize.

And this is how pools calculate your plotsize, it is a statistical value of given network size (which itself is a statistical value) and your submitted deadlines, averaged over a long time. The shorter the timespan used for averaging, the spikier (both too high and too low) the "calculated/guessed" plotsize is.

If two miners submit nearly identical deadlines, luck decides which one will get to sign the block. In an ideal world of massively interconnected wallets without any timestamp hitches, blacklisted nodes, low memory situations, the lowest deadline will win, always. But the real network is a very complex thing, and so a better deadline might get discarded because of a slower propagation path.

@bluebook "Burst" does not measure, a specific software tool you want to use does it.

I know that my own tools use TiB (2^40) instead of what HDD manufacturers use (10^12 per TB). The difference is about 10 % (2^40/10^12 == 1.099511627776). The amount of USABLE space is further reduced by what your Filesysten needs for housekeeping and configured parameters like "minimum free space".

What your toolchain uses is easy to find out: Just plot 100 Gigabyte. Then observe the disk space the plot file uses in Bytes. Then look for the amount of free space you want to plot, voila.

Also, the amount of RAM used by the plotter might come into play. Depending on plotter engine, if you assign 8 GiB RAM the output file might very well be a multiple of 8 GiB and not the parameter given above - 104 GiB instead of 100 GiB.

         104 GiB, which is 
111669149696 Bytes, 
   109051904 Kilobytes (exactly: KibiBytes, kilo-binary, but refered to
                        by Windows Explorer as "Kilobyte").

That is the reason I don't just give an overly specific answer for my setup that does not translate well into your setup.
Test it with a file of at least 10 GB.

@tross The VPS/VM "machines" may very well have different default settings for mariadb - or are they using the exact same codebase at the time of installation ? I guess not..

@tross

TLDR; find out if your database has the correct charset/collation:

$ echo "SELECT SCHEMA_NAME 'burstwallet', default_character_set_name 'charset', DEFAULT_COLLATION_NAME 'collation' FROM information_schema.SCHEMATA ;  " | mysql -uroot
burstwallet	charset	collation
burstwallet	utf8mb4	utf8mb4_unicode_ci
$

If you get "latin1" or just the bare "utf8" in the charset column, you have found a problem.

@tross
I'm barely able to read this screencap as it is VERY small and I am rather old,
but something pops up from memory:

If your database was created with the defaults, the (systemwide) defaults may not be set to the vallues burst needs. I had this problem on a standalone mariadb installation on FreeBSD, and the setup hints contain

$ echo "CREATE DATABASE burstwallet; 
      CREATE USER 'brs_user'@'localhost' IDENTIFIED BY 'yourpassword';
      GRANT ALL PRIVILEGES ON burstwallet.* TO 'brs_user'@'localhost';" | mysql -uroot
$ mysql -uroot burstwallet < init-mysql.sql

where the create statement above should contain the charset and collation explicitly;

CREATE DATABASE burstwallet CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ;

In order to find out the charset/collation of your database:

$ echo "SELECT SCHEMA_NAME 'burstwallet', default_character_set_name 'charset', DEFAULT_COLLATION_NAME 'collation' FROM information_schema.SCHEMATA ;  " | mysql -uroot
burstwallet	charset	collation
burstwallet	utf8mb4	utf8mb4_unicode_ci
$

If you get "latin1" or just the bare "utf8" in the charset column, you can quickly change that (depends on your machine and the speed of the underlying storage for the database) -
stop the wallet (!) and export/drop/create/import the database:

$ mysqldump burstwallet >/somewhere/dump.sql
$ echo "DROP DATABASE burstwallet ;" | mysql -uroot
$ echo "CREATE DATABASE burstwallet CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ; " | mysql -uroot
$ mysql -uroot burstwallet </somewhere/dump.sql

After that restart the wallet and see whether the daily error goes away.
Alternatively, just import the dump into a new database (without touching the db burstwallet), alter the brs.properties to use this secondary. If the error goes away, throw away the primary and keep the secondary, or vice versa.

@mongrel said in My plotting seems slow:

Am I doing something wrong?

Yes, you are looking at 10 GBytes.
Make it 120 GB and you will see the effect kick in.

(Most) SMR disks are not SMR-only, but have a small area which is formatted with PMR. This is a staging area that swallows the data you write to the disk. After external (host-disk) I/O settles, the disk is still busy, shuffling the data from staging (perpendicular) to final (shingled) area.

As long as your write bursts fit this into this PMR area
AND
you have a very low I/O load afterwards for the times required to reshuffle data,
your SMR disk will behave as any other disk.

It is only when you

a) write more than fits this staging area
b) write randomly
c) write continously without enough pause for reshuffling

that the SMR penalty hits you. Unfortunately, plotting does all of this.

I'm sure we have this explained in various places on this forum, but don't have a link at hand.

@zac123 Please follow the link given above and read.
Makes no sense to duplicate large, dull tables here.

The takeaway is: Miners are rewarded with transaction fees plus the diminishing reward, which will be at 10 Burst around Oct'2025.

@zac123 any log entries ? Define "keeps crashing" - spontaneous reboot, system frozen, just the miner program vanished ?

I guess not (now).
The payments are showing, your balance is correct.
It is just that the transaction is not in your transaction list, but in the sender's list only.
Do you care which of the 1$ notes in your pocket were received from whom ?

There is a huge time-memory tradeoff involved.
In order to save space, these multi-out transactions are stored, tied to the sender only. When wallets process the block, all involved balances are updated. If you as a recipient want to know who sent you some in a multi-out, you have a very expensive database query to make, run-time wise.

The reason for this design is very simple: You can opt for time OR space.
The sensible decision is : space.

If you need to find out who sent you 1$, that can be done. It is just not stored as a classic, separate,individual transaction and is therefore not easily accessible by the receiver. Displaying these multi-out in the user interface of the receiver might need some time to be implemented - there are other, more important things in the queue.

And for the nitpicks: yes, this is a very nonchalant use of the "wrong" terms. I'm trying to answer a question without touching computer science stuff, as it gets complicated, fast. See https://simple.wikipedia.org/wiki/Space-time_tradeoff