• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

RAM vs CPU upgrade

Started by os2monkey, 2012.04.18, 07:24:56

Previous topic - Next topic

os2monkey

I have a ThinkCentre 8215 with a Celeron D 2.6GHZ w/ 1GB RAM with ECS 2.1.

The system works fine but i've noticed web browser rendering sometimes seems to lag. (I have a clone of the same system running XP pro and it seems to browse the web faster)

It would be pretty cheap (like $5) to upgrade to a pentium 4 HT, which would increase the bus speed from 533mhz to 800mhz, and allow support for acpi.

The other alternative is for me to upgrade the ram to 2 gb or 4gb, although it looks like ddr2 ram has become pretty pricey these days. (between $20-50)

So i'm tempted to try just the cpu considering how cheap it is - but i've read that firefox uses a lot of ram so not sure if maybe I would be wasting my time if ram is likely the issue.

So what do you guys think :)? Should 1gb be enough ram for web browsing?


DougB

QuoteShould 1gb be enough ram for web browsing?

Yes. I have a couple of systems with more than 1 GB, but the only time I ever see them use more than 1 GB is when I run a virtual machine, with lots of memory allocated. I also use a 256 meg cache for my JFS drives, and that is included. What you probably should do, is get a monitor to watch your swap file growth. I suspect that it rarely grows, but if it does, increase the swapper parameters to make the file a little larger than the biggest it ever expands to. That, at least, prevents the need to shrink it again, when the extra space is no longer required. Go to HOBBES, and search for SWAP MONITOR. You will find a couple that should work.

hobbes.nmsu.edu/

There are a couple of possibilities. One is the video driver. I don't know if SNAP will run in accelerated mode, but if it will, you should be using SNAP. If SNAP runs in VESA mode, it will be very slow, and you would probably get better performance from PANORAMA, with the buffer enabled, but that is not as fast as SNAP in accelerated mode. I expect that windows drivers will run in accelerated mode, and that may be why you see a difference.

I am not sure how much difference the processor will make. I do know that the CELERON processors are not very efficient at processing graphics, and the web has a lot of graphics. For $5 I think I would give a better processor a try. The problem could be to get the old processor out, without damaging anything.

I think your main problem is the video driver, and a faster processor will probably help a little, but it won't make a lot of difference.

os2monkey

Quote from: DougB on 2012.04.18, 08:39:57

There are a couple of possibilities. One is the video driver. I don't know if SNAP will run in accelerated mode, but if it will, you should be using SNAP. If SNAP runs in VESA mode, it will be very slow, and you would probably get better performance from PANORAMA, with the buffer enabled, but that is not as fast as SNAP in accelerated mode. I expect that windows drivers will run in accelerated mode, and that may be why you see a difference.


Hi Doug,

Thanks for the insight.
I am running snap drivers right now, but not sure how to know if it's running accelerated or not - any idea how I can find that info?
I picked snap over panorama since snap supported all the refresh rates on my monitor.

os2monkey

I just found under the snap folder there is a "hardware report" program. I ran it and it generated this:
Manufacturer:    Intel
Chipset:         i945G
Memory:          7872 Kb
DAC:             Intel Integrated DAC
Clock:           Intel Integrated Clock
Driver Revision: 3.2, Build 29
Driver Build:    Jul 31 2006

Not sure if anyone would know if that chipset should support accelerated?

DougB

QuoteI am running snap drivers right now, but not sure how to know if it's running accelerated or not - any idea how I can find that info?

Go to System Setup-> Screen and it should tell you in the Display Info section.

QuoteChipset:         i945G

Because of that, I expect that you will find that it is using VESA VBE 2.0 mode, which is slow.

You can switch to Panorama by using the Local System-> Install/Remove-> Video Driver Wizard. Be sure to turn on the buffer, if it isn't done automatically. I have seen the wizard fail to set the Panorama logo, where the SNAP logo is, in the Screen object. That is not a real problem, and can be fixed, if you can find the right program to run (I wouldn't worry about it).

FWIW, I use SNAP on my desktop system, even though it is slow, because Doodle's Screen Saver will not turn off the DVI attached screen if I use Panorama. Of course, I could just use the power button on the screen, if speed was important to me.

melf

