It could be that by chance the modules that you took out were bad. If you had a memory tester available it would tell you. You'd be surprised at how much memory tests bad straight from a company. We have two memory testers where I work and we routinely sent back 1/4 of our memory modules soon after receiving them. (until we started buying from Crucial) Just because memory is recognized by the BIOS doesn't mean it's good memory.
I did test out the memory. Not with a hardware memory tester, but with AmiDiag 6. It was the only tester that I had avail. But the mem checked out fine. I did not see any probs with the mem.
Every IT, or techie, should have a mem tester. It will save alot of time and headaches (as far as troubleshooting, not RMA's).
Every IT, or techie, should have a mem tester. It will save alot of time and headaches (as far as troubleshooting, not RMA's).
well I won't say you're Wrong shadow, if cutting the memory in half stopped your crashing, then it stopped your crashing, I can't argue with that, but I have seen lots of Win9x machines run just fine with over 128MB of RAM.
Is it true that having 288mb of ram for win98 is a waste? I guess I should format my computer with install win2k ...... Btw, anyonw know is my p2-266 with 288mb ram good enough to handle win2k pro?
BFG10K
Lifer
- Aug 14, 2000
- 22,709
- 2,971
- 126
I read several posts here that Windows 9x/ME somehow has "trouble" accessing more than 128 MB and runs "worse" when you have more. That is utter BS. The Win 9x/ME memory manager isn't as good as Win NT/2K but it's still pretty good. I have a 192 MB machine and it runs *sweet*. If you had 4 DIMMs each filled with a stick of 256 MB, Windows would have no trouble accessing all 1 Gig of RAM you have.
However, there is an issue with having a large disk cache (>512 MB) in combination with a large AGP aperture grille size (ie greater than 128 MB). To get around this problem you can either limit your AGP size to less than 128 MB or limit your disk cache size to less than 512 MB.
However, there is an issue with having a large disk cache (>512 MB) in combination with a large AGP aperture grille size (ie greater than 128 MB). To get around this problem you can either limit your AGP size to less than 128 MB or limit your disk cache size to less than 512 MB.
<< Is it true that having 288mb of ram for win98 is a waste? I guess I should format my computer with install win2k ...... Btw, anyonw know is my p2-266 with 288mb ram good enough to handle win2k pro? >>
It depends. If you enjoy having a very speedy system with quick response time and enjoy running programs out of the disk cache as you progress during the day, it's not a waste. Win2000 will run as fast as 98 on that comp with that much RAM. However, do check your hardware against the HCL before upgrading.
Get 2000 and slam it on your machine. I was surprised to learn how off Microsoft was with it's recommendation about this OS. I'm running it on a quasi Emachine and it runs fine. I found drivers for hardware even though the company was out of business. This thing is two years old and it works good accept a few minor glitches that I have now fixed. It is alot more stable than 98 but I would upgrade your CPU to 400+ if your motherboard can handle it.
I hope Whistler will be even better !
I hope Whistler will be even better !
I'm running 640MB on Win98SE on an Abit KT7-RAID. Works perfectly fine (but it does require some tweaking which I'll post below), though Win2k would probably manage the memory more efficiently, but Win2k is more work than is worth it to me.
Win95A Retail version, the first version ever sold, DID have a problem with more than 64MB of memory, unrelated to motherboard caching. This was fixed, though I don't know how you'd tell if you have that version other than knowing you bought the retail version right from the start.
After that, Win95 and Win98 and Win98SE can use any amount of memory up to 2GB (though 4GB can be installed and work, Win9x can only address 2GB). That is from the Knowledge Base article Q181594. The Knowledge Base article linked in badthad's post, Q184447, seems somewhat contradictory, though. This is perhaps a bug that only occurs in some cases. There is also a known bug when using more than 512MB of memory, but it can be worked around by a small modification in the system.ini file.
The MS Knowledge Base article Q253912 describes what it is and how to get around it. Anybody that has set their VCACHE minimum and maximum before has already done what's needed to work around it, however you probably set those amounts based on your lower amount of memory. If you upgrade to higher than 512MB you MUST modify the VCACHE min and max, and since you've got that much RAM, you can set them pretty high. I have mine at 32MB/64MB. The problem results from the way Windows addresses the VCACHE. With more than 512MB of RAM, it runs out of virtual memory addresses, so you have to limit how much virtual cache it tries to use. If you read the article you'll see several ways of getting around the limitation. Why anybody would chose a total limitation to how much memory Windows can address, instead of just tweaking the VCACHE, is totally beyond me. Why install so much more RAM without using it?
On the subject of motherboard cache support: With the exception of the HX chipset, Intel Socket7 chipsets were only able to cache a MAXIMUM of 64MB of RAM. This included all Pentium Chipsets (VX, TX, FX) except the HX. HX by default could cache 64MB, but with an upgrade to the TAG RAM could cache up to 512MB.
SuperSocket7 chipsets from VIA, ALi, and SiS, could cache higher amounts, dependent on how much TAG RAM was installed (which usually came with the cache chips. For instance, my EPoX MVP3G-5 with 2MB of cache could cache up to 512MB in write through mode or 256MB in write-back mode. The 1MB cache model could only cache half those amounts (the write through and write back modes were auto-set based on how much memory you had, so that it would cache as much as possible; write back is faster, but if it wasn't cacheing the memory above 256MB then it would make the system slower). So a SS7 chipset with only 512K cache will probably only be able to cache 64MB in write-back mode, and 128MB in write-through mode.
Windows uses memory from the upper memory addresses down. UNIX variants (including Linux) use memory from the bottom up. Cacheing is done on memory from the bottom up. So with a 64MB cacheable limit, and 128MB of memory, only the lower half of the memory is cached, but Windows starts using the upper half of the memory first. Only after it has filled more than 64MB does caching start, and it will still only cache the data that goes into the lower 64MB block. Therefore Windows loses a huge amount of performance if you install memory beyond the cacheable limit, but it is NOT due to Windows not being able to use the memory, it is due to a chipset cache limitation and the WAY Windows uses memory overall.
Newer chipsets, for PII/III, Celeron and Duron/Athlon, do not affect the cache directly at all, since it is integrated either onto the chip die or the processor package PCB, and the processor has an integrated cache controller. I haven't gotten a definitive answer, but it seems to be understood that there is no longer a cache limitation up to the amount of memory that an x86 processor can address, which is 4GB. Therefore UNIX variants would have no problems with any amount of memory you installed, up to whatever the chipset supports (1.5GB for Athlon chipsets, 512MB for i81x chipsets). But Windows9x is still maximum limited to 2GB (which of course can't be reached with current consumer chipsets), and to 512MB if you don't tweak the system.ini file.
Win95A Retail version, the first version ever sold, DID have a problem with more than 64MB of memory, unrelated to motherboard caching. This was fixed, though I don't know how you'd tell if you have that version other than knowing you bought the retail version right from the start.
After that, Win95 and Win98 and Win98SE can use any amount of memory up to 2GB (though 4GB can be installed and work, Win9x can only address 2GB). That is from the Knowledge Base article Q181594. The Knowledge Base article linked in badthad's post, Q184447, seems somewhat contradictory, though. This is perhaps a bug that only occurs in some cases. There is also a known bug when using more than 512MB of memory, but it can be worked around by a small modification in the system.ini file.
The MS Knowledge Base article Q253912 describes what it is and how to get around it. Anybody that has set their VCACHE minimum and maximum before has already done what's needed to work around it, however you probably set those amounts based on your lower amount of memory. If you upgrade to higher than 512MB you MUST modify the VCACHE min and max, and since you've got that much RAM, you can set them pretty high. I have mine at 32MB/64MB. The problem results from the way Windows addresses the VCACHE. With more than 512MB of RAM, it runs out of virtual memory addresses, so you have to limit how much virtual cache it tries to use. If you read the article you'll see several ways of getting around the limitation. Why anybody would chose a total limitation to how much memory Windows can address, instead of just tweaking the VCACHE, is totally beyond me. Why install so much more RAM without using it?
On the subject of motherboard cache support: With the exception of the HX chipset, Intel Socket7 chipsets were only able to cache a MAXIMUM of 64MB of RAM. This included all Pentium Chipsets (VX, TX, FX) except the HX. HX by default could cache 64MB, but with an upgrade to the TAG RAM could cache up to 512MB.
SuperSocket7 chipsets from VIA, ALi, and SiS, could cache higher amounts, dependent on how much TAG RAM was installed (which usually came with the cache chips. For instance, my EPoX MVP3G-5 with 2MB of cache could cache up to 512MB in write through mode or 256MB in write-back mode. The 1MB cache model could only cache half those amounts (the write through and write back modes were auto-set based on how much memory you had, so that it would cache as much as possible; write back is faster, but if it wasn't cacheing the memory above 256MB then it would make the system slower). So a SS7 chipset with only 512K cache will probably only be able to cache 64MB in write-back mode, and 128MB in write-through mode.
Windows uses memory from the upper memory addresses down. UNIX variants (including Linux) use memory from the bottom up. Cacheing is done on memory from the bottom up. So with a 64MB cacheable limit, and 128MB of memory, only the lower half of the memory is cached, but Windows starts using the upper half of the memory first. Only after it has filled more than 64MB does caching start, and it will still only cache the data that goes into the lower 64MB block. Therefore Windows loses a huge amount of performance if you install memory beyond the cacheable limit, but it is NOT due to Windows not being able to use the memory, it is due to a chipset cache limitation and the WAY Windows uses memory overall.
Newer chipsets, for PII/III, Celeron and Duron/Athlon, do not affect the cache directly at all, since it is integrated either onto the chip die or the processor package PCB, and the processor has an integrated cache controller. I haven't gotten a definitive answer, but it seems to be understood that there is no longer a cache limitation up to the amount of memory that an x86 processor can address, which is 4GB. Therefore UNIX variants would have no problems with any amount of memory you installed, up to whatever the chipset supports (1.5GB for Athlon chipsets, 512MB for i81x chipsets). But Windows9x is still maximum limited to 2GB (which of course can't be reached with current consumer chipsets), and to 512MB if you don't tweak the system.ini file.
Win98SE is perfectly functional when it isn't preinstalled by morons (or installed by morons at home, either way). My system only goes down when I'm adding hardware or loading new drivers. I rarely have to reboot for any instability reasons, and they're usually caused by some bad application that decides to lock up a piece of hardware.
My NT4 system at work on the other hand is slow and tends to lock up on a regular basis.
My NT4 system at work on the other hand is slow and tends to lock up on a regular basis.
Lord Evermore - Nice discussion. I can't seem to find any info on optimal Vcache settings. It seems to me that, if you have a large amount of ram, it would be better to set Vcache fairly BIG, i.e. >128MB. This should cut down disk activity, speeding performance.
For anyone that doubts the theoretical RAM limit of Win9x being 2GB:
MS KB
For anyone that doubts the theoretical RAM limit of Win9x being 2GB:
MS KB
BFG10K
Lifer
- Aug 14, 2000
- 22,709
- 2,971
- 126
I'm glad we got that "512 MB limit" crap sorted out. I'm sick of the cliche bashing Windows 98 SE receives, and it's usually by the people who don't have a clue what they are on about.
As for stability, it isn't as good as Windows NT/2000 but it's still damn good. My system only crashes around once every ~3 weeks, which is pretty good for a consumer OS.
As for stability, it isn't as good as Windows NT/2000 but it's still damn good. My system only crashes around once every ~3 weeks, which is pretty good for a consumer OS.
Yea, I hear ya BFG. This thread is not meant to extoll the virtues of Win2k, I know it's good, I run it on my server. I would appreciate it if people would STOP with the comments about win2k in this thread. If you have meaningful comments about increasing memory performance in the win9x kernel, bring 'em on.
I'm still searching for info on how to best set the Vcache in win98....and I'm not really looking for opinions. I want some HARD proof in the form of links to legit websites or benchmark testing you may have done.
I'm still searching for info on how to best set the Vcache in win98....and I'm not really looking for opinions. I want some HARD proof in the form of links to legit websites or benchmark testing you may have done.
This has nothing to do with the OS, but sometimes two different modules with different CAS latencies seem to cause trouble. I had a super 7 board with 64Meg of CAS 3, added another 64 of CAS 2. I didn't alter the BIOS settings at all. For the next three weeks I got blue screen crashes almost every day. I swapped out the other module and had all CAS 2 and the crashes immediately stopped. Whether this was a BIOS problem, sparked by serial presence detect, or an OS-generated memory management problem I don't know. I assumed it was all about the spd and the timings.
Hi guys....Just my 2 cents.
I have 98se on one of my pcs,
Asus P2B (bx chipset, duh.)
P2-350 (392)
3 sticks of PC-133 2-2-2 (mb is full)
fbs is 112 (hence the 392)
I have a separate 1gb drive for virtual memroy
(mostly for burning cds as there is no fragmentation
and I don't need to access my main drive at the same time)
No crashes for many months now....
(unless I try to get 133fbs on this ol' cpu)
Take it for what it's worth....
I have 98se on one of my pcs,
Asus P2B (bx chipset, duh.)
P2-350 (392)
3 sticks of PC-133 2-2-2 (mb is full)
fbs is 112 (hence the 392)
I have a separate 1gb drive for virtual memroy
(mostly for burning cds as there is no fragmentation
and I don't need to access my main drive at the same time)
No crashes for many months now....
(unless I try to get 133fbs on this ol' cpu)
Take it for what it's worth....
TRENDING THREADS
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 10K
-
Discussion Speculation: Zen 4 (EPYC 4 "Genoa", Ryzen 7000, etc.)- Started by Vattila
- Replies: 13K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 7K
Facebook
Twitter