Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Dariusz Piatkowski

Pages: 1 2 [3] 4 5 ... 72
Hardware / Re: Using a LaserJet 2100m on a Print Server
« on: November 30, 2021, 05:03:37 am »
Hey Mark!

...I've had for years a LaserJet 2100m which I want to set up on a D-Link DPR-1260 Print Server. I already have an HP Color LaserJet 3500 attached and printing nicely, using CUPS but am having trouble setting up and printing to the LaserJet 2100.

Just because I was familiar with it I've set up my printers in the past using the LPD protocol. One day I plan to play around with IPP, but that's for another day, unless the solution may lie there.

The printer was originally used connected directly to one of my towers, and has an external parallel port built in. I've got a Parallel Port to USB adapter attaching the printer to the Print Server. With the printer turned on and addressing the IP address for the Print Server ( on my network) I reach the print server and get the output which I attached below (Dlink Screen.JPG).

As the USB Port (#4) reports an unknown printer, I'm not sure if thats related to the age of the printer, or whether the printer is just not communicating. I was thinking of trying to ping the printer on my network, but its been quite a while since I did that - if someone can jog my memory as to what I need to enter to undertake that it would be appreciated (I assume Print Server IP address, but also need to know what syntax to use to add the Port address)...

So what I'm thinking is that your D-Link Print Server should be exposing the attached printers through some kind of interface that differentiates the printers from each other. By the looks of it, that difference is the port# that the printer is going to respond on.

My Brother has a NIC with a print server built in, which means that my OS/2 setup is using a SLPR port driver to point to the printer's IP address (which would be your D-Link Printer Server IP address I believe) and a specific interface, which in the attached photo is the 'LPD printer' field, and for you that is probably going to be the printer's port number.

In my case I'm using the BINARY_P1 service of Brother's built-in print server.

Worst case, given that your D-Link Printer Server is at, you could point the SLPR port driver to and perhaps look to see what service names (if any) are exposed and can be used in the 'LPD printer' field.

Multimedia / Re: How do I change this default behaviour?
« on: November 29, 2021, 04:34:11 pm »
Hi Lars,

...Anyway, the "default" MM device for some given file type/file extension is defined through MMPM2.INI. And unfortunately, that "device" has to be an MCI device which essentially boils down to being a DLL with a defined entry point and command support. Certainly not any arbitrary EXE file. It would be possible to "wrap" invocation of an EXE file as a MCI device but this has to be implemented...

OK, good pointer. I found the following sections in MMPM2.INI file:

Code: [Select]
 PRODUCTINFO=Software Motion Video
 EATYPES=Digital Video
 ALIASNAME=DigitalVideo Player

...therefore, the 'Digitalvideo' definition (see below section) clearly points to the above 'Software Motion Video' and 'OpenMPEG Video' as the providers of that playback functionality (at least as best as I can interpret this).

Further on, the following is defined in the 'Drivers' section:

Code: [Select]

Therefore, the IBMDIGVIDPLAYER01 & IBMMPEGPLAYER01 are the pertinent sections, where the 'MCDDRIVER=' field in both cases appears to point to a matching DLL file in the \MMOS2\DLL path.

Beyond this, the contents of MMPMMMIO.INI spell out the actual installed & registered details.

I am fairly certain that both of these are part of the default OS/2 MM install though, so I suppose one could try the official un-install process, although I'm worried that would remove far too much of that multimedia functionality.

Based on the feedback you provided I went looking through 'Multimedia Subsystem Programming Guide' (part of the OS/2 Toolkit), and under the 'Installation Requirements' one will find 'Installing an I/O Procedure' section. Of course that will simply update the MMPMMMIO.INI file, but it still needs the DLL itself that would allow a re-mapping of various file extensions to a user-defined program.

Taking the example of the AVI IOProc from above, so the SVMC.DLL file, I find the following procedures being exported:

Code: [Select]
Procedures Exported by Ordinal:
    0 @#IBM:14.075#@
    1 mciDriverEntry

Therefore, I'm curious if one was to:
1) build such a DLL that would re-map the call to a mplayer.exe (or a user defined EXE for that matter), would it be sufficient to define in that DLL the matching mciDriverEntry procedure?

2) once that procedure is created, would it simply call the EXE from there?

I feel like the above is a terrible oversimplification, but heck, that's all I know at the moment! LOL

