Author Topic: JFS cache sizing, and system "speed-up"  (Read 5021 times)

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1130
  • Karma: +24/-0
    • View Profile
JFS cache sizing, and system "speed-up"
« on: October 21, 2021, 05:43:04 pm »
Alright, so for what it's worth, I had recently made some changes to the JFS cache sizes and thought I would share my results.

8Gig machine here, at bootup 4Gig is used for a RAM drive, the remaining is seen by OS/2 as workable memory. Not all of it, but you know the standard limitations that apply.

OK, so I've had my VIRTUALADDRESSLIMIT=3072 setup in CONFIG.SYS for quite some time, and utilized a JFS cache of 256M. Seemed to work fine, no issues. Keep in mind the underlying disk is a SSD (Samsung 850Evo).

Given the above hardware details and my application use/mix I have consistently found that at least 1.5Gig of that upper memory would regularly go un-used. It would simply sit there and if anything, it was always the Shared Memory that would get exhausted first. So that got me thinking: cache is cache, and so if the RAM is there, why not make better use of the darn thing?  ;)

If you see what ther other OSes are running, the cache sizes are typically much larger.

So off I went experimenting a little bit:

1) bump the cache up to 512M, set VIRTUALADDRESSLIMIT=2048, but I kept the MIN and MAX buffer settings the same as with the prior smaller cache, that being:

G:\OS2\CACHEJFS.EXE /LW:8,30,6 /MINBUFFER:4000 /MAXBUFFER:21000

Umm...nice, system just seems faster...apps respond quicker. Obviously not on the first attempt, but openning OO the 2nd and 3rd and 4th time is faster.

2) now since I freed up some upper memory due to the VIRTUALADDRESSLIMIT change why not go bigger (or go home, as the saying goes...LOL), so I bumped the cache up to 768M

Following this change I started to see a weird 'stagger' in the system...went back to some published/presentation notes on the JFS and realized that I was saturating the cache and pretty much exhausting the free buffer space, so I implemented the following:

G:\OS2\CACHEJFS.EXE /LW:8,30,6 /MINBUFFER:16000 /MAXBUFFER:84000

...basically I increased my MIN and MAX buffer sizes by a factor of 4.

Those system 'staggers' I mentioned above appear to be gone now. The apps are loading consistently faster, on multiple attempts.

All in all, tripling the JFS cache has provided for a good positive result.

Of course not everyone will be able to max out on their JFS cache this way, and even if you have the room your apps may limit you to how much of that upper memory can be utilized for cache itself.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1548
  • Karma: +4/-2
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #1 on: October 21, 2021, 07:16:45 pm »
Quote
OK, so I've had my VIRTUALADDRESSLIMIT=3072 setup in CONFIG.SYS for quite some time, and utilized a JFS cache of 256M. Seemed to work fine, no issues. Keep in mind the underlying disk is a SSD (Samsung 850Evo).

Personally, I always use VAL=2560, which seems to be a sweet spot, for my usage. At least two of my systems get very unstable if I use more than 2900 (and don't run very long, if I go to 3000). I do monitor the available lower, and upper, private, and shared, memory (using Above512, and a logging script). I find that the lowest I ever get with upper shared memory, is somewhere in the 800K range. Lower shared memory does get down to the 35K range (when I run VBox), but most of the time, it is above 100K. When it does get below 100K, I try to prevent further programs from running, because it sometimes does go to zero, with bad results (it seems that some programs never check to see if they got lower shared memory, before they try to use it, and then they can't recover). Of course, I do use HIGHMEM to set as much as possible to use high shared memory. I find that it is necessary to run HIGHMEM again, after some updates. It doesn't always find something that got changed, but sometimes it does.

For those who don't know, VAL has absolutely nothing to do with available real memory. I use VAL=2560 on my antique ThinkPad, which only has 256 Mb of real memory. What it seems to do, is increase the amount of upper shared memory, that is available.

I find it interesting, that private memory (upper, or lower) rarely changes value. Almost everything allocates shared memory, but that could be because Above512 is lying to me.

Quote
So off I went experimenting a little bit:

