@wateroakley
I'm used to pretty good performance of Linux VMware guests on this PC (4 threads of an i7 7700HQ, 16 MB of RAM allocated to VM, 100 GB fixed HD space in VM). I'm noticing considerable mouse lag as I move the cursor around in the VM window. Are you noticing the same thing too? I did perform some of the MacOS tweaks for VM performance listed at https://github.com/sickcodes/osx-optimizer.
The mouse does not lag on this macOS VM. Did you enable the guest additions, which provide better integration for mouse and keyboard ?

@geophi
I've adjusted the screen resoultion to 1920x1080: VBoxManage setextradata "macname" VBoxInternal2/EfiGraphicsResolution 1920x1080. After making the change, the mac screen window inside VBox fills more than the display and the mouse is laggy. Changing the mouse 'tracking speed' to 'fast' in 'System Preferences' doesn't make a big difference. Stopping the 'oregon trail' video, that apple had decided to play continuously, brought back the responsiveness!

Two of the tasks are cycling at 99.98% for the remaining 1 minute 45 secs to zero and ---. ? When I suspend one of the two, the second task pauses at remaining time ---. It sits there until I resume the suspended task and then both will cycle again. Wierd?. Then when I restarted the BOINC manager, four crashed with 'computation error' and 'output file missing' in the event log. Note to self: "LEAVE IT ALONE". Four new tasks are running now.

---

Unfortunately neither changing a VBox setting nor changing the number of CPUs to 4 worked.

Which just confirms what I have always thought (despite having been able to run Ubuntu in VB under Ubuntu host.) Virtualisation is a dark art.

Once my i7-4790 Windows 10 PC finished the last of its N216s (on WSL2), I installed Mojave on VBox on it. So far no issues with running CM3Ss. Definitely seems like the issues is with trying this on AMD CPUs. Not sure if there's a fix though.

Once my i7-4790 Windows 10 PC finished the last of its N216s (on WSL2), I installed Mojave on VBox on it. So far no issues with running CM3Ss. Definitely seems like the issues is with trying this on AMD CPUs. Not sure if there's a fix though.

Yet it is working for George with the same CPU I have. Hence my comment about it being a dark art!

Edit: I don't actually think my problem is to do with the CPU type and we don't really have enough data points to be sure. I will continue to play from time to time but next serious go at it might not be till next time I do a clean install of my OS.

I'm experiencing an odd behavior in BOINC running CM3s in VBox VM Mojave on Windows 10. The progress bar has stalled (values are stuck on a number and not going up) on all tasks but the Elapsed and Remaining times are still counting. No trickle ups in a couple of days even though before it was at least once a day. Suspend/Resume seems to get things going again. Has anyone experienced anything like this before?

I'm experiencing an odd behavior in BOINC running CM3s in VBox VM Mojave on Windows 10. The progress bar has stalled (values are stuck on a number and not going up) on all tasks but the Elapsed and Remaining times are still counting. No trickle ups in a couple of days even though before it was at least once a day. Suspend/Resume seems to get things going again. Has anyone experienced anything like this before?

Sounds similar to two here. When they got to 100% and —- they cycled back to 99.98% then 100% and —. Wierd. The only option, for here, was to abort them.

---

Unfortunately my first batch of CM3s errored out at the very end. Seems like the output file was not found. For example:https://www.cpdn.org/result.php?resultid=22195470

In my last post I asked about progress bar stalling and needing suspend/resume to get going again. What seems to precede that is the following in the event log (numbers in parenthesis vary):

New system time (1647911207) < old system time (1648063920); clearing timeouts

I don't know how to read those numbers but It seems like VM system time is running faster significantly enough to lead to these adjustments in BOINC when some kind of time sync happens. This seems to negatively affect tasks. I tried a command I found in VBox manual that makes VM sync time with host system frequently but it doesn't seem to be making a difference. Seems like VM syncing may not be the same as guest OS (Mojave) syncing. I'm thinking if I should turn off time sync in Mojave settings, which is on by default.

Has anyone seen issues like this before in BOINC?

That looks like a "Monotonically increasing time has been violated" sort of error, so... yeah, turn off time sync, see what happens.

I've not run into those over on Linux, FWIW.

I've run Linux VMs on Hyper-V on the PC I have the macOS on with no such issues. This is my first time trying VBox though.

