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 ... 71
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.

Web applications / Re: QT5 simplebrowser
« on: November 21, 2021, 08:14:56 pm »
I do find this to be counterintuitive, expecting that should a VAL be set sky-high I should in fact be able to request a 1G JFS cache

Of course, it is  counterintuitive. And I have no idea why you came to conclusion  to make VAL sky-high. As I said, JFS cache situated in System Arena. So to have more space for JFS cache you have to increase System Arena, is't it ? As I also said, System Arena is between VAL and 4GB - so you have to set VAL as low as possible (say 512) to have max size of System Arena (3.5GB).

We have gotten quite a bit off-topic here (given the QT5 & browser focus), but I will wrap up my input into the conversation by stating the following: VAL is intended to provide the additional memory footprint for applications that need the bigger "box" boundaries. My remark re: "counterintuitive" was meant to say that since that setting is there, it should NOT override and/or allow the system settings, such as the JFS cache for example, to be impacted by a user specified VAL value. After all, unless AND until I can successfully boot I have no chance to run an application that may in fact require such a large VAL in order to operate successfully.

The "why" this hasn't been resolved in the kernel/whatever logic is what I find to be "counterintutive".

Anyways, good discussion, I genuinely wish we had more of these kinds of topics in a "underneath the covers" type of a forum perhaps?

Setup & Installation / Re: Making of bootable USB stick, or CD - how to?
« on: November 21, 2021, 01:57:12 am »
Don't you have access to a ArcaOS build? That would be simplest. USB and some CD boots require setting up a ramdisk and actually booting from that. Anyways there's various programs for booting a CD at perhaps

Yeah, I do Dave, but I honestly didn't want to mess around with that given how much older and version-of-a-version-of-a-version my current OS/2 build is! LOL

So I'm not giving up on that approach, just wanted to avoid any sort of conflicts, etc.

My MAINT partition is actually built using 'bootos2' utility, however there is nothing in the DOC that talks about how to target a CD build. This is the reason why I thought that maybe there is some way for me to literally grab my MAINT partition and "toss" that onto a CD. By "toss" I of course mean more than just the tools to use for burning a CD (already have that ready), rather I need to understand what's actually required for the CD to be bootable.

Anyways, alright, appreciate the pointer to the other Hobbes utils, will check those out! Thanks...

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