Doug, according to the SNAP readme i945G is supported:

//--- Intel i740, i740 PCI, i810, i810/DC100, i810e, i815, i845G, i865G.
Intel i852/i855 GM/GME, i915G/GV, i915GM/GMS, i945G, i945GM ---//

/M
/Mikael

os2monkey

Acceleration support is on.
I was able to find it by going to command prompt, changing to the c:\snap folder, and then running the command gaoption show.
And it then gives you a huge list of the supported features:
Prefer 32 bit per pixel.. On
  Compressed Framebuffer... On
  Allow DDC BIOS........... On
  PCI bus mastering........ On
  Video memory packets..... On
  Hardware acceleration.... Full
  Multi Head Display....... Off
  VESA DPVL Mode........... Off

Global options for all devices:

  Force VBE Fallback ...... Off
  Force VGA Fallback ...... Off
  Allow non-certified ..... Off
  Disable write combining . Off
  Use BIOS for LCD panel... Auto
  Video Memory Limit....... Off
  Shared AGP memory size... 4096 Kb
  Use system memory driver. Off
  Disable DDC detection.... Off
  Enable AGP FastWrite..... Off
  Maximum AGP data rate.... 8X
  Virtual Display.......... Off


So anyways.. maybe I will try the cpu upgrade. I'm assuming if I upgrade the cpu the OS will be able to detect the change without reinstalling?
I wouldn't want to reinstall the OS.. Last time I upgraded a cpu on a windows XP machine it was able to detect the change automatically.

Thanks again everyone.

DougB

QuoteEnable AGP FastWrite..... Off

You might try turning that on. I don't remember the exact command, but it is in the SNAP docs, somewhere.

QuoteI'm assuming if I upgrade the cpu the OS will be able to detect the change without reinstalling?

I can't think of any reason why it would have a problem, but it is probably a good idea to have a good backup of the system, before trying it. You may also want to do some benchmarking, before and after, to see how much difference the new processor makes. SysBench is probably a good one:

hobbes.nmsu.edu/download/pub/os2/util/benchmark/sysb095c.zip

The results could be interesting, so be sure to post them.

os2monkey

Benchmarking does sound like a fun idea to see the real difference. I'll totally post the before after results :).

RobertM

#9
Some added notes:

My experience with the OS/2 browsers also would indicate that on systems with 1GB or more RAM, video card/drivers are the more important factor. Even with slower video cards, but with drivers working in accelerated mode, the browsers are far faster than on machines with faster cards in non accelerated mode. Now, at 768MB, things seem to start to crawl for some reason on my systems. Though, at 1GB, if, like me, you have both a large JFS *and* HPFS386 cache, the browser can be somewhat slow due to too little physical RAM left.

For server systems running native OS/2 apps and server daemons, such as Lotus Domino GoWebserver and Peter Moylan's FTPD, various Rexx cgi scripts, as well as a few Linux ports like MySQL, I have found that the amount of memory and CPU/core quantity is far more important than actual CPU speed. OS/2 really seems to like multiple CPUs and enough memory to handle numerous threads and processes across them. The same seems to apply to running very CPU intensive tasks - such as running multiple large FFMPEG transcoding processes. I'd definitely rather take two or four slower CPUs over one faster one.

As an example, I'd expect from my experiences, that if I was running say four transcodes simultaneously on the quad 550MHz and simultaneously on a single core 2.2GHz machine, the quad 550Mhz would beat it by a noticeable margin. And along this vein, OS/2 on such a machine *CRUSHES* a single core 2.2GHz Windows machine running the same build number of FFMPEG - but then again, we all know that the Windows threading, process and SMP scheduling mechanism is just the tiniest step up from "broken and useless".

As another example, I have used a quad 550MHz system with 4GB of RAM to create blazingly fast results while running Domino GoWebserver, MySQL, Rexx (for cgi stuff, such as calling/using MySQL to create dynamic web pages based off the content of decently large database tables), and FTPD. Of this sort of activity, the only things that seemed to suffer to some extent were the stuff that required intensive calculations.

Now, oddly, using an ancient S3 Trio video card (and the accelerated drivers that came with WSeB), Firefox loads and responds FAAAAR quicker on that machine than it does on my 1.2GHz single core/CPU, 1.2GB AMD Athlon based system (it uses an ATI Radeon 9250 with SNAP for video support).




