> Win98SE Dell PII 333 256 Megs memory
>
> BOINC Beta Version 4.05 loaded 3-4 hours ago.
> Crunched 1 of 8 wu's, It will not upload.
> Keeps retrying.
>
> That's it.


CONGRATULATIONS! YOU'VE POSTED THE 100TH POST ON THIS THREAD!

GOOD JOB! AND NOW FOR YOUR PRIZE! A PIECE OF ADVICE FROM YOUR FRIEND PYROFOX!!


WAAAAAAAAHOOOOOOOOOOOOOOOOOOOOOOOOOO!!!

K3UZZ - disable boinc network access (file -> disable BOINC netowrk access)
it won't try to connect to the server, and it won't crash! (for THAT reason anyway...)


I thought we could use some enlightenment :D

KEEP FIXING AND CRUNCHING OR WHATEVER YOU DO BEST!!
THE COMMUNITY LIVES ON FOREVER!!
(raises and waves BOINC flag)


-Fox
[/url]

I'm not sure if this information will help solve the perticular issue this
thread refers to, but it is worth mentioning. When we work on Win98/Win98SE
machines at the shop, we always tweak the config.sys file to make sure that
there is a large enough operating environment for MOST programs to run. The
standard config.sys file should look like this:

DEVICE=C:[WINDOWS]HIMEM.SYS
DEVICE=C:[WINDOWS]EMM386.EXE NOEMS
DOS=HIGH
FILES=60
BUFFERS=30,0
STACKS=9,256
DOS=UMB
FCBS=16,0

Substitute [] with backslashes!

Win98/Win98SE does not put these in by default, though SOME pre-installed
Windows installations from Dell/Gateway/Compaq/HP have these entries. Either
way, make sure that you put DOS=HIGH and DOS=UMB on seperate lines, not
a single line such as DOS=HIGH,AUTO,UMB or DOS=HIGH,UMB. For some reason
Windows can get a little flakey and unstable if this is done. Regardless
of what some people say about the "built in" memory management features
of Win98/Win98SE, these lines in your config.sys file WILL increase
stability and performance.

Then check your virtual memory settings and make sure that you set the minimum
size for your swap file to between 128 megs and 256 megs (provided you have
enough free space on your hard drive). This will also help out your stability
and performance. We also typically change the file system from "Desktop
Computer" to "Network Server", as it also seems to boost performance when
reading and writing to the hard drive. I hope this information helps, and
good luck to you all...

Regards, Daniel.

My experience is different:

After suffering a very-slow-lockup on my WIN-ME system, I did a hard, power cycle, reboot.

I then disabled the BOINC network access per the suggestion and went to bed.

This morning when I checked the system was nearly locked up (the cursor would respond to general movement after several seconds, but was not controllable).

The SETI 4.03 process was indicating 99.98% complete.

I had to do a power-cycle reboot and am now running SETI Classic on the box.

SETI 4.03 continues to run fine on a couple of XP systems.

If somebody can tell me something specific to do, I can try BOINC again on the WIN-ME box in order to help trouble-shoot the process. Be advised my completion time on this boxs is a little over 6 hours, so feed back will be slow.

<a> [/url]

> Win98/Win98SE does not put these in by default,

Nope, because they're only required for old DOS programme compatability.
You don't need a Config.sys or an Autoexec.bat file at all; they are only required to keep old programmes happy, or support extremely old hardware that doesn't have a suitable Windows driver.


> Regardless
> of what some people say about the "built in" memory management features
> of Win98/Win98SE, these lines in your config.sys file WILL increase
> stability and performance.

Personally i've found they have no effect at all unless you're running very old software.


> Then check your virtual memory settings and make sure that you set the
> minimum size for your swap file to between 128 megs and 256 megs (provided you have
> enough free space on your hard drive). This will also help out your stability and performance.

I've found it's best to set the minimum & maximum size to the same value- it stops fragmentation of the swapfile & Windows doesn't waste time resizing it as it thinks necessary.
It won't have any effect on stability but it does give a slight performance improvement.

If you've got plenty of RAM, you can disable virtual memory completely; although some softwae can spit the dummy at this as it expects there to be virtual memory, even if it doesn't actually need to use it.

> Okay, if an effort to try and narrow down the cause could somebody try adding
> this tag to the account_setiathome.berkeley.edu.xml file between the project
> preferences tag:
>
> [leave_apps_in_memory/]
>
> NOTE: the [] need to be changed to less than, greater than marks.
>
> What does BOINC do after you start it back up?
>
> ----- Rom
> BOINC Development Team, U.C. Berkeley
I added the tag to the file, rebooted, and went to bed. When I retuned to the machine it was very slow, but was able to C-A-D to see that BOINC was not responding. (Took a long time to get the systems attention, and then another long wait for it to actually close the program) System clock was stopped at 2:56. When I restarted S@H just the normal screen appeared with no additional information. The system clock reset itself after reboot to the correct time (9:32). It did keep trying to send the result and kept timing out.