Been there, done some of it. I usually use JFS cache at 132K (on machines with more than 1 GB of real memory), which seems to be a bit of a sweet spot (64K, or 10% of real memory, is default). Using more tended to end up not helping much (it has been a few years since I tried that), and I found that the systems became somewhat less stable. Usually the problem was an unexplained hang, although I seem to be able to reproduce a similar problem by writing huge (20 GB on JFS) files to USB devices (JFS), while using the default cache size.

I never played with buffer sizes, and cache size doesn't seem to matter if it is using a spinning disk, or a SSD. A SSD, of course, has no seek time, or spin, delay, so it is faster.

I gave up using HPFS, years ago, because the HPFS cache goes into lower shared memory, which is already in very short supply. JFS does have other, significant, advantages over HPFS.

Quote
The apps are loading consistently faster, on multiple attempts.

A lot of that "improvement" depends on timing. If the program parts have not been flushed from the cache, the load time is faster (even when using a small cache). Using a larger cache does increase the probability that most of it will still be there, but it depends on what you do between starts.

Quote
Obviously not on the first attempt, but openning OO the 2nd and 3rd and 4th time is faster.

If you are using the AOO QuickStart feature, that may be what you are seeing. From what I see, QuickStart keeps parts of the program available in memory, after you close it, but it looks, to me, like the first program load still needs to load everything. QuickStart does work around DLL unload problems when using upper shared memory, without the kernel fixes that ArcaOS has.

FWIW, I have turned off all Lazy Write settings (FAT32, and JFS). That doesn't seem to affect system response much, but it does seem to make the system less likely to hang, especially when writing large files to USB.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1130
  • Karma: +24/-0
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #2 on: October 21, 2021, 09:58:16 pm »
Hi Doug,

...
Quote
The apps are loading consistently faster, on multiple attempts.

A lot of that "improvement" depends on timing. If the program parts have not been flushed from the cache, the load time is faster (even when using a small cache). Using a larger cache does increase the probability that most of it will still be there, but it depends on what you do between starts...

So this point here is actually the crux of what I was trying to improve upon.

Consider a set of applications that you normally run, in my case that normally is a mix of:

1) FF
2) Thunderbird
3) Lotus 1-2-3
4) AOO
5) VSE & IBMCPP & GCC (compilation)
6) PMView

Therefore, by increasing the size of the cache (if the upper memory is rarely used otherwise) allows me to try to pull in more of that working set into the cache, and hopefully convert that into a quicker responding system.

In my case, that appears to have been the result of tripling the size of the cache, with the matching increase in the buffer settings.

Of course that that not mean ALL of these apps and their data (heck, FF has a 512M disk cache) are always there, the cache will of course always continue to be shuffled around as needed.

roberto

  • Hero Member
  • *****
  • Posts: 649
  • Karma: +2/-0
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #3 on: October 28, 2021, 06:55:06 pm »
Hello
I'm doing cache testing lately. With interesting results. But the difference with you is that I am testing with this:
rem DISKCACHE=D,LW
DISKCACHE=4096000,LW

swappath=c:\ 0 4096


saludos

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1548
  • Karma: +4/-2
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #4 on: October 28, 2021, 08:24:45 pm »
Hello
I'm doing cache testing lately. With interesting results. But the difference with you is that I am testing with this:
rem DISKCACHE=D,LW
DISKCACHE=4096000,LW

swappath=c:\ 0 4096


saludos

Uhmm. That is totally wrong. From Help DISKCACHE:
Code: [Select]
DISKCACHE Command: n Parameter

Specifies a number from 48 through 14400 that indicates the number of 1024-byte blocks (or 1KB blocks) of storage to be used for control information and programs in the disk cache buffer. The default value is d, which is set during installation and based upon the amount of system memory. You can reset this value to a numerical value.

To set your disk cache size to 128KB, type the following in the CONFIG.SYS file:

DISKCACHE=128
The n parameter is what you say is "4096000". So, 14400 is maximum. If your number works, at all, it is only because it wraps to a smaller number, somewhere between 48 an 14400.

DISKCACHE is for FAT anyway, so it is probably not, at all, helpful to play with the default.