Thus, it seems there are multiple roads to create the desired solution. Though... in note on the above, in the case of the quad 550MHz machine, I am not sure what is providing the big performance increase... the RAM? the amount of CPUs? Both are running the video cards in accelerated mode I believe - but the Athlon system has a far faster CPU an entire generation newer than the Pentium III Xeons in the quad CPU machine. And both have over a gig of memory.

Unless the video card support is horrendous (for those situations where screen output is important the the apps running - such as with a browser), the biggest advantage I've always seen in any OS/2 setup where a decent number of threads and processes that require decent amounts of CPU use, seems to always be (a) the number of CPUs or true cores, and (b) the hardware (and it running in SMP mode) being properly supported by OS/2 or eComStation.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


os2monkey

Wow Robert - Lots of good info there. Thanks.
The cpu i'm upgrading to supports hyper-threading but is only one real core, so i'm not sure if that is going to help much - but it will increase the bus speed & provide a bigger l2 cache.

Here is the benchmark I ran on my current celeron d- and i'll post the benchmark on my new cpu when I get it.

Sysbench 0.9.5c result file created Wed Apr 18 15:12:04 2012

Machine name       - Celeron D 2.6GHZ
Manufacturer       - IBM ThinkCentre 8215-A1U
Motherboard        - IBM ThinkCentre 8215-A1U
Chipset            - Intel Corporation - 82945G Processor to I/O Controller
Processor          - Intel model f49 found (not in cpu table) with MMX
External cache     - 16Kb internal instruction cache, 0Kb internal data cache
Graphics card      - Intel Corporation - 82945G Integrated Graphics Controller
Storage Controller - Intel Corporation - 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller
Storage Controller - Intel Corporation - 82801GB/GR/GH (ICH7 Family) Serial ATA Storage Controller
Machine data
Coprocessor        = Yes
Processors         = 1
RAM                = 1013.17 MB

Operating System data
OS/2 version       = 20.45
CSDLevel           = XR0C004_
FIXLevel           = Unknown
Revision number    = 14.097
Priority           = Dynamic
Maxwait            = 1
Timeslice          = (32,32)
Protectonly        = NO
Swap file size     = 2.00MB
  ...initially     = 2.00MB

Video data
Resolution         = 800x600x16 bits/pixel
Number planes      = 0
Screen Access      = Direct
Bank Switched      = No
Bytes/scanline     = 1600
Aperture size      = 1048576
Manufact. code     = 32902
Chipset code       = 10098

Graphics
   BitBlt S->S copy      :     1050.005    Million pixels/second
   BitBlt M->S copy      :      475.224    Million pixels/second
   Filled Rectangle      :     6084.763    Million pixels/second
   Pattern Fill          :     6084.308    Million pixels/second
   Vertical Lines        :       34.713    Million pixels/second
   Horizontal Lines      :      554.655    Million pixels/second
   Diagonal Lines        :       30.340    Million pixels/second
   Text Render           :      539.889    Million pixels/second
   -----------------------------------------------------------------------
   Total                 :      525.622    PM-Graphics-marks

CPU integer
   Dhrystone             :     2553.500    VAX 11/780 MIPS equivalent
   Hanoi                 :     1689.000    moves/25 microseconds
   Heapsort              :      885.700    Million Instructions Per Second
   Sieve                 :     1124.700    Million Instructions Per Second
   -----------------------------------------------------------------------
   Total                 :     1763.772    CPU integer-marks

CPU float
   Linpack               :      199.600    MFLOPS
   Flops                 :      558.100    MFLOPS
   Fast Fourier Transfrm :      174.080    VAX FFT's
   -----------------------------------------------------------------------
   Total                 :      119.972    CPU floating point-marks

Direct Interface to video extensions - DIVE
   Video bus bandwidth   :     1466.978    Megabytes/second
   DIVE fun              :     4139.827    fps normalised to 640x480x256
   M->S, DD,   1.00:1    :     5009.107    fps normalised to 640x480x256
   -----------------------------------------------------------------------
   Total                 :     1811.463    DIVE-marks

