boincstats shows that there are 494 participants of Rosetta using Windows 98. There is a known issue with Rosetta such that "leave applications in memory" should be set to "yes", but there is a known issue with BOINC on Win98 that says it should be set to "no".

I'd like to hear from any Win98 users, what your setting is, and is everything working okay for you.

---

I have 2 PC's running 98SE (just crunching machines). Both seem to be running fine with 256Mb RAM.

The oldest install is https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=56849 Uptime on this one 17 days 18 hours.

The latest install is https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=105600 Uptime on this one 1 day.

---

I have 2 PC's running 98SE (just crunching machines). Both seem to be running fine with 256Mb RAM.

Yes - but what is your "leave applications in memory" setting? I only see one "client error computing" result from the older install, but that makes me suspect you have it set to "no", but are doing only Rosetta.

I should also add that this conflict (having it at "no" to satisfy Win98) _probably_ won't impact anyone who is running _only_ Rosetta on the host, except at shutdown or, if running an older BOINC client, when benchmarks are run... but multi-project folks will possibly be losing a lot of Rosetta credit.

I'm just trying to figure out the extent of the problem, and what to tell Win98 people who hit it.

---

I run rosetta and ran simap for a short time alongside with 1:1 resource share on a win98 box. I found no problems running with "leave applications in memory" set to yes.

---

Sorry I missed the memory thing.... Leave applications in memory set to yes.

Just running rosetta on both.

---

Ok, so with 2 samples, 1 switching and 1 not, the "don't set it to yes with Win98" thing is seeming less critical. Thanks!

Larger sample size definitely wanted. :-)

---

I have 1 computer with win 98.

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=52067

I changed the memory setting to yes 2 week ago and have not had any problems.

Anders n

---

Larger sample size definitely wanted. :-)

OK, happy to oblige.

This Linux box was rebooted as this Win-98 box when I saw the question. So I don't have long term experience but I have been experimenting.

Hardware is an 833 MHz Intel PIII, 256Mb ram
OS is Win-98 SE, with all MS critical updates applied.
Keep in memory when pre-empted = yes


1. Rosetta runs fine on its own

2. Rosetta and Einstein run OK together, one pre-empting the other as they should. I tweaked the preferences so that pre-emption was happening every 7 min to stress the pre-emption a bit, and it was still OK

3. Add Predictor to the mix and it goes wrong. Rosetta and Einstein stop nicely when pre-empted but Predictor does not. The GUI display shows Predictor as prempted but the cpu time is still increasing. Also this slugs (*) whichever of the other two is currently running legitimately.

4. Detach Predictor and Rosetta and Einstein co-exist peacefully again.

I don't know whether it is Predictor per se that was causing the problem, or whether the issue is the number of projects and Predictor misbehaved as it was third in line. My hunch is the former but that might be unfair.

My suggested advice is therefore

A. It seems OK to run Rosetta alone on Win-98 with keep in mem = yes

B. If running more than one project, watch carefully what heppens after each of the first few pre-emptions - does the pre-empted result still continue to accrue CPU time. If so you can't comfortably run that combination of projects.

Bill - let me know if it would be useful to continue the experiment longer than about 7-10 Rosetta WU - otherwise I will boot back to Linux soon after the Einstein WU completes


River~~

-----------
(*) Why is it so bad if two results are running together?

Every time the CPU swaps from one task to another there is a cost involved. This is not just the cost of changing the CPU state, on machines with on-chip cache this also means that the cache is now full of irrelevant data.

In fact, a single CPU box can only run one thing at a time. When it looks like it is running more than one, in fact it is swapping between the two every so often, typically every 20 milliiseconds from the mains cycle. This means that the cache may always be dirty with the other process's data. BOINC's answer to that is to swap once an hour rather than many times a second. Result: better throughput.

In fact, the predicted completion time of the Einstein result went from 18 hours to 42 hours while Predictor was stealing half its time. You'd expect it to double, the extra comes from the swap overhead.

---

River, I think we have our answer, so you can go back to Linux. :-)

Rosetta says it works with Win98. We know there is a bug if you have "leave in memory" set to no. That's not a big issue, as to the best of my knowledge, there is no "downside" to leaving things in memory unless you are _really_ overstressing your computer. But I saw warnings elsewhere that if you are running Win98, you shouldn't leave things in memory, so I got concerned about the conflicting advice.

Predictor is extremely unstable. It did exactly what you are describing on my Mac as well, plus has other problems, so what you found there doesn't surprise me.

I suspect the "Win98" advice on the other boards comes from problems that other projects have had, and anyone with a Win98 box should be careful about trying to run _too_ many projects on it, but as long as there is enough RAM, Rosetta is fine. Even Rosetta+Einstein or Rosetta+Simap is fine. Others, you need to keep an eye on for a while to be sure.

Thanks everyone!

---

...also the 'memory' problem could be that 98 is known to have a memory leak and should probably be re-booted about once per week. (I remember having to do this when I had 98 SE)

---

