So how much missing signage points per 24h is considered bad? I got around 120 missing signage points on boths of my farmers in about 48h. How many signage points are there in 24 hours?
My thoughts are it’s due to the new Timelords causing spikes.
Has anyone seen an increase in missed signage points recently. My hardware has not changed at all and I am seeing hundreds per day now.
I have a 6gb A2000 farming about 900 GB C8 Plots (13000).
I am thinking that 6gb Vram is not enough or the A2000 needs swapping for a card with more cuda cores as the missed signage points occur when the gpu load is maxed for a period of time. This is when the missed signage points occur.
me too, over 100 per day this week.
It’s because of the regular chain re-orgs we are seeing currently.
You’re not actually missing any SPs, it’s just a false reporting due to the way this number is computed.
@paulcre Try the new giga24, fixes the GPU overload issue.
My missing signage points has tripled last week. 326 per day! Is it not huge?
My internet connection is 60 megabit which I think is fast enough.
After 3 days the storm is gone and misssing signage points is now 10 / day. Was that a storm?
Whats going on? Or is it a misinterpretation of the windows gui? Because there is no “missing” in the debug.log!
I think whoever caused it was asked to stop causing it.
Noticed this also - have changed nothing in the farm and suddenly has gone from >100/day to 2 per day
I think it’s all this Timelord stuff going on on the chain recently. From the Chia docs, the signage points occur every 9.375 seconds (64 signage points per 600-second sub-slot). If these ultra-fast Timelord ASIC’s have been and are still being brought online, there would likely be sometimes more than 64 signage points per 600-second sub-slot, and sometimes less (to make up for more in the previous sub-slots). This is where I think the GUI states there are missing signage points.
The source in farmer.py is here:
def check_missing_signage_points( self, timestamp: uint64, new_signage_point: farmer_protocol.NewSignagePoint ) -> Optional[Tuple[uint64, uint32]]: if self.prev_signage_point is None: self.prev_signage_point = (timestamp, new_signage_point) return None prev_time, prev_sp = self.prev_signage_point self.prev_signage_point = (timestamp, new_signage_point) if prev_sp.challenge_hash == new_signage_point.challenge_hash: missing_sps = new_signage_point.signage_point_index - prev_sp.signage_point_index - 1 if missing_sps > 0: return timestamp, uint32(missing_sps) return None actual_sp_interval_seconds = float(timestamp - prev_time) if actual_sp_interval_seconds <= 0: return None expected_sp_interval_seconds = self.constants.SUB_SLOT_TIME_TARGET / self.constants.NUM_SPS_SUB_SLOT allowance = 1.6 # Should be chosen from the range (1 <= allowance < 2) if actual_sp_interval_seconds < expected_sp_interval_seconds * allowance: return None skipped_sps = uint32(floor(actual_sp_interval_seconds / expected_sp_interval_seconds)) return timestamp, skipped_sps
So it looks quite feasible to me that anything 15 seconds or more between signage points is counted as ‘missed’ by the GUI, even if no signage points where missed in reality.
The problem is this, in case of re-orgs the
signage_point_index is jumping back and sometimes not all are re-traced again. So a single re-org can cause multiple “missed” SPs.