How usable is CLN currently (vs LND)?

[Jodmapht]

These seem to all apply to LND and not CLN though, correct? I can open an issue on the CLN's repository.

Sorry yeah, I am remote into my desktop that is logged into the forum and the last part "There might be something similar in CLightning" did not make it.

Ok, so it looks like this could be all normal and due to the fact that my LN node is new. It is supposed to calm down...

At least for the CLN part, I'm not sure why core is using anything. Mine only has activity when blocks are found and even then not much.

How are you powering the RPi? I have seen some 5V adapters cause issues.
This is one of my favorites.... 5% over voltage with no load, add a load and I can get it to 5.5V / 10% over voltage, then bad things^tm happen.



-Dave

Do you recall having your service using a significant amount of CPU and IO for a few days initially?  When comparing to downloading and verifying the blockchain, CLN does not seem to be downloading much data or using much disk space, but it saturates the SSD IO and puts significant load on the CPU. My whole bitcoin directory for CLN currently uses only 82M of disk space. I see about 20 KB/s or less of up or down traffic for the node. lightningd at 36% and bitcoind at 110% CPU core usage.

I have been using the official 15W power supply. I have not had any obvious issue with it. What do you have exactly? I have not done any overclocking for my node, but as I mentioned got UASP and trim working for the SSD, and I use it for the OS as well, I do not use any SD card, I activated noatime. I would expect IO performance to be quite optimized for my RPI.


Maybe I should bump up bitcoind's dbcache temporarily to help CLN syncing faster with less IO operations? I had dbcache configured at 7368 MB when I downloaded and verified the blockchain, but since I brought it down to 300 MB... Maybe it is bitcoind that is currently creating the IO strain and not lightningd...


I will try increasing dbcache to 5000


Ok I looked at the details using htop, and what I see is that cln's bcli is writing to the disk at 10 MB/s constantly...

[moderator's note: consecutive posts merged]

[DaveF]

Ok I looked at the details using htop, and what I see is that cln's bcli is writing to the disk at 10 MB/s constantly...

To me that looks like it's still trying to do something with the initial sync, but it really should not be taking this kind of time. If it's still doing it now 15+ hours from your last post and a long time after your initial seeing of the issue. I would open an issue on github. It is obviously working since you can see the channel you created in 1ml so something else is going on.

Sorry I could not help more, but this looks more like it's not a configuration issue but something withing CLN / your setup.

-Dave

[runam0k]

Actually I've been using the rebalance plugin, rebalancing individual channels manually:
https://github.com/lightningd/plugins/tree/master/rebalance

Running a larger node with good liquidity will definitely require some automation though and the LND ecosystem seems to have a lower learning curve in that regard.

CLBOSS automates things and generally works well, though it's purpose is more about managing fees than purely rebalancing https://github.com/ZmnSCPxj/clboss

[Jodmapht]

Ok I looked at the details using htop, and what I see is that cln's bcli is writing to the disk at 10 MB/s constantly...

To me that looks like it's still trying to do something with the initial sync, but it really should not be taking this kind of time. If it's still doing it now 15+ hours from your last post and a long time after your initial seeing of the issue. I would open an issue on github. It is obviously working since you can see the channel you created in 1ml so something else is going on.

Sorry I could not help more, but this looks more like it's not a configuration issue but something withing CLN / your setup.

-Dave

Thanks. It ended up settling down after another day. I wish I understood more what it was doing and why it was not performing these operations in memory...

[DaveF]

Ok I looked at the details using htop, and what I see is that cln's bcli is writing to the disk at 10 MB/s constantly...

To me that looks like it's still trying to do something with the initial sync, but it really should not be taking this kind of time. If it's still doing it now 15+ hours from your last post and a long time after your initial seeing of the issue. I would open an issue on github. It is obviously working since you can see the channel you created in 1ml so something else is going on.

Sorry I could not help more, but this looks more like it's not a configuration issue but something withing CLN / your setup.

-Dave

Thanks. It ended up settling down after another day. I wish I understood more what it was doing and why it was not performing these operations in memory...

Either some setting has to be tweaked to get it to use ram instead of the drive OR it was just doing some table manipulation in the database and its just reading & writing until it's done.
Glad it's working.
Make sure to do regular backups if you have any funds in there, RPis are good and all, but you still do not have RAID in case of a disk issue.
Been there, done that.

-Dave

[Jodmapht]

Ok I looked at the details using htop, and what I see is that cln's bcli is writing to the disk at 10 MB/s constantly...

To me that looks like it's still trying to do something with the initial sync, but it really should not be taking this kind of time. If it's still doing it now 15+ hours from your last post and a long time after your initial seeing of the issue. I would open an issue on github. It is obviously working since you can see the channel you created in 1ml so something else is going on.

Sorry I could not help more, but this looks more like it's not a configuration issue but something withing CLN / your setup.

-Dave

Thanks. It ended up settling down after another day. I wish I understood more what it was doing and why it was not performing these operations in memory...

Either some setting has to be tweaked to get it to use ram instead of the drive OR it was just doing some table manipulation in the database and its just reading & writing until it's done.
Glad it's working.
Make sure to do regular backups if you have any funds in there, RPis are good and all, but you still do not have RAID in case of a disk issue.
Been there, done that.

-Dave

Thanks,

Do you think using PostgreSQL instead of SQLite could have prevented this?

Yes I got some Lexar USB sticks with a metal enclosure I will use for backup...
Thanks!