signum-network
error shutting down a node - NoSuchFileException: genscoop.cl
node v3.8.0 using H2. From the log I only could get these last lines, the rest is at the screenshot
[INFO] 2024-01-29 13:55:55 brs.db.sql.Db - H2 defragmentation started, this can take a while
[INFO] 2024-01-29 13:59:19 brs.db.sql.Db - Database shutdown completed.
[INFO] 2024-01-29 13:59:20 brs.OCLPoC - Platform 0: AMD Accelerated Parallel Processing
[INFO] 2024-01-29 13:59:20 brs.OCLPoC - Choosing Platform 0 - DeviceId: 0
Im surprised this wasn't noticed sooner, as i cant remember that file being around for a long time...
Anyways file appears to have been deleted at some point. Two temporary fixes available:
- Turn off gpu acceleration
- Download the file from the old burstcoin repo and put it next to the signum-node.jar (I'm guessing on location) https://github.com/PoC-Consortium/burstcoin/blob/afb45c48715722563d4e689a2f6fc4645bf5ece7/genscoop.cl
** if you attempt the second option and it works please report back so it can eliminate possible guessing **
Some while ago I noticed the file was not present and got it from a previous release. But from my tests, at that time, the sync speed was not affected by using the gpu accelerated code, neither the card had any significant amount of usage, so I assumed the node code for sync (and database insertion) was much more impacting than the scoop checks. Is it worth having the OpenCL option?
With current network speed it's not really needed, maybe in the future. I wouldn't personally want to see it removed from code right now, but maybe just add a notice it's not implemented and a skip?
Some while ago I noticed the file was not present and got it from a previous release. But from my tests, at that time, the sync speed was not affected by using the gpu accelerated code, neither the card had any significant amount of usage, so I assumed the node code for sync (and database insertion) was much more impacting than the scoop checks. Is it worth having the OpenCL option?
If it has no positive impact on the sync process we could rip it off. From my recent researches and works on Version 3.8 I figured out that the bottleneck is not so much the processing power but foremost database access. This is why H2 is significantly faster on sync than PG and MariaDB.
with the new release 3.8.1 we figured out that now generate_scoop may take a significant amount of time while syncing... But as @deleterium said: If there's no real performance gain we really should ask, if it is worth having GPU support