nanoHUB@HOME - On the Naughty List

[Nick Name]

nanoHUB@HOME looks like an interesting project. Unfortunately, no one can return work after a server move on the 15th! I usually notice things like that but just tonight I saw I had 30 tasks that were stuck, and found out on the forum it's been a problem for awhile. I've aborted those tasks and set to NNT, it's bad enough dealing with the Virtualbox overhead and occasional failures due to bad apps. I'll need to see a more involved admin before returning.

 

[Nick Name]

Still no word from the admin(s) on the status of this project, over a month after the move. I consider this project closed unless I hear otherwise.

 

[Nick Name]

Work is available after a lengthy hiatus. It looks like there's a mix of resent - previously bad - tasks as well as new work. The database is full of bad tasks from when the project started so I'm putting it back on hold for the time being. There have been some reported concerns about excessive disk writes as well, so this project may not be suitable for SSD unless you're using an expensive commercial grade one or a RAM disk.

 

[Nick Name]

Work is flowing again if you're interested. Tasks are validating for me on both Windoze and Linux, I had 4 bad ones between 2 machines out of several dozen yesterday.

 

[Nick Name]

No sooner did I post this than I hit a bad run of work. This might have been at least partially my fault as I set up an app_config to max out the number of threads on the Windoze machine. The reason for this is that I was also running Kryptos@Home and had multiple VirtualBox jobs running simultaneously, which over taxes the machine when I'm using it. The best way to deal with this is only run one VB project at a time and set project_max_concurrent in your app_config to one, but I had already downloaded a bunch of work and didn't want to abort it. I could have saved myself some time fooling with the app_config because I ended up doing that anyway. Kryptos jobs worked even though they weren't actually using all available threads based on system monitoring. Nano started but were never actually doing anything. VirtualBox work is finicky at best but these Nano jobs seem to be pickier than usual.

 

[Nick Name]

It looks like most of the Linux work is validating, or at least not failing. The problem is there is a wide variance in the run times and bad tasks can take an hour. The client has also downloaded an excess of work, most of that is not going to get returned before the deadline. I'm just going to let it run and hopefully sort itself out over time.

 

[Nick Name]

Most of the Linux work did get returned in time, and most of it validated. My biggest complaint other than zero admin communication is that if the task is bad it runs for over an hour, tying up resources doing nothing. It's also titled as a multi-threaded app but seems to only use one. I'm ok with that since the good tasks run pretty quickly anyway, usually just a few minutes at most.