File I/O - Drive C:
   4Kb seq.   Uncached w :    13310.718    Kilobytes/second
   4Kb seq.   Uncached r :    41652.839    Kilobytes/second
   4Kb random Uncached w :     1164.673    Kilobytes/second
   4Kb random Uncached r :      821.436    Kilobytes/second
   4Kb seq.   Cached   w :    70787.649    Kilobytes/second
   4Kb seq.   Cached   r :    35978.336    Kilobytes/second
   4Kb random Cached   w :     4066.788    Kilobytes/second
   4Kb random Cached   r :      468.845    Kilobytes/second
   8Kb seq.   Uncached w :    27277.669    Kilobytes/second
   8Kb seq.   Uncached r :    52837.172    Kilobytes/second
   8Kb random Uncached w :     2330.947    Kilobytes/second
   8Kb random Uncached r :     1190.293    Kilobytes/second
   8Kb seq.   Cached   w :    57429.321    Kilobytes/second
   8Kb seq.   Cached   r :    36236.217    Kilobytes/second
   8Kb random Cached   w :     3933.750    Kilobytes/second
   8Kb random Cached   r :     1350.551    Kilobytes/second
   16K seq.   Uncached w :    32913.760    Kilobytes/second
   16K seq.   Uncached r :    70615.883    Kilobytes/second
   16K random Uncached w :     4030.815    Kilobytes/second
   16K random Uncached r :     2168.189    Kilobytes/second
   16K seq.   Cached   w :    70218.133    Kilobytes/second
   16K seq.   Cached   r :    36341.589    Kilobytes/second
   16K random Cached   w :     9843.824    Kilobytes/second
   16K random Cached   r :     2091.073    Kilobytes/second
   32K seq.   Uncached w :    56221.186    Kilobytes/second
   32K seq.   Uncached r :    70596.643    Kilobytes/second
   32K random Uncached w :     7934.493    Kilobytes/second
   32K random Uncached r :     4580.384    Kilobytes/second
   32K seq.   Cached   w :    70351.194    Kilobytes/second
   32K seq.   Cached   r :    48745.621    Kilobytes/second
   32K random Cached   w :    13798.661    Kilobytes/second
   32K random Cached   r :     4659.228    Kilobytes/second
   64K seq.   Uncached w :    61810.560    Kilobytes/second
   64K seq.   Uncached r :    70297.067    Kilobytes/second
   64K random Uncached w :    12213.575    Kilobytes/second
   64K random Uncached r :     8445.075    Kilobytes/second
   64K seq.   Cached   w :    69102.749    Kilobytes/second
   64K seq.   Cached   r :    42030.690    Kilobytes/second
   64K random Cached   w :    22013.786    Kilobytes/second
   64K random Cached   r :     8666.712    Kilobytes/second
   -----------------------------------------------------------------------
   Total                 :    28763.202    File I/O-marks

Memory
   5    kB copy          :     7396.968    Megabytes/second
   10   kB copy          :     7983.248    Megabytes/second
   20   kB copy          :     7238.889    Megabytes/second
   40   kB copy          :     7042.285    Megabytes/second
   80   kB copy          :     7174.005    Megabytes/second
   160  kB copy          :     4401.406    Megabytes/second
   320  kB copy          :     1679.824    Megabytes/second
   640  kB copy          :     1008.681    Megabytes/second
   1280 kB copy          :     1031.302    Megabytes/second
   5    kB read          :     8242.499    Megabytes/second
   10   kB read          :     8350.863    Megabytes/second
   20   kB read          :     4913.521    Megabytes/second
   40   kB read          :     5079.646    Megabytes/second
   80   kB read          :     5060.817    Megabytes/second
   160  kB read          :     4355.099    Megabytes/second
   320  kB read          :     3454.977    Megabytes/second
   640  kB read          :     3155.511    Megabytes/second
   1280 kB read          :     3153.333    Megabytes/second
   5    kB write         :     5264.695    Megabytes/second
   10   kB write         :     5298.985    Megabytes/second
   20   kB write         :     5294.234    Megabytes/second
   40   kB write         :     5233.454    Megabytes/second
   80   kB write         :     5248.536    Megabytes/second
   160  kB write         :     3867.531    Megabytes/second
   320  kB write         :     1769.341    Megabytes/second
   640  kB write         :     1491.700    Megabytes/second
   1280 kB write         :     1497.871    Megabytes/second
   -----------------------------------------------------------------------
   Total                 :     5217.752    M