roberto

  • Hero Member
  • *****
  • Posts: 649
  • Karma: +2/-0
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #5 on: October 28, 2021, 09:25:14 pm »
You are right in everything, but my question is have you tried it?
As you said, it affects fat
I have tried to copy a folder with usb 2.0 to fat32 and it took me 24 minutes at 1120 bps fc 2.40 and to a usb 3.0 with the same card it takes 33 minutes at 780 bps

saludos

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1548
  • Karma: +4/-2
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #6 on: October 29, 2021, 02:44:05 am »
FAT is not FAT32. They are different drivers, with different parameters, and different cache. Using incorrect cache size probably just uses the default size, but it could also just drop the higher bits, and use whatever is left over. If that turns out to be something usable, it will likely work.

No, I haven't tried it. I no longer use FAT, except for the ArcaOS USB stick installer. Working with USB is affected by far too many outside factors, to even consider doing a copy to test speed. Do it 1,000 times, after rebooting each time, with consistent results, and I may find a reason to try it.

Roderick Klein

  • Sr. Member
  • ****
  • Posts: 498
  • Karma: +14/-0
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #7 on: October 29, 2021, 01:06:28 pm »
Hi Doug,

...
Quote
The apps are loading consistently faster, on multiple attempts.

A lot of that "improvement" depends on timing. If the program parts have not been flushed from the cache, the load time is faster (even when using a small cache). Using a larger cache does increase the probability that most of it will still be there, but it depends on what you do between starts...

So this point here is actually the crux of what I was trying to improve upon.

Consider a set of applications that you normally run, in my case that normally is a mix of:

1) FF
2) Thunderbird
3) Lotus 1-2-3
4) AOO
5) VSE & IBMCPP & GCC (compilation)
6) PMView

Therefore, by increasing the size of the cache (if the upper memory is rarely used otherwise) allows me to try to pull in more of that working set into the cache, and hopefully convert that into a quicker responding system.

In my case, that appears to have been the result of tripling the size of the cache, with the matching increase in the buffer settings.

Of course that that not mean ALL of these apps and their data (heck, FF has a 512M disk cache) are always there, the cache will of course always continue to be shuffled around as needed.

Why is standard Sysbench not sufficient ? Its much more consistant. It tests small file I/O large file I/O.  Also it measures the timing very accurate!

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1130
  • Karma: +24/-0
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #8 on: October 29, 2021, 03:34:13 pm »
Hi Roderick,

Why is standard Sysbench not sufficient ? Its much more consistant. It tests small file I/O large file I/O.  Also it measures the timing very accurate!

...because SysBench and diskio measure the raw speed of the hardware and mostly bypass the cache I believe (there is a single cache/bus xfer test in both).

So the attempt here is to optimize the 'runtime' environment by balancing the raw speed of the storage device (that being a SSD in my case) with the system resources (4Gig of RAM) in order to avoid a constant storage device seek for the pertinent data (increasing the cache should allow the most recently used stuff to be available much quicker).

In other words: it's not about sheer performance, rather it's about how all the various controls available to us can produce better application performance.

roberto

  • Hero Member
  • *****
  • Posts: 649
  • Karma: +2/-0
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #9 on: October 30, 2021, 05:14:51 pm »
Do it 1,000 times, after rebooting each time, with consistent results, and I may find a reason to try it.
You will have to wait about six months for me to try it a thousand times, but for everyone else I leave you a file with instructions on how you can make it consistent each boot.

-Dariusz I agree 100% with your comments from the sysbench ...

saludos

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3635
  • Karma: +77/-0
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #10 on: October 30, 2021, 06:24:24 pm »
Hi Roderick,

Why is standard Sysbench not sufficient ? Its much more consistant. It tests small file I/O large file I/O.  Also it measures the timing very accurate!

...because SysBench and diskio measure the raw speed of the hardware and mostly bypass the cache I believe (there is a single cache/bus xfer test in both).

So the attempt here is to optimize the 'runtime' environment by balancing the raw speed of the storage device (that being a SSD in my case) with the system resources (4Gig of RAM) in order to avoid a constant storage device seek for the pertinent data (increasing the cache should allow the most recently used stuff to be available much quicker).