S@H is the only project that I'm running on this machine. Also, failed to mention that I'm using ZoneAlarm and McAfee. When I look @ ZoneAlarm I see that BOINC_gui is listening to port(s) TCP:31416. Everything appears fine as long as I disable BOINC network access.

I tried to calculate the workunits I've stored. So I disabled the BOINC networkacces, and what happens?

-- The system hang's / chrash's / slow down again! --

In this case with BSOD!

So i make a hardreset and wait for some help by a workaround...or a patch!

> Nope, because they're only required for old DOS programme compatability.
> You don't need a Config.sys or an Autoexec.bat file at all; they are only
> required to keep old programmes happy, or support extremely old hardware that
> doesn't have a suitable Windows driver.

Not entirely true. Win95, Win98, and WinME run on top of DOS, just like old Win 3.1 did! (No matter how much MS liked to make people think that DOS was gone, it really wasn't!) In order to get entirely away from Dos you have to go with WinNT, Win2k, or WinXP.

After reading through all these threads, and knowing how bad Win9x memory management is, I keep wondering if this is some memory leak in the program, resulting in the OS crash. Perhaps some Windows network driver is having a memory conflict with BOINC that accelerates this problem? Wouldn't be the first time that there was a driver-app conflict on a system.

Also, the info Walt Gribben threw out at 31 Aug 2004 10:26:11 UTC looks interesting.

(I wish I could play with this problem, but I reformatted my old Win98 system a year ago and installed Linux on it ;) )

I've installed BOINC 4.05 on 3 Win98SE machines at my office yesterday(. Two of them hangs(AMD Athlon 2500+ 256 MB RAM and Celeron 1.7GHz 256 MB RAM), but third one goes smoothly(PIII 566MHz 128 MB RAM).
I must investigate configuration of this machine tomorrow to see what makes it to work anyway.

Best regards

Another piece of wood to the flames ...

In my PC running 98SE what seems to happen is that after a few minutes running (around half an hour), even with the network access disabled, suddenly, the SETI client closes and after that the machine starts getting slower and slower but never stops responding.

I'm always able to C+A+D and kill the "boinc_gui" and after that the machine resumes normal function.

Hope it helps.

I tried to reconstruct on my machine what has happened before after I installed V4.05 on the oldest machine I have P450 - WinMe (rans fine upto then).
I uninstalled BOINC and did a systemcheck with Norton Systemworks. After that I checked the drives, no flaws.
I downloaded BOINC anew from the website, everything went smooth and I let it crunch for several hours, again no problems...
When I rightclicked under the Tab Projects to Update (probably at a moment the the server was down) the program went berserk and could only be stopped via Ctrl-Alt-DEl and killing the process.
Hence again I did start up the program, problems did get worse because the program was still trying to make connection to update (forced update)...
Things got worse and I could reproduce the erratic and very slowed down functioning of the mouse. It took me much longer to get the system out of hibernation this time. Now I stopped experimenting because I wouldnot be forced to do a hard reset with possibility to have disk damage and lost clusters...

Hoping this could help to find the culprit,
(By the way no problems on the XP machines)

Greetings from Belgium ;-))

> I'm leaving BOINC alone methinks - just have 3 Predictor WUs left to finish.
> SETI is too unstable to run it as my sole project. I need Predictor as a
> backup and there's no knowing when it will convert to v4.

Predictor is in the process of upgrading right now...

but i think THE question is why computers hangs under ver 4.05 of BOINC and not under ver 3.20???
what are the difference beetween those 2 versions???

> Not entirely true. Win95, Win98, and WinME run on top of DOS, ...

Generally true, but WinME tore out a lot more of the DOS support, somewhat crippling it. Some old DOS stuff doesn't run well in WinME for that reason.

> but i think THE question is why computers hangs under ver 4.05 of BOINC and
> not under ver 3.20???
> what are the difference beetween those 2 versions???

my wild guess is that Win98 just isn't that great for running multithreaded & multiproc apps, and WinME was little better. Stuff like W2K & XP, which are based from NT, seem to be more stable. Since BOINC 4 adds a lot of preemptive task switching etc, that probably isn't as "friendly" for 98/ME. If you look at the Windows API help library, it seems like half the "fun stuff" (i.e. process/thread calls) isn't available for 98/ME.

> but i think THE question is why computers hangs under ver 4.05 of BOINC and
> not under ver 3.20???
> what are the difference beetween those 2 versions???
>
>

As has been mentioned before...I had problems with 3,02...just not bad enough to mention. I am on vacation this week so have not down loaded 4.05.

