Just wanted to say hello as it is my first post.
Also node version 1.28.0 just minted its first block on my young but eager Southern Cross pool [scrs]
1 Like
Hi, mainnet or testnet?
Mainnet 
Mainnet
I was wondering if I should try and put this version in the build.
Takes 3 seconds to revert back so decided to go for it. )
It’s not official released but I think should not be any issues… 
That’s what I was worried about. The 1.27 is still showing as latest on GitHub.
I will report if any issues encountered. Been up 48 hours so far.
2 Likes
Did you notice any big difference? Especially in mem usage and missed slots during epoch change?
Tbh, no. Not much difference. At least none that I can report atm.
As far as missing blocks, I haven’t had any.
I am very young, started at 275.
Maybe I am wrong, but it seems like memory consumption is a bit higher.
I have my nodes containerised. With 1.27, it would average around 6.5Gb per container/per node. Now it is over 7Gb
I will report if anything noticeable/out of order happens.
I am on patch 7029306
1 Like
Sorry I meant missed slots not missed blocks 
Ah, slots…
I don’t think I have any missed slots. Sorry again )
I think you get this metric (correct me if I am wrong) only when you have at least one missed slot. Since I don’t have this metric, I assume no missed slots. Here is full output:
podman exec relay curl -s localhost:12798/metrics | grep cardano
cardano_node_metrics_Stat_threads_int 15
cardano_node_metrics_density_real 4.8114405363865194e-2
cardano_node_metrics_epoch_int 280
cardano_node_metrics_txsInMempool_int 0
cardano_node_metrics_RTS_gcMinorNum_int 49046
cardano_node_metrics_txsProcessedNum_int 49443
cardano_node_metrics_RTS_gcLiveBytes_int 2960244024
cardano_node_metrics_mempoolBytes_int 0
cardano_node_metrics_nodeStartTime_int 1627388668
cardano_node_metrics_RTS_gcMajorNum_int 766
cardano_node_metrics_blockNum_int 6042783
cardano_node_metrics_Stat_cputicks_int 278120
cardano_node_metrics_RTS_gcticks_int 75151
cardano_node_metrics_RTS_mutticks_int 202967
cardano_node_metrics_served_header_counter_int 17742
cardano_node_metrics_Mem_resident_int 7191609344
cardano_node_metrics_slotInEpoch_int 404759
cardano_node_metrics_slotNum_int 36001559
cardano_node_metrics_RTS_gcHeapBytes_int 7170162688
My bad. I was looking at the relay instead of producer. Yes, I do have some missed slots.
cardano_node_metrics_slotsMissedNum_int 35
The epoch changes in like 7 hours, I will let you know if this number increases by much during the change
1 Like
Thanks. Really looking forward to get that info! A couple of other SPO’s in the xSPO alliance are currently tweaking the settings to find out how these missed slots are caused and how to prevent them using the current 1.27.0.
Yes, the missing slots number jumped high during the epoch change.
I set a timer to measure it 5 mins before the change and 5 mins after the change. The jump was like 200 slots.
5 mins before change: 43
5 mins after change: 239
I moved the node to the new patch-level 7096191 which was just released.
I will monitor it more closely and see how it goes
So far it’s been running for about 10 hours and not a single missed slot
Cheers
1 Like
hello, I don’t think it’s recommended to upgrade to this version until it’s out officially? Anyway, we are also running 24 / 7 testnet cluster, so maybe I could roll it out there, but not sure if it’s really needed at this point.
Yeah doesn’t look like they made any changes there. Same results it seems.
There also is an open github issue addressing the epoch switch missed slots and that it would be worked on after alonzo. Understandable and wise choice.
You shouldn’t do that. It’s not yet released for mainnet.
Possibly. Works fine though…