LHC@home

Overnight one of the XP/POSReady SP3 hosts here got 20 of these. They fail like this. Looks as though it would be fairly simple to fix. These hosts have been kept partly to help out with SixTrack for which they have done sterling service, so here is a request for this...Please.

Hi, and thanks for your error report.

I am not surprised that SixTrack does not run on WinXP 32-bit. It is built on Windows 10 with a minimum Windows version compatibility of 6.0. I managed to download a WinXP SP3 VHD image from Microsoft, so I will try and tweak our build system and test it on this.

The solution you posted is specifically relevant to the windows.h include file, so not sure how this relates to the Fortran side of things, if at all. But I will try and set Windows version to 5.1 for libarchive and the BOINC library as a start.

---

SixTrack 5 Core Developer. github.com/SixTrack/SixTrack

OK. Thanks for taking the trouble. The breath is baited, the fingers quivering...

Tried it on mine and it was an instant crash a second after d/l

So back to Theory X2

https://lhcathome.cern.ch/lhcathome/results.php?hostid=10447575&offset=0&show_names=0&state=0&appid=1

Tried it on mine and it was an instant crash a second after d/l

So back to Theory X2

https://lhcathome.cern.ch/lhcathome/results.php?hostid=10447575&offset=0&show_names=0&state=0&appid=1

Yes, it's the same error.

The problem is as stated in the OP that the kernel call to the clock tick counter does not have a 64 bit precision interface on Windows OSes before kernel 6.0 (Windows Vista). On older OSes this is bypassed in for instance zlib by taking the 32 bit value and padding it with zeros.

For us, unfortunately, this does not look straight forward to fix as the libgfortran.a we link is built with WINVER >= 0x0600 by default. We use MSYS/MINGW-w64 to build SixTrack on Windows, and it comes with packages that are too new to still support pre 6.0 kernels.

We did manage to build a working exec for WinXP for the 5.2.5 release because one of the guys here had an old virtual machine where the build environment had not been updated for a couple of years. That is not really a good long term solution though.

---

SixTrack 5 Core Developer. github.com/SixTrack/SixTrack

Well there is/was XP Pro x64 Edition, released on April 25, 2005

Unlike the x86 version it could also use more than 4GB DDR2 ram

An update on this issue.

I went through the source code of 4 different version of gcc, and I didn't find anything that indicated the issue was there either. In the end I came across a discussion about MSYS/MINGW support for WinXP. They bumped the minimum requirement to Windows 7 in September last year. This means our build environment (runtime libraries) no longer supports Windows XP. It will likely still work on Vista though.

We'll have an internal discussion what to do about this in the future.

---

SixTrack 5 Core Developer. github.com/SixTrack/SixTrack

Well there is/was XP Pro x64 Edition, released on April 25, 2005

Unlike the x86 version it could also use more than 4GB DDR2 ram

Yes. However, the kernel call was added in Vista, so I don't think that helps. In any case, SixTrack only uses up to a couple hundred MB of memory, depending a little on which accelerator it's running simulations on.

---

SixTrack 5 Core Developer. github.com/SixTrack/SixTrack

I managed to download a WinXP SP3 VHD image from Microsoft, so I will try and tweak our build system and test it on this.

Please, do not lose your time and effort on support XP.

Please, do not lose your time and effort on support XP.

I always think the same thing for any legacy system. They should be optimizing for the newer ones.

I always think the same thing for any legacy system. They should be optimizing for the newer ones.

Microsoft has stopped support to XP 5 years ago.
All hw producers (Intel, Amd, Nvidia, etc) has stopped to update their driver.
XP has less than 4% of market share (win10 has 44%).
Why continue to support it on Boinc projects?

We don't mind supporting old systems if it's a simple fix. We have a pool of contributors running on XP, and our application has run fine on it for a long time after Microsoft stopped their support. Since it now stopped working with our recent builds, it was important for us to understand why.

---

SixTrack 5 Core Developer. github.com/SixTrack/SixTrack

Microsoft has stopped support to XP 5 years ago.

Not quite, at least for 32 bit systems; this is (part of) the last XP update..

2019-04 Update for POSReady 2009 for x86-based Systems (KB4487990), Windows XP ... Update for WES09 and POSReady 2009 (KB4468323), Windows XP ...as far as I'm aware, this really is the end of free MS support.

and there's an (unofficial) SP4. However there is clearly a limit on the effort that can be justified for this.