Multimedia / Re: How do I change this default behaviour?
« on: November 28, 2021, 06:23:21 pm »
Hi mauro,
Hi Dariusz, I had simply changed the default application for opening my media files using Assoedit (see images).

Yeah, I thought that doing this should take precedence over anything else, but in my case that is not the outcome. I suspect it is because of the MM file classes, but that's a standard OS/2 MM install and I figured basically everyone else out there would be impacted by this, unless I have of course installed something else in the past that I have simply forgotten about since then!

Multimedia / Re: How do I change this default behaviour?
« on: November 28, 2021, 06:21:37 pm »
Hi Pete!

...The cwmm MediaFolder help file - usually at [BootDrive]:\MMOS2\MEDIAFLD\DOC\mediafldr.inf provides an answer if using smplayer or vlc. See the section Hidden Features, Replace AVI Player as an example. Not sure if it can be tweaked to use mplayer without a frontend though...

Ahh, so these are the Chris W's MM classes I think, which I do not have installed on my machine, so that option is not currently available. Not to say I won't pursue it, just that it's not the setup I have deployed at the moment.

Multimedia / Re: How do I change this default behaviour?
« on: November 28, 2021, 06:18:42 pm »
Hi Martin,
I don't think it is good to deregister any class for what you want to do?

When you right click over the AVI or MPG file, and select "Open as", which options do you see?...

I agree, I do not want to de-register any classes, unless there is a single AVI/MPG specific class that will NOT impact anything else. By the looks of it so far, these both appear to be default OS/2 multimedia classes though, and for that reason I think it's best that I do not touch them.

Take a look at the attached screenshot for what "Open as" looks like. Basically all my other video apps show, along with the default OS/2 ones.

I can certainly force each AVI file to open using mplayer, but that requires me to open it's Settings and specifically select mplayer, as opposed to relying on normal OS/2 associations.

Regarding the "Associations Set Up" docs...very nice!!! I am aware of all of these options and have already tried them, but that's a great write-up for anyone that's not had the chance to work through these in the past.

Multimedia / How do I change this default behaviour?
« on: November 27, 2021, 08:44:49 pm »
So I've got a bunch of AVI and MPG video files: family get-togethers, various car events, etc. My box currently insist on always opening the AVI and MPG stuff using the ancient default OS/2 AVI player. How the heck do I change that?

Before you say "adjust the associations", well they already have been. All of these media files are pointing to mplayer as the default, and yet each time I double-click on a AVI file the default viewer plays.

So I'm thinking that's because the 'Current class' is defined as MMAVI for the the AVI files and MMMPG for the MPG files. Meanwhile the MP4 stuff is simply showing up as XFldDataFile (which is to be expected given my XWP install).

Do I need to un-register a particular class?

Take a look at what currently shows up under 'Codecs' TAB of the Multimedia object (see attachment).

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 26, 2021, 07:11:36 pm »
Hi Doug,

...I did up my cache to 256000, on my main machine. It created the cache, but then Firefox won't start, complaining that XUL is defective. I put it back to 132000 and it is working.

Then, I have been playing with LW, MIN and MAX buffers. That is possibly making some difference. I will know more on Monday morning, when I do my backups. There is an indication that the single processor machine doesn't like it much, so that will go back to what it was (the LW part anyway).

Is XUL marked to load high? Otherwise the only follow-up is to see if it's been LXLITE compressed? (not sure if DLLs get processed by LXLITE, I think they do...?)

Re: LW, MIN and MAX, same here. As I change these I continue to log to see they impact these are having.

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 26, 2021, 07:04:56 pm »
My ramdisk does persist over warm reboots (last computer, it even persisted over a couple of seconds of no power) and every time the browser crashes, which is too often lately, the whole cache gets invalidated. ya! My machine does not retain the ramdisk contents, I had originally tried to do what you are talking about becuase I rarely actually physically shut OFF the machine. Instead it's almost always a re-boot.

...As for Thunderbird, I'd think the cache is mostly used when displaying web pages, which it is quite capable of doing. I even have an add-on, thunderbrowse, which exposes displaying web pages.
For SM, you can point the cache in the Preferences under Advanced-->Cache. I assume that for TB, you have to open the Options-->Advanced-->Config Editor and create the same preference as for Firefox.

Well, it didn't take long for me to read up on the TB specifics. The FF parameter setting is exactly what TB works with. I initially shifted my TB cache to the ramdisk, but then noticed something, see further details below...