... anyone with a Win98 box should be careful about trying to run _too_ many projects on it

As would be expected - although all the win9x operating systems do multi-tasking, none of them do it particularly well.

It is also worth saying that Win-ME belongs with Win-9x in most respects - even tho the name doesn't fit the pattern it was the last of that series.

Any advice you see about win-98 is likely to apply to win-ME too.

For completeness (= because I am a compulsive hacker?) I also tried the same experiment on a separate Win-ME box, and get the same Predictor-related problem. Rosetta+Einstein, fine; Einstein+Predictor not. Same issue of Predictor not letting go when pre-empted.

River~~

---

boincstats shows that there are 494 participants of Rosetta using Windows 98. There is a known issue with Rosetta such that "leave applications in memory" should be set to "yes", but there is a known issue with BOINC on Win98 that says it should be set to "no".

I'd like to hear from any Win98 users, what your setting is, and is everything working okay for you.

Four Win98 systems, all running with "leave in memory" set yes, no problems at all.

Win98 has a vmem system that's as robust as 2K & XP, so despite it's other problems as an OS, it'll swap to disk just fine.

FWIW, I'm using it on those boxes because it has a lower overall memory footprint than 2K, and hence way lower than XP.

---

3. Add Predictor to the mix and it goes wrong. Rosetta and Einstein stop nicely when pre-empted but Predictor does not. The GUI display shows Predictor as prempted but the cpu time is still increasing. Also this slugs (*) whichever of the other two is currently running legitimately.

I'm contemplating detaching from Predictor for this reason. Their app does not set it's priority correct (or adjusts it after the fact). I was sharing Boinc and FaD on a couple of systems. FaD and Rosetta split the CPU very nicely at 50/50. FaD and Predictor together, and Predictor took all the CPU.

Predictor appears that it just does not play well with others.

---

...also the 'memory' problem could be that 98 is known to have a memory leak and should probably be re-booted about once per week. (I remember having to do this when I had 98 SE)

True, but maybe not relevant here. TTBOMK, the leak is mostly a problem with releasing resources on GUI application exit. Console apps are fine (for the most part). So if it's not doing anything else, it'll run for extended periods.

Just checked one of them, after 22 days of uptime, 88% 88% 97% resources free, and memory in use is about where it was on bootup.

---

Did not see this question, so here goes, how many can run graphics....

---

BOINC Wiki

Did not see this question, so here goes, how many can run graphics....

I can ...

https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=52067

Anders n

---

Win98 has a vmem system that's as robust as 2K & XP, so despite it's other problems as an OS, it'll swap to disk just fine.

yes, it takes full advantage of the VM facilities Intel designed into the 386 - VM is the one thing that Win-95 got right. Pity MS didn't think thru the rest of multi-threading / multi-tasking at that time.

FWIW, I'm using it on those boxes because it has a lower overall memory footprint than 2K, and hence way lower than XP.

Yes, where amount of RAM is an issue, Win-98 is way smallest -- apart from win95 which usually can't run all the drivers you want...

Tho if you don't want a GUI, you can run command-linux in much less still ;-)

Win98 has a vmem system that's as robust as 2K & XP, so despite it's other problems as an OS, it'll swap to disk just fine.

yes, it takes full advantage of the VM facilities Intel designed into the 386 - VM is the one thing that Win-95 got right. Pity MS didn't think thru the rest of multi-threading / multi-tasking at that time.

Thread hijack alert!

Ahh - the checkered history of Windows.

Suffice it to say that I believe (and have reasonable grounds to back that belief), that as early as 1997, MS realised that Win95 and its descendents were a dead end. When you consider that even ME required the video miniport equivalent to be a 16 bit VxD, you begin to get the idea. Hence the reason they devoted minimum time to that family.

NT 3.51 was arguably the best OS that MS released, from an internals approach because it used the four rings of the X86 correctly: drivers ran at ring 1, not ring 0 where they do in NT4 and later. The fact that drivers run at ring 0 is a major weakness in NT4 et al, because it means one rogue driver can take the OS with it if it crashes. That was not the case in NT 3.51. A driver crash could well cost you the device till you rebooted, but the remainder of the OS could continue to function.

Funny how VMS did it this way, as did NT 3.51. Go find out about Dave Cutler for details. :)

---

Thread hijack alert!

Funny how VMS did it this way, as did NT 3.51. Go find out about Dave Cutler for details. :)

And again...

This was done to increase apparent performance. As usual, Microsoft compromises quality for marketing glitz ... though "faster", it was, and still is, much less stable than it should be for this very reason.

Certification of the drivers is a work-around for a mistake in the basic design of the operating system.

Sadly, CPU performance and GPUs made the need for this compromise moot in less than a year ...

---

This was done to increase apparent performance. As usual, Microsoft compromises quality for marketing glitz ... though "faster", it was, and still is, much less stable than it should be for this very reason.

Quoted for truth.

I have wondered what it would take to get MS to reconsider this, and start looking again at the NT 3.51 microkernel architecture again.

---