[edit] Updating from XP often involved scrapping a lot of still serviceable hardware which must have quite an environmental cost, If this can be reduced without too much trouble , it must be good [/edit]

Updating from XP often involved scrapping a lot of still serviceable hardware which must have quite an environmental cost, If this can be reduced without too much trouble , it must be good

I have always considered the greater environmental cost to be energy use. In fact, I don't even sell my old stuff on e-Bay, even though I could make some money.
But I don't want the CO2 being produced to power them. The new generations are much more energy efficient.

Well I really don't care if SixTrack stays with the new version and XP doesn't work and all I was doing was a quick test for *M* when he mentioned the problem and he had less than 2GB ram and may have used both cores to run them and as we *all* know the computer uses some of that memory just to run at all.

I only have the one XP Pro X86 still running here because......well because it never fails and has been here since 2004 and is only here running Theory tasks (single core X2 on the old 3-core Phenom)

I also have its twin computer from back then but updated it to a Win7 X64 and then the Win 10 X64 so I then could add more ram and use it to run these Theory tasks either 2-core or 3 single core tasks (and actually messed around with it and turned on that *4th core* that is what these 3-core Phenoms actually are)

So if the day ever comes that *Theory* tasks demand a Win7 X64 or better I will finally update it to that OS version and then it will *recognize* the extra ram that is already plugged in that box.

(oh and I will continue to drive my 1970 Cutlass with the 455 and my old 1980 Jag and 1976 4X4)......and the 1999 Chrysler until the day when one of us is no longer on the road

(now I also have an excuse for the weather records I have been writing down here since 1971)
.......my final post on this thread to cut down on the possible
damn I hate these message boards that have the 1995 version still running like it was facebook of physics

I only have the one XP Pro X86 still running here

I have one PC with WinXP 64-bit running, because I am also crunching GPUGRID, and the WDDM overhead contained in Windows versions later XP brakes the GPU crunching speed by about 20%.
So, as long as the GPUGRID code still supports XP, I will definitely keep this XP machine alive. Makes sense.

Dear all,
even though we have the required executable, we have no efficient mean to plug it in at present. Technically, we could bump minor version and distribute new exes - this option requires minimal adjustments on our side, that we would like to avoid in this period of extremely high load. The other option IT suggested, i.e. to add plan classes based on the OS version, though documented, is not in use by major BOINC projects - hence, again, a high load period is not the ideal moment when starting playing with it.

Even though we tried to keep the old hosts in the game to contribute also in this period of high load, I regret that they will anyway miss the moment.
On the longer term, maintaining the special build environment for no longer supported OSs (and necessary compilation libraries) takes resources, and we would not to that indefinitely.

Can I kindly ask the concerned users to update their hosts?
Thanks a lot for your understanding,
A.

Please note that we would strongly discourage running an old and unsupported Windows version connected to the Internet due to the risks of virus infections and that the hosts can be used to spread malware.

To keep using old computers, better to install a lightweight Linux distribution like Linux Lite, Tiny Core Linux, Linux Mint or similar. (Myself I use Xubuntu.)

Now that I found this thread I now know why my XP jobs are all failing.
I have now set that machine to No More Work, to stop the 400+ errors I have gotten in the last few days.

I wont be updating it as it still does all I want it to do (well most). Upgrading requires a new OS, no direct update path, meaning dump what I have and then install from scratch the new OS, loss of compatible programmes and some equipment. Just does not seem to be worth the effort.

One less computer on this project, my last two do Sixtrack because I could never get Theory or Atlas CPU jobs to work, they are Linux so can still do the work. I don't do VM work as it appears to be a pain to set up and run and my Linux knowledge is not of sufficient caliber to put in the effort.

Conan

---

An update to this topic:

we've managed to find a way to plug in the XP compatible 32bit version of sixtrack without changing version - it is now plugged as sixtracktest before deployment in production.
We made the exe available as default plan class, let's see if it gets distributed.

This is not an invitation to remain forever and ever with Win XP hosts, rather a last call to those volunteers who have XP to contribute once again and welcome their help, especially in this period of high load. It was possible to have the exe thanks to the fact that one of our developers kept an outdated compilation environment, but this is not going to be kept on the long term.

Can I ask the XP users to try to download the tasks and crunch them?
In case you don't get any, please ping me with private messages.
Cheers,
A.