Now there is something that seems different, although maybe that's just because I previously did NOT pay attention to it: in TB each time I click on a different folder I now have the clock icon pop up for just a couple of seconds. I honestly do NOT remember seeing this before, and of course I have no idea if this is a result of moving the cache to the ramdisk.

So to test this out, I've actually gone back to a DISK based cache, will give it a few days worth of use and see if that's what causing it.

Each time the clock icon pops up I do see TCPIP TB is certainly fetching something. Haven't captured that and pumped it through Wireshark yet to see what it's actually doing, but I suspect it's going to the server to read something.

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 26, 2021, 03:08:30 pm »
Hi Dave!

For the Mozilla cache, I use the ramdisk, fairly easy to setup with SM. For Firefox need to use about:config to create preference something like this (H: is my ramdisk) "browser.cache.disk.parent_directory;H:\mozilla\firefox"

Hmm, from my perspective I'm not sure what the longer-term performance gain would be in terms of doing a FF ramdisk cache, after all I would want the cache to persist in order to speed up the load of the bigger sized web page elements the very next time they are requested. I suppose if you want to keep the profile clean (and smaller sized), and do not care to carry over the cache past any re-boot, that would do it.


...for the Thunderbird client that is absolutely what i'm going to take a look at. I see no point in keeping that cache persistent since emails will always change, and I would think that causes the normal disk cache to just fill up with stuff that rarely ever gets re-used, with the exception of very few standard emails: bills from the same companies, etc.

I do not have SM installed here so I'm not sure what you mean by "fairly easy to set up", but would that still hold true for TB? If so, can you point me in the right direction before I attempt to create that FF-like preference?

In the meantime I'm off to research the TB cache settings a bit...


Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 25, 2021, 06:35:45 pm »
Here are the Theseus metrics from a Clean Boot (so basically a re-boot with my default application/utility mix: UPS stuff, Xit, XWP, etc...none of the other major apps):

1) System => Nonswappable Memory

Code: [Select]
Nonswappable Memory analysis:
Apps & DLLs      = 00024000 ->     144K -> 0.141M
Process overhead = 0025B000 ->    2412K -> 2.355M
DD allocated     = 45615000 -> 1136724K -> 1110.082M
DOS              = 0001E000 ->     120K -> 0.117M
VDisk            = 00000000 ->       0K -> 0.000M
File system      = 00030000 ->     192K -> 0.188M
Kernel code      = 000B3000 ->     716K -> 0.699M
Kernel data      = 01292000 ->   19016K -> 18.570M
Kernel heap      = 003B9000 ->    3812K -> 3.723M

Total            = 46FE0000 -> 1163136K -> 1135.875M

2) System => Free, Idle and Locked Memory

Code: [Select]
Free, Idle, and Locked Memory:
Free                RAM = 7A902000 bytes (2008072K) (1961.008M)
Idle                RAM = 0001A000 bytes (  104K) ( 0.102M).
        (Dirty idle RAM = 00015000 bytes (   84K) ( 0.082M)).
Long  Term Locked   RAM = 0005E000 bytes (  376K) ( 0.367M).
Short Term Locked   RAM = 00000000 bytes (    0K) ( 0.000M).
Short & Long Locked RAM = 00000000 bytes (    0K) ( 0.000M).

3) System => Kernel Information => System Object Summary

Code: [Select]
  Object Allocated Committed   Present   Swapped
 address    memory    memory    memory    memory  Description
          --------  --------  --------  --------
Totals:   619D9000  47B62000  47AD4000  00000000  (in bytes)
           1599332   1174920   1174352         0  (in Kbytes)
          1561.848  1147.383  1146.829     0.000  (in Mbytes)
Number of objects = 1024.

Analysis of 'Free' areas:
There are 398 free blocks which total 1E5E7000 (497564K or 485.902M)
The largest 10 free areas are:
 address      size
8FC10000  1D016000 (475224K or 464.086M)

4) System => General System => General System Information

Code: [Select]
General System Information:

OS/2 version        = 2.45, revision = 0.
Os2krnl build level = 14.203

SYSLEVEL.OS2 information
OS/2 Component ID   = 5639A6101
CSD GA level        = XR04503
CSD Previous level  = XR0C006

SYSLEVEL.FPK information
OS/2 Component ID   = 566933010
CSD Current level   = XR0C006
CSD Previous level  = XR0C006

Theseus4 Version    = 4.001.00
Machine information: Model = 252 (0xFC),
                     Submodel = 1 (0x01),
                     Revision = 0 (0x00),
                     ABIOS = 0 (0x00).