My symptoms with 3.02 under 98SE were that when the GUI was trying to communicate it mwould hang...usually just BOINC would not respond. I also noticed the problem when the benchmarks were running. I would just wait for it to quit and then either go online and let it connect, or if the servers were down I would disable network access, and there would be no problem.

Don

CPU type GenuineIntel Pentium
Number of CPUs 1
Operating System Microsoft Windows 98 SE, (04.10.2222.00)
Memory 127.46 MB
Cache 976.56 KB
Swap space 1920.54 MB
Total disk space 9.76 GB
Free Disk Space 6.35 GB

This is a very old machine I use at work,
when I start B4.05 to run CPDN it slows to
a crawl, the mouse becomes very slow etc...
when I force a manual update...it freezes.
ctrl+alt+del does not even kill it, must
reboot. I unistalled B4.05 today. I recall
when running B4 the day of the transition
strange happenings when downloading seti wu's,
they were no good, error messages flying out of
the window....so I killed it...
@home have the PC sliced, one side XP the other
Fedora, using *nix to crunch seti, other than
the problems with the project itself the client
runs smoothly with Fedora Core 1....just FYI hoping
to help.
Xi3 Chongqing,China

I updated to BOINC 4.05 and Seti@home 4.03 and it started to download workunits. But when the downloads finished, in the work-tab it still said: Busy downloading at all the work-units!

> This problem starts because the BOINC client sits at a HLT instruction.
> Apparently from either a corrupted return address or bad branch. At least
> thats what it shows very early in the process.
>
> The "HLT" instruction is part of a call, compare, call sequence in shmem.c:
>
> >0045179A call dword ptr ds:[54163Ch]
> >004517A0 cmp esi,esp
> >004517A2 call 0047FB20
>
> The first call is to CreateFileMapping, which should return to the next
> instruction at 0x004517a0. Instead its sitting at 0x004517a1, the second byte
> of that compare instruction, which just happens to be a HLT.
>
> Just a guess here, but it probably goes thru this code when starting a new
> workunit, and for an "update".

Okay, so between the 3.22 branch and the 4.x branch we changed how the shared memory management was initialized. Namely we go looking for a shared memory segement name that is not already in use.

The function in question is in app_start.C in the 4.x branch called
write_app_init_file()

In the 3.x branch it is in app.C.

Both make a call into shmem.C calling create_shmem() which was changed to account for the new behavior.

Time to hit the KB and see if there was any bugs reported around CreateFileMapping on the 9x platform.

My first instinct is to move the SECURITY_ATTRIBUTES from being in the stack to the heap.

----- Rom
BOINC Development Team, U.C. Berkeley

> I updated to BOINC 4.05 and Seti@home 4.03 and it started to download
> workunits. But when the downloads finished, in the work-tab it still said:
> Busy downloading at all the work-units!
>
>
>
>

I had the same problem yesterday when the client was unable to download the PDB file. See here for more details

I have two win98se machines, w/ updates. One is a pIII450 and the other a celeron633. I have experienced most of the same problems with slow downs till hard boot neccessary, and the gui faults which require hard boot.

Through my snooping around and tryin to figure out whats doing it, I have found a way to keep both machines crunching away, which may be of assistance to those who are troubleshooting this problem.

It seemed the problem was when the client is trying to reach the server, so I just pulled out my network cable from the hub and restarted boinc. Now its crunching the current work unit with no problems. This was the PIII, and it did manage to finish a wu last night, but hung after upload when it went to start the next wu. This morning all it needed was to be rebooted, and its crunching again.

The Celery633 had two completed wu's in que for upload, but as it tries to upload, its bogs and if not shut down will fault requiring the hard boot. I tried the same trick to pull the network cable, and restart, and it began to crunch the next wu. Its still trying to get through to the sever to upload the finish wu's, but with the cable pulled it cant find hostname.....etc.

So I thought it was just something to do with talking with the server, but as the Celery633 finished another wu, still with cable pulled, it crashed as it went to start the new wu. Hard booted and its crunching again, but now 3 wu's trying to upload. Finished the next wu, and same scenario, Hard Boot...etc

I now have 4wu's ready for upload and its crunching on the next. As I type this, I've just plugged in the network cable to see what happens when the clock runs down for the next upload retry in a few seconds. Wow, it uploaded that wu! The next one is set to retry in 43mins, I wonder if I should click the retry now? are ya feeling lucky punk?

Well, that might not have been the best thing to do! Its hanging, but so far it wont need a hard boot, I can still end task, but I'm giving it some time to see if it will crash hard.

After five mins, still hanging, ctr alt del, end task. Restart boinc, its crunchin again. Next upload retry's in 23 mins, 27mins, and 2:47mins. I dont think I'll re-test the retry now feature! Hopefully it will count down and upload. I guess my thinking now is, as long as the server is up and responding, it may just upload and continue.

In about an hour the PIII will finish its wu, and I'll report what happens to it when it tries to start a new wu