emory-marks

RobertM

I haven't found hyperthreading to be of any noticeable advantage. Some have reported it can actually be detrimental in systems running highly threaded apps. I'd suspect both such experiences are based on how OS/2 itself, as well as native highly threaded apps handle their threads - they need the true ability for possibly very diverse threads from the same app to run truly concurrently for there to be an advantage. It might be helpful with some of the Windows ports though.

As for bus speed, it is an advantage with anything that requires large data moves across the bus or to/from the CPU (or lots of little transfers of that type, or heavy disk access where the bus speed is a bottleneck - which in your case, it should not be), but for many things, it wont cause a drastic improvement except for benchmarking.


|
|
Kirk's 5 Year Mission Continues at:
Star Trek New Voyages
|
|


DougB

QuoteVideo data
Resolution         = 800x600x16 bits/pixel
Number planes      = 0
Screen Access      = Direct
Bank Switched      = No
Bytes/scanline     = 1600
Aperture size      = 1048576
Manufact. code     = 32902
Chipset code       = 10098

I question why you are using 800x600 resolution. I suspect it is because you only have 1 meg allocated for the video RAM (Aperture size). There should be a way (probably in the BIOS) to increase that to 8 meg (at least 4 meg). That should allow you to have better resolution (match it to the monitor), and should help with performance. Again, windows might do that with the driver, which may be one reason why you see better performance.

QuoteI haven't found hyperthreading to be of any noticeable advantage.

I don't see it making any difference, at all, on my Lenovo ThinkPad T510 (Intel dual core I5), with eCS. It does seem to improve the performance of Win7. Windows is not good at multithreading, so it helps to use the Hyperthreading feature. OS/2 is much better at that, so Hyperthreading doesn't make much difference. In fact, with a single processor, it probably has a lot more overhead to dispatch two processors than to work with one. (Hyperthreading makes the processor look like a dual core, so it can queue up work to be done, then switch the processor to the second thread to do it). One other difference, is that the processor cache needs to be synchronized between the two (effective) processors, and that is also overhead that isn't needed in a single processor machine.

The rest of the data looks pretty respectable.

One bit of, very simplified, explanation that might give you some idea about what is happening:

A CELERON processor is what is known as a Reduced Instruction Set Computer (RISC). That means that it doesn't have the internal smarts that a Full Instruction Set Computer (FISC) has. One of the main differences is that a FISC computer, when told to multiply two numbers, does that in one step. A RISC computer will add the number to itself, as many times as necessary to get the right answer (I told you it is very simplified). Since a program like a browser uses a lot of heavy duty calculations, you can notice a difference.

IBManners

Hi Doug,

I think your having a senior moment :)

QuoteA CELERON processor is what is known as a Reduced Instruction Set Computer (RISC). That means that it doesn't have the internal smarts that a Full Instruction Set Computer (FISC) has. One of the main differences is that a FISC computer, when told to multiply two numbers, does that in one step. A RISC computer will add the number to itself, as many times as necessary to get the right answer (I told you it is very simplified). Since a program like a browser uses a lot of heavy duty calculations, you can notice a difference.

A Celeron is a CISC (Complex Instruction Set Computing), the same as any other x86 line of CPU's from Intel/AMD etc. RISC (Reduced Instruction Set Computing) is a chip such as the IBM PowerPC etc. Totally different beasts.

http://en.wikipedia.org/wiki/Complex_instruction_set_computing

Cheers
Ian
I am the computer, it is me.

os2monkey

Quote from: DougB on 2012.04.19, 19:45:50


I question why you are using 800x600 resolution. I suspect it is because you only have 1 meg allocated for the video RAM (Aperture size). There should be a way (probably in the BIOS) to increase that to 8 meg (at least 4 meg). That should allow you to have better resolution (match it to the monitor), and should help with performance. Again, windows might do that with the driver, which may be one reason why you see better performance.

Just find it much easier on my eyes to use 800x600 when working :).. on my 17" monitor.
Thanks for the video ram advice, i'll look into that.