I turned off time checking/syncing in macOS but it's too early to tell if it'll help. I got some other ideas to try if it doesn't. I'm a little suspicious that my currently processing tasks might error out also at the very end, even if I find a solution. Is there a way to make these tasks start from the very beginning? I think that once I find a solution, restarting tasks from scratch might make it more likely that they'll successfully finish.

Is there a way to make these tasks start from the very beginning? I think that once I find a solution, restarting tasks from scratch might make it more likely that they'll successfully finish.

Unless you made a back up of all BOINC data including client_state.xml and a few other files as well as the downloaded task files, I think you are out of luck. If you have already sent trickle up files and zips to CPDN time data may end up making the tasks error even then though turning off internet access, possibly for the whole computer as trickle up files still go even when network activity is suspended may enable a proof of concept test.

I used to back up all my BOINC directories to enable crashed tasks to restart in the days when some of my tasks took over six months to run. If running more than one task this would involve careful editing of the client_state.xml file. I have not done this for many years now however. Even then, I think I only saved about one in five tasks of those I attempted it with.

I'd like to try it after current tasks finish. Would backing up the entire BOINC data directory before starting new tasks be sufficient? I only have CPDN running on this VM so it'd only be a handful of GBs of disk space.

I'd like to try it after current tasks finish. Would backing up the entire BOINC data directory before starting new tasks be sufficient? I only have CPDN running on this VM so it'd only be a handful of GBs of disk space.

I can't be 100% certain as I have only ever done it on Linux where to be safe, I also backed up .boinc in the home directory. I think on Windows that would be sufficient. I know absolutely nothing about Mac file structure but it would be an interesting exercise and even if only for academic interest, I would like to know the answer.

I'll try it and post how it works out. It'll be a few days before I can even try. So far turning off time syncing in macOS seems to be helping, no time issues in a coupe of days, trickle ups are being sent and hopefully tasks will finish successfully.

Disabling macOS time sync early in the processing of tasks helped as the last batch of tasks just completed successfully. Although the stederr looks similar to the failed tasks. Example task: https://www.cpdn.org/result.php?resultid=22194020. I backed up the entire BOINC data directory before starting new tasks.

From https://lhcathome.cern.ch/lhcathome/forum_thread.php?id=5812&postid=46519 and following I learned that CMOS RTC is set to local time on Windows machines and that's what Windows expects. Most other OSs, like Unix based ones, expect UTC time in CMOS RTC. This is likely what caused problems for me. While investigating I noticed that when setting up a VM in VBox there's an option under System/Motherboard to specify "Hardware Clock in UTC Time". It's checked by default so I unchecked it and turned time sync in macOS back on (which is the default anyway). I'm hoping that this simpler solution will work and started another batch of tasks.

This should be explained a bit more precise to avoid confusion.

The CMOS RTC can be set to an arbitrary value.
If an OS starts it reads the value and interprets it according to it's standard rules.
Windows usually interprets it as local time.
Other OSs usually interpret it as UTC.

As long as you run only 1 OS - no multiboot, no VMs - it doesn't matter whether you use local time or UTC.

The confusion starts as soon as you use a mix of OSs.
To solve this all OSs should be told to either interpret the RTC value as local time or as UTC.
The suggested solution is to use UTC since there are some (small) advantages compared to local time.

Windows can easily be told to interpret the RTC value as UTC.
Just run:

reg add "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /d 1 /t REG_DWORD /f

The VirtualBox option "Hardware Clock in UTC Time" should be set according to the host/guest combination.
Best would be to boot a guest and check whether host and guest are in sync.
If not, shut down the guest and change the setting.

Unfortunately unchecking "Hardware Clock in UTC Time" didn't work. I got the time mismatch event log in BOINC again, less than 24 hours after restarting the VM and BOINC. I found a way to interpret those numbers, which are UNIX timestamps, and they're more than 2 days apart. Specifically, it's saying that according to BOINC the VM time was more than 2 days into the future. Given this info, it seems to be more than just CMOS RTC time setting issue. I tried to keep an eye a bit on the macOS time since restarting the VM and haven't seen it not match current time. A very strange and puzzling problem.

I turned off time checking in macOS and did suspend/resume to get the tasks going again, so far so good.

Just released...656 HADCM3S work units in batch 930 for Intel Macs.