BIOS date = 10/31/12.
RAM available to OS/2 = C7F0B000 bytes (3199.043M).
It appears that all of it is being used as 'paging space' by OS/2.
  (This is the 'proper' usage of the memory.)

Following are the values from DosQuerySysInfo:
 1. QSV_MAX_PATH_LENGTH      = 260.
 3. QSV_MAX_PM_SESSIONS      = 16.
 4. QSV_MAX_VDM_SESSIONS     = 128.
 5. QSV_BOOT_DRIVE           = 7.
 7. QSV_MAX_WAIT             = 1.
 8. QSV_MIN_SLICE            = 32.
 9. QSV_MAX_SLICE            = 32.
10. QSV_PAGE_SIZE            = 4096.
11. QSV_VERSION_MAJOR        = 20.
12. QSV_VERSION_MINOR        = 45.
14. QSV_MS_COUNT             = 263519 (0:04:23).
15. QSV_TIME_LOW             = 1637843077.
16. QSV_TIME_HIGH            = 0.
17. QSV_TOTPHYSMEM           = -940527616 (3275820K -> 3199.043M).
18. QSV_TOTRESMEM            = 1198608384 (1170516K -> 1143.082M).
19. QSV_TOTAVAILMEM          = 2082484224 (2033676K -> 1986.012M).
20. QSV_MAXPRMEM             = 370147328 (361472K -> 353.000M).
21. QSV_MAXSHMEM             = 313262080 (305920K -> 298.750M).
22. QSV_TIMER_INTERVAL       = 310.
23. QSV_MAX_COMP_LENGTH      = 255.
26. QSV_NUMPROCESSORS        = 6.
27. QSV_MAXHPRMEM            = 1409286144 (1376256K -> 1344.000M).
28. QSV_MAXHSHMEM            = 1404301312 (1371388K -> 1339.246M).
29. QSV_MAXPROCESSES         = 128.
System Anchor Segment (SAS) selector = 0070.
Size of PTDA                 = 0768 bytes.
Size of TCB                  = 0304 bytes.
Size of Alias        record  = 0008 bytes.
Size of Arena        record  = 0016 bytes.
Size of Object       record  = 0010 bytes.
Size of Context      record  = 0005 bytes.
Size of Page Frame   record  = 000C bytes.
Size of Virtual Page record  = 000A bytes.
Size of SFT entry            = 00A2 bytes.
har of System Arena Sentinel = 0004.
har of Shared Arena Sentinel = 0006.
har above 512m Shr Arena Sen = 0005.
har of Page Frame table      = 001C.
har of Virtual Page table    = 001F.
System Page Directory        @ FE48A000.
System Page Tables start     @ FE200000.
DLL code Page Tables start   @ FE1F8000.
Start address shared global  @ 1E000000.
Alias Record Table           @ FCB16020.

Let me know if there is anything else you want me to catpure.

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 25, 2021, 05:54:06 pm »
Alright guys...I've got DATA!!!

Well, data is good, but visuals make it a tad easier to understand.

OK, so take a look at about 4 days of runtime stats. This is the capture of cstats that I mentioned earlier, and what i'm focusing on is the relationship between the metrics.

The thing to note is the nightly spikes...these are my RSYNC runs, which copy my data to NAS and also do a full disk RSYNC of the OS/2 partition to a local disk backup partition.

So I thought it would be interesting to deep-dive some more into these because if anything, these are going to more directly point out the cache behaviour given that a RSYNC copy will require a full disk scan, and therefore one would expect the METADATA to be heavily hit in the JFS cache.

This is shown in the 2nd capture where I basically narrowed things down to just these nightly spikes. For that reason ignore the 'plunge' you see in-between these runs, that's just a placemarker that I used to indicate the manual cut-off between each day.

I have gathered 7 different logs so far since I started experimenting with the larger JFS cache settings, each spanning about 3-4 days. The earlier logs have different JFS cache sizes along with different parameters.

Having said that, I honestly will tell you the following (keep in mind, this is just based on a single 4 day 1G cache cycle):

1) FF is just flat out faster, pages render quicker which is telling me that FF's cache (set to 350M max) persists in the JFS cache for longer
2) the faster application load is present for all other apps that I regularly use: Thunderbird, PMMail, Lotus 1-2-3, OpenOffice, Lucide, PMView, VSE and few others

