Is there a way to figure out which disk proof attempts come from?

On one of my machines I’m seeing astronomical times for proof attempts. Parsed down to what I’m watching I see:

18:30:20.616 1 plots 0 proofs. Time: 3.04167 s.
18:30:20.618 1 plots 0 proofs. Time: 20.78349 s.
18:31:50.088 1 plots 0 proofs. Time: 83.97397 s.
18:33:38.519 1 plots 0 proofs. Time: 0.03620 s.
18:33:58.039 1 plots 0 proofs. Time: 0.04552 s.
18:34:10.100 1 plots 0 proofs. Time: 4.00617 s.
18:34:53.160 2 plots 0 proofs. Time: 27.77108 s.
18:39:16.477 1 plots 0 proofs. Time: 0.42586 s.

The vast majority are <1s, but once in a while there’s a big spike. I’m moderately decent at Linux sysadmin and I can’t find anything obviously wrong. I’m starting to suspect I could have a bad HBA or backplane in the machine, but I also have 2 USB disks in a (probably not great) Vantec dock, so it would help a lot if I could figure out which disk the slow responses are coming from.

I’m trying to watch iostat, but it’s tough to catch anything without staring at it. Any tips or tricks would be appreciated.

I’m also plotting to these disks, so maybe I’m just seeing unlucky I/O contention. Is that possible?

1 Like

Yes, the “Black Box” aspect of chia is a bit frustrating to me at the moment as well.

My best advice… you could fire off chia plots check and just watch it? I think by default it tries 30 proofs on each plot.

I have an irrational desire to know which of my machines was the victor when the farm wins a block. No clue how I would accomplish that.

3 Likes

I’ve also heard this expressed as “my friend and I pooled drives, so we need to know which plot won so we can share the coin appropriately”… it makes sense.

1 Like

@dan90266 Using chia plots check was the quick, simple type of thing I was looking for. I didn’t even realize it showed the timings. Thanks! I didn’t uncover anything, but I also rebooted that machine because some of my plots lined up enough that I didn’t lose much progress and something just felt off.

Something else I find tough is that I can’t really reproduce anything when I have issues because everything’s on a 15h cycle for me plotting to HDDs. By the time I have enough rounds to get any consistency my disks will be full.

I’m not sure how to see which machines are winning on Windows, but on Linux I do it like this (on each harvester):

  1. Edit config.yaml and set logging level to INFO.
  2. Make a script called ~/plotter/showproofs.sh with executable permission and the following contents:
#!/usr/bin/env bash

grep -h "eligible" "${HOME}/.chia/mainnet/log/"* | grep -v "0 plots" | grep -v "0 proofs" |  cut -d ' ' -f 1,9-10,17-20,23-24
echo "All logs scanned."

You might need to tweak the cut command or even just get rid of it if you don’t care.

  1. Make a script called ~/plotter/watchproofs.sh with executable permission and the following contents:
#!/usr/bin/env bash

watch -n 30 "${HOME}/plotter/showproofs.sh"

Then run watchproofs.sh and if you win on that machine it’ll show you the log line you’re interested in. It’s a bit hacky, but once plotting is done you won’t care :slight_smile:

@codinghorror I think sharing XCH into the same wallet (on a win) is probably a mistake regardless of how it’s done or accounted for. I’d probably create plots with different -f and -p keys and farm them via Docker so wins can be sent to separate wallets. It would require both friends to run a full node and would be a lot more complicated to set up, but it would be better for everyone to have their own wallet IMO.

The reason I say that is because there could be tax implications that come along with nonchalantly transferring XCH between people and my impression of the community (from reading Reddit) is that most people haven’t looked up the tax code in their jurisdiction. As a disclaimer, I have no idea what I’m talking about beyond knowing that I tried to look up the tax rules (for crypto currency in Canada) last night and it’s complicated.

Here’s a good example of why people may want to be cautious.

2 Likes