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?
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/ (http://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.
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.
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?
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.
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
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.
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 (http://hobbes.nmsu.edu/download/pub/os2/util/benchmark/sysb095c.zip)
The results could be interesting, so be sure to post them.
Benchmarking does sound like a fun idea to see the real difference. I'll totally post the before after results :).
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.
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 Memory-marks
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.
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.
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
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.
Quotethe same as any other x86 line of CPU's from Intel/AMD etc.
Well, no it isn't. That is why they are cheaper, and slower. (Duron is the AMD equivalent). Newer Celeron, and Duron, processors have added in some of the performance parts of the more capable chips, just to try to take some market share, but they still don't have all of the performance enhancements of their big brothers.
QuoteJust find it much easier on my eyes to use 800x600 when working Smiley.. on my 17" monitor.
There are many reasons to want larger text, or icons, etc. It is a bad misconception that running at 800x600 (especially on a 17 inch monitor) is easier on the eyes. If you want larger text, icons, etc. you should use a higher resolution, then set eCS to use larger icons etc. Look up "Controlling the Size of Fonts and Icons" in the SNAPOS2.PDF document. I expect that Panorama doesn't know about those things, but it may have something similar.
Quote from: DougB on 2012.04.19, 19:45:50
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).
I just booted into bios, and under video ram it is set for 8meg.. so i'm not sure why it's just reporting 1 under the benchmark, unless there is some ECS specific setting I need to find.
Quotei'm not sure why it's just reporting 1 under the benchmark
It could be because you are using 800x600x16 resolution.
Your right.
I just realized I had my monitor setup to only have 64k colors under 800x600. I set it to 16M and then ran the benchmark test again and it then showed 2mb video ram.
I then switched to 1024x768 and ran the benchmark again and then it reported 4mb.
So why do lower resolutions not access more video ram?
I'm not sure if I am imagining it but it does seem much faster, even with just the 2MB under 800x600.
Quote from: os2monkey on 2012.04.20, 08:22:49
....
So why do lower resolutions not access more video ram?
...
You need 800x600x16 bits (65536 colors) which is about 960kByte. Just below 1MByte. But usually with acceleration video memory is double buffered so you would need 2MByte for this setting. No need and no benefit with more than 2MByte video RAM with OS/2 - eCS. Of course other video drivers on other OSes do benefit from more RAM in special cases...