Now here is the kicker which I did not exect to see: my shared memory over these past 4 days never dropped below 55M. This is VERY different from my prior experience where routinely after 3-4 days of normal system use (that typically includes daily FF re-starts - which i do once I see FF get to about 1G mem consumption as shown in Theseus) I basically exhaust all available shared memory and even shutting down all apps will not bring things back (because of the well known segmentation problem).

Sooo....I obviously need to re-do this cycle multiple times and attempt to better understand the cstats information.

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 24, 2021, 07:37:56 pm »

OTOH, here, where I could only get 700MB's cache,
Code: [Select]
Hostname:         4C4C454
OS2/eCS Version:  2.45
# of Processors:  4
Physical Memory:  3240 mb
Virt Addr Limit:  1536 mb

Even more memory accessible to the system.

Hmm...good point, which makes me think you are using up that upper memory with other device drivers.

For what it's worth, here is my Theseus=>System=>Nonswappable Memory Analysis output:

Code: [Select]
Nonswappable Memory analysis:
Apps & DLLs      = 00024000 ->     144K -> 0.141M
Process overhead = 004F2000 ->    5064K -> 4.945M
DD allocated     = 47799000 -> 1171044K -> 1143.598M
DOS              = 0001E000 ->     120K -> 0.117M
VDisk            = 00000000 ->       0K -> 0.000M
File system      = 00064000 ->     400K -> 0.391M
Kernel code      = 000B3000 ->     716K -> 0.699M
Kernel data      = 017F9000 ->   24548K -> 23.973M
Kernel heap      = 00497000 ->    4700K -> 4.590M

Total            = 49A74000 -> 1206736K -> 1178.453M

That massive 1143.598M number in the 'DD allocated' field is primarily the result of my 1G JFS cache...sure, other things are in there, but that's the big-boy amongst them.

I'm curious what you guys see for your running systems?

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 24, 2021, 04:01:31 pm »
Doug, Dave, everyone....

Anyways, previously I had found my system to run best with VAL=3072. However, that meant my JFS cache would only go to about 64M, any attempt at bigger value would produce that "out of memory" boot message and a default cache size being substituted.

This doesn't make any sense. It implies that the cache, over 64M, goes into unreserved upper shared memory space (above what VAL reserves). Could be possible, I suppose, and it might explain some of the weird crashes that I see when I try to use larger values for VAL.

This is precisely how it seems to work on my machine. The memory locations > VAL become available for SYSTEM use, and that appears to be what JFS cache is using.