In other words: it's not about sheer performance, rather it's about how all the various controls available to us can produce better application performance.

The file IO speeds should show the file systems speed as well as making it obvious when there are increased cache misses ,at least if they tested large enough files.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1548
  • Karma: +4/-2
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #11 on: October 30, 2021, 07:08:14 pm »
Quote
In other words: it's not about sheer performance, rather it's about how all the various controls available to us can produce better application performance.

There are a lot of things, that can affect application performance. Most of them make so little difference that they are not possible to measure. For instance, it takes less time to repaint the desktop, if it is a single, solid, color, than if it is a complicated pattern (like a photo). A small picture paints faster than a large picture. A large screen resolution takes more time, than a small screen resolution. Two screens take a lot longer than one screen. This becomes much more obvious, if you are using a program, like VNC,  to operate another computer over the internet.

You can also position data on your disk, so it is easier to get to it (more effective on a spinning disk, than a SSD). The outer edge of the disk spins faster than the inner edge (modern disks take advantage of that, so it doesn't make as much difference). Once you get there, the data transfer is a little faster (although modern disks also use internal cache, so it probably doesn't make any difference, as long as it is enabled).  File fragmentation also enters this equation.

If you use a RAMDISK, it is faster to read/write directly, than to need two steps to write to cache, then to the program. This may also apply to devices like NVME drives.

Various formats operate at different speeds. FAT is probably the fastest. FAT32 is likely the slowest (not counting optical devices). Enabling Lazy Write (all formats) often slows it down, especially when the cache fills up. Of course, each format has it's own uses.

Eliminating background processes can speed things up, until you need one of them.

There are many more things that can affect application performance. One, that most people forget about, is that it takes a lot longer to run a program, when something crashes, and you need to restart the program, or, worse, reboot the computer. Overall stability is one of the most important performance considerations. I always found that making the cache size too big, contributes to instability.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 3635
  • Karma: +77/-0
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #12 on: October 31, 2021, 01:56:43 am »
Various formats operate at different speeds. FAT is probably the fastest. FAT32 is likely the slowest (not counting optical devices). Enabling Lazy Write (all formats) often slows it down, especially when the cache fills up. Of course, each format has it's own uses.

Err, FAT is often slow and in theory FAT32 should be about the same speed as they both use similar structures. My phone is blazing fast at writing and reading a FAT32 stick whereas OS/2 is amazingly slow. The big problems with FAT and FAT32 is fragmentation and the fact that the FAT and directory structure are at the beginning of the disk.
OS/2 is a faster DOS and Windows mostly due to HPFS (and now JFS) which lays out the disk structure in a much better way, both use extents so files are stored as one or 2 continuous groups of sectors, assuming little fragmentation, disk directories in the middle of the disk and arranged as a B-Tree which at least HPFS also optimizes in the background. And even the HPFS cache was much better then the FAT cache.
In comparisons of Linux file systems, JFS scores pretty good as an all around file system. Of course Linux (and even Windows now) have dynamic caches so what memory you are not using is used as a cache.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1548
  • Karma: +4/-2
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #13 on: November 01, 2021, 08:25:47 pm »
Quote
so I bumped the cache up to 768M

Since I haven't tried this, for a long time, I decided to give it a shot. How did you get it to take 768m (I would assume that you used 768000 (K) as the cache size. When I try that, CACHEJFS shows me:
Cache Size:  131072 kbytes
which I believe is the allowed max now.

Quote
/MINBUFFER:16000 /MAXBUFFER:84000

Did you find a description of what these actually do? I have run out of places to look, and can't find anything.

Andreas Schnellbacher

  • Hero Member
  • *****
  • Posts: 783
  • Karma: +13/-0
    • View Profile
Re: JFS cache sizing, and system "speed-up"
« Reply #14 on: November 01, 2021, 08:50:38 pm »
Yes, 'M' stands for mega, 'k' for Kilo, but 'm' for milli. See https://en.wikipedia.org/wiki/Unit_prefix.