...I use VAL=2560, and going larger causes instability in my system (don't know why). The biggest JFS cache, that I can use, seems to be 132M, no matter what larger value I set in the IFS startup line. However, I just tried setting it to 256M, in a new install that defaults VAL to 1536 (way too small for actual use), and it did take it. The Sentinel memory watcher (XCenter widget) appears to show that the memory was allocated (from somewhere). I tried 512M (then 384M, then your number 1048567), VAL is still 1536, but now cachejfs shows only 132M, and Sentinel seems to confirm that. I never see an "out of memory" boot message.

So, it seems that 256M is the largest value that doesn't default to 132M, for me (that is probably a bug, I expect that 132M is the maximum acceptable). I don't see any indication of where the cache memory is allocated (private low, private high, shared low, or shared high).

So here is what I think has a very direct impact on what you are seeing. Given your last response which shows the EXCEPTQ report, I find the following:

Code: [Select]
Hostname:         IREBBS7
 OS2/eCS Version:  2.45
 # of Processors:  2
 Physical Memory:  2793 mb
 Virt Addr Limit:  2560 mb

...however the matching result I see in any of my EXCEPTQ reports are:

Code: [Select]
Hostname:         NEUROBOX
 OS2/eCS Version:  2.45
 # of Processors:  6
 Physical Memory:  3199 mb
 Virt Addr Limit:  2048 mb

Notice the difference in the amount of 'Physical Memory' being reported?

My box shows about 400M more, this is without a doubt allowing me to run a larger cache (in combination with the appropriate VAL setting).

Something on my part that helps me get that is limitting the amount of video memory mapping that SNAP does. I have that set to 24M since that is all I need to support my two panels each running in 1920x1200 resolution @24bit colour.

Which version of JFS are you using? The one that I am using is v1.9.9 from AN.

Yup, same here, latest AN version.

I will get a better summary of all this following my next re-boot, which will give a clean-slate snapshot. Right now I'm on DAY3 cycle of JFS Cache stats gathering, and if there is anything I can learn from that I'll happily toss a deck together and share with you guys.

That will include the Theseus values that Dave mentioned as I happen to actually track my memory consumption using Theseus.

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 22, 2021, 05:15:23 pm »
Hi Doug,

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.

So my JFS cache parameters are all set in CONFIG.SYS with:

IFS=G:\OS2\JFS.IFS /CACHE:1048567 /LW:8,30,6 /AUTOCHECK:*

The absolute pre-requisite to increasing the JFS cache size was freeing up the high memory area (see the tail end of the 'QT5 browser' thread discussion where OS4User provides a pretty good explanation of how OS/2 allocates memory =>,2627.msg32933.html#new).

Anyways, previously I had found my system to run best with VAL=3072. However, that meant my JFS cache would only go to about 64M, any attempt at bigger value would produce that "out of memory" boot message and a default cache size being substituted.

Well, I was getting a little annoyed by seeing a quite sizeable NTFS cache allocation on my WIN7 boxes and started to dig into why our OS/2 JFS cache size was so seemingly limitted. As I was reading up on this it dawned on me that setting the VAL lower should allow me to free-up the 'system' memory, which would then become available to various device drivers, and JFS is certainly one of these.

I am now running with VAL=2048, and given that I have a 8G box with 4G allocated to RAMDISK, and 3.2G being recognized by OS/2 as "accessible memory", that allowed me to allocate more memory to FS cache, where I think the most "bang for the buck" exists today (given our platform and it's limitations).


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

Yes and no. There were some Warpstock presentations that touched on this. See "Dynamically Tuning the JFS Cache for Your Job" by Sjoerd Visser from 2009. P22 of that deck starts getting into the details of the JFS cache design, which is really about the logic of how the different buffers are handled, and the differences between actual data and metadata.

Bottom line in all this is: tune the settings to your system usage patterns.

Storage / Re: JFS cache sizing, and system "speed-up"
« on: November 22, 2021, 04:56:54 pm »
So I thougth I would provide a bit of an update given my experimenting with the JFS cache settings.

I have been using the OpenJFS utilities to gather the internal JFS metrics (

Based on various on-line references I had modified an existing REXX script (which in it's on-line shape did not actually work) to do real-time logging of the 'cstats' to a CSV file.

Anyways, through multiple cycles I have been trying to understand how the various parameters affect what JFS does on my system (of course, my usage is an end-user type of use, so very different from a let's say server - web or file for that matter).

Regardless, I am now running a 1G JFS cache and in the current iteration of parameters I have to say the responsiveness of my system is a "day & night" type of a difference from where I started. In particular however, the latest move from a 768M cache to a 1G cache introduced a significant improvement that I'm not sure I can quite explain.

Specifically, using the cstats utility the 1G cache shows the following:

Code: [Select]
cachesize    262141   cbufs_protected       58960
hashsize     131072   cbufs_probationary    30920
nfreecbufs    75323   cbufs_inuse               0
minfree        6000   cbufs_io                  0
maxfree       60000   jbufs_protected       96286
numiolru          0   jbufs_probationary      642
slrun        155246   jbufs_inuse               0
slruN        174760   jbufs_io                  0
Other            10   jbufs_nohomeok            0

Meanwhlie, the os2stats utility show this:

Code: [Select]
NCache: lookup: 262141
        hit: 131072
        miss: 75323
        enter: 6000
        delete: 60000
        name2long: 0
JCache: reclaim: 262141
        read: 131072
        recycle: 75323
        lazywrite.awrite: 6000
        recycle.awrite: 60000
        logsync.awrite: 0
        write: 155246
LCache: commit: 262141
        page.init: 131072
        page.done: 75323
        sync: 6000
        maxbufcnt: 60000
ICache: n.inode: 262141
        reclaim: 131072
        recycle: 75323
        release: 6000

The cachesize field implies that actual data cache is only 256M, which is what I'm struggling with. Keep in mind, I came from HPFS386 world, where seemingly at least, it was pretty clear how big your cache pool was and what your cache hit/miss were. The JFS being a journaling FS deals with metadata, so it's not quite as clear as having a single cache for content data; at least that's my current understanding.

In fact I suspect my interpretation of what these fields mean may not be correct. The '262141' may not be a k-byte count, instead it may be a metadata unit count, I think? LOL

I am therefore curious if anyone else understands this better?

My next step is to look at the sources to see if I can decipher this.

Pages: 1 2 [3] 4 5 ... 72