Messages

16

Internet / Re: firefox question

« on: September 28, 2024, 03:17:58 am »

So FF has three kinds of cache:

1) memory
2) disk
3) app

Take a look at 'about:cache' to see the individual allocations, although really the 'disk' part is what you are lookign for given your quesiton.

The 'browser.cache.xxx' is a rich set of config options...do a little reading up on this and you can configure your setup to just suit your needs. Most of these options are controllable through the GUI, although not all.

17

Applications / Re: Installation of Open Office 4.1.11

« on: August 14, 2024, 07:48:57 pm »

...
Uninstalled. Rebooted. No problem.

Re-installed. Shut down. No problem.

Restarted, Got the IFX error...

Glenn,

Looks like you may have some other INI problems, and perhaps the uninstall/install process simply highlighted them?

Are you able to get back to a working config?

If YES, I would recommend running checkini to see what it finds.

For my part, that is pretty much the approach I take to each significant App upgrade:

1) clean existing INIs
2) save backup of INIs
3) execute the upgrade
4) save backup of INIs
5) clean new INIs

...yup, a bit tedious and time consuming but for the most part that has proven itself to be a reliable approch to producing a good outcome.

From a more specific hints/topics perspective, how about tossing this into your CONFIG.SYS if you don't have this already:

SET DESKTOP=x:\DESKTOP

where: 'x' is your boot drive.

18

Hardware / Re: AMOUSE + Lotus 123

« on: August 03, 2024, 02:19:19 am »

JPM,

How about the 'Mouse - Properties' object itself?

My IBM/Lennove ProPoint (the one with the directional button in-between the keys) shows a 'Scrolling' tab in the Properties where you control how your mouse hardware use is to be mapped to inputs.

There is also the 'Mappings' tab, which further defines options for things such as MB3, etc...but that is a XWP feature.

I haven't found anything in Lotus 1-2-3 that actually allows you to further define mouse actions.

19

Applications / Re: Unzip Version 6.0 hangs when booting to a commandline

« on: August 01, 2024, 12:10:22 am »

Hey Martin,

...For what I see on the F2 boot the %LIBPATH% is not recognized, but the config files looks fine. Is there any elegant way to see full the enviroment variables on the command line (image LIBPATH_F2.png )?...

Dave Yeo already gave the much bigger answer, but otherwise, if you want to look at each individual ENV variable you can do this at CLI:

Code: [Select]

echo %PATH%


20

Applications / Re: lSwitcher v 2.94

« on: June 16, 2024, 02:25:00 pm »

Andy,

Does anyone else have an issue when Ctrl clicking the desktop icon that barely a small highlight shows up and now list of processes to kill?

I assume you meant to say "...and NO list of processes..."?

If yes, correct, that's what I see here as well in the pop-up switching window. This does work for all the other icons of running programs I see however.

21

Applications / Re: AOS RAM Disk

« on: June 09, 2024, 03:14:59 pm »

Hello Roberto,

... But reducing the virtualaddresslimit to 1024, it already shows me 1gb of cache.
 The price is the reduction of memory...

Yup, this JFS thing is all about balancing the hardware resources in a manner most beneficial to the way YOU use YOUR machine. So there really are no generalizations, other than perhaps some starting points?

With my particular hardware combo I'm able to run this large of a JFS cache with 'VIRTUALADDRESSLIMIT=2048' setup. I found that going lower than that will start causing problems with our current applications, as others have pointed out as well.

So the 'balance' thing here is probably more heavily skewed towards 'being able to run an app' as opposed to 'having a fast FS cache'.

...I've still set up my ArcaOS NAS like this, but I don't see any performance improvements in file transfer.
 I'll have to do more tests...

I would NOT expect at all there to be file transfer performance improvements, other than I suppose the fact that the larger cache allows your target write operation to be cached.

...
[C:\]cachejfs

          SyncTime:      32 seconds
            MaxAge:     128 seconds
        BufferIdle:       8 seconds
        Cache Size: 1048576 kbytes
        Min Free buffers:    8000 (   32000 K)
        Max Free buffers:   15000 (   60000 K)
Lazy Write is enabled...

One last comment is re: SyncTime, MaxAge and BufferIdle. Be careful with these. I have my setups as large as they are because my machine is hooked up to a UPS fulltime. Therefore, the chance of power going out and the JFS cache NOT getting flushed out is very minimal. Still, a hard TRAP could still happen, so there is always some risk there.

Just for reference, here are my notes on this topic:

Code: [Select]

/LAZY:synctime,maxage,bufferidle
enables write cache with the following parameters:

- synctime : the interval at which the sync thread runs
default = 16

- maxage : is the longest time that a frequently modified file is kept in cache
default = synctime * 4

- bufferidle : is the time indicating a "recent" change. Changes newer than this
               value are not written unless the last write was older than maxage.
default = MIN(1,synctime/8)


22

Applications / Re: AOS RAM Disk

« on: June 08, 2024, 01:24:58 am »

Hello roberto!

Code: [Select]

...
IFS=C:\OS2\JFS.IFS /CACHE:1048576 /LW:32,128,8 /AUTOCHECK:*
CALL=C:\OS2\CMD.EXE /Q /C C:\OS2\CACHEJFS.EXE /LW:32,128,8 /MINBUFFER:8000 /MAXBUFFER:15000 >NUL
...
[C:\]cstats
cachesize     32768   cbufs_protected       10302
hashsize      16384   cbufs_probationary     2585
nfreecbufs    18938   cbufs_inuse               0
minfree        8000   cbufs_io                  0
maxfree       13000 **   jbufs_protected         681
numiolru          0   jbufs_probationary      255
slrun         10983   jbufs_inuse               0
slruN         21844   jbufs_io                  0
Other             7   jbufs_nohomeok            0


So here is the thing: my JFS cache is really large, 1Gig, therefore the '/CACHE:1048576' setting.

When you attempted to run as big of a cache on your system, given that JFS wasn't able to allocate that much RAM it actually defaulted to 10% of your accessible RAM (or maybe 20%??? I don't remember the default at the moment), which gave you a JFS cache of about 128M.

This is confirmed by your cstats value of cachesize=32768, where each such buffer is 4096 bytes. You can get a true JFS cache size by running the following:

Code: [Select]

[G:\os2]cachejfs

          SyncTime:      32 seconds
            MaxAge:     128 seconds
        BufferIdle:       8 seconds
        Cache Size: 1048576 kbytes
        Min Free buffers:    8000 (   32000 K)
        Max Free buffers:   24000 (   96000 K)
Lazy Write is enabled

Therefore, if you are interested in increasing your JFS cache size you may want to inch-up on the 1Gig slowly...maybe go to 256M, than 512M, etc...

23

Applications / Re: AOS RAM Disk

« on: June 07, 2024, 07:23:10 pm »

hey Dave!

Dariusz, did you ever publish your updates to diskio, also have you considered adding them to Sysbench, which basically uses diskio for disk benchmarking.

Nope...b/c I started the work on converting it to handle SSD's 4K sector sizes and ran into some problems with DosDevIOCtl32 return RC=87, which I wasn't able to resolve.

However, for what it's worth, here is the DISKIO version that I previously published in the forum here on a separate thread => https://www.os2world.com/forum/index.php/topic,2676.0.html.

24

Applications / Re: AOS RAM Disk

« on: June 07, 2024, 04:00:38 am »

Not quite RAM disk related, but for the folks who are experiencing that "...system seems to freeze for 4 - 8 seconds and then resume..." behaviour: if you are using JFS, this may be a symptom of your JFS settings causing it to run out of free buffers and needing to purge the cache(s) to free up the buffers.

This is well documented by Sjoerd Visser in his "Dynamically Tuning the JFS Cache for Your job" presentation deck from way back in 2009.

Bottom line: this can be brought on by several 'system use' activities, but it basically causes the JFS code to write out dirty buffers to disk. The key to dealing with this on my rather large JFS cache (1G) was to watch the typical system use (log cstats output) and adjust the MIN & MAX free buffer settings in pair with the overall LazyWrite setups.

This is a trial & error thing as your machine will be heavily driven by what your usage patterns are.

For what it's worth, here is what I have:

CONFIG.SYS:
IFS=G:\OS2\JFS.IFS /CACHE:1048576 /LW:32,128,8 /AUTOCHECK:*
CALL=G:\OS2\CMD.EXE /Q /C G:\OS2\CACHEJFS.EXE /LW:32,128,8 /MINBUFFER:8000 /MAXBUFFER:24000 >NUL

5 Days into using my box (last time it was up for 27 days, normal desktop stuff, nothing fancy), castat shows:

Code: [Select]

[G:\]cstats
cachesize    262144   cbufs_protected       35795
hashsize     131072   cbufs_probationary    22467
nfreecbufs   101902   cbufs_inuse               0
minfree        8000   cbufs_io                  0
maxfree       24000   jbufs_protected      101075
numiolru          0   jbufs_probationary      894
slrun        136870   jbufs_inuse               0
slruN        174762   jbufs_io                  0
Other            11   jbufs_nohomeok            0

...with the nfreecbufs never dropping so low that they show zero (0) as slruN approaches slrun value.

I started with MIN=8000 and MAX=16000, and that gave a pretty solid system, although sometimes I would get that tell-tale "hang" feeling. So I moved to MIN=4000 thinking that would free up the buffers for caching duties..welllll...no sirr....wrong move...that completely resulted in a solid and repeatable "system hang". So back to the drawing board so to speak, I set my MIN=8000 and increased MAX=24000. RESULTS => SOLID, the most solid system I have had for years.

The thing that 'ruins' my JFS cache (spoils it actually) is the nightly disk copy (rcopy) run. If it wasn't for that activity my cbufs_protected would stay very large, which means I have a good amount of content that's being successfully cached. Of course, the jbufs_protected is equally important as that allows JFS to quickly figure out where to "go" to retrieve the content as opposed to having to read the data from the disk itself. Again, which one should be the focus for you entirely depends on what disk access patterns you see.

Anyways...balance, somewhere out there are the right settings for your machine.

Last but not least, my JFS formatted RAM DISK results are (diskio):

Drive cache/bus transfer rate: 629714 k/sec
Data transfer rate on cylinder 0   : 680303 k/sec
Data transfer rate on cylinder 634 : 680021 k/sec

meanwhile the SSD results are:

Drive cache/bus transfer rate: 125467 k/sec
Data transfer rate on cylinder 0   : 286615 k/sec
Data transfer rate on cylinder 30399: 253408 k/sec

The ram disk is 2-3x faster here.

EDIT
====
One more thing to add to this, albeit this is easily identifieable and most likely NOT the situation everyone else is seeing: I tried running AHCI driver here and on my hardware that would result in what seemed like a complete HARD lock for about 4-8 secs at a time. Once that "event" passed the system was available for use once again. I tried a boat-load of different setups and configs but none of it helped. Subsequently i went away from AHCI.

25

Setup & Installation / Re: libtiff-tools: upgrade, but where r the tools???

« on: May 28, 2024, 03:10:38 am »

Dave,

Yum install libtiff-legacy-tools looks like it would install tiff2pdf, version 3.9.5-2. Might have to install after upgrading
Seems that an issue should be raised at Bitwise about the missing tools.

Yup...happens to be the same conclusion I had just arrived at LOL, but our posts virtualy crossed each other!

I suspect you are right...

26

Setup & Installation / libtiff-tools: upgrade, but where r the tools???

« on: May 28, 2024, 02:53:41 am »

Question for the masses: I'm at libtiff-tools 4.0.9 level here, and the 4.6.x release has been sitting out there in EXP state, so I thought I'd take a stab at it with the pre-req of course being the baseline libtiff itself.

The libtiff-tools however drops just about all the "tiff2..." EXE files...so tools themselves, and I see not legacy version out there that still provides these.

Specifically I am after the tiff2pdf.exe one, as PDFmergeNX uses that...

Sooo...I went back to the previous version b/c the latest & greatest doesn't quite seem to be just that.

Is there something else out there that has this? Doing a 'yum provides */tiff2pdf.exe' just lists the previous releases and shows nothing at the 4.6.x level.

EDIT
====
Just spotted libtiff-legacy-tools, but that's at 3.9.5-2 level, and wouldn't that be an older version of libtiff-tools-4.0.9-1? (which is what I had before I executed the upgrade)

27

Applications / Re: XWP v1.0.16

« on: April 29, 2024, 02:32:53 am »

Hello Martin,

...I think that XWPProgramFile Class (or is it some other WPS Class?) has already something implemented (See picture) on the "Module" tab. But I have no idea how to have the same information for DLLs files...

Hmm...so for some reason I do not see this being populated for some EXEs, such as the NewView.exe, where at CLI there certainly is BLDLEVEL info showing.

DLL wise, turns out that not all DLLs are classified as XWPProgramFile object, which is perhaps why so it happened that the DLLs I was looking at showed no such Module tab.

So at a follow-up, two actually, I'm curious:
1) DLL object type conversion
- reading that other thread you shared, it seems like this was a manual process that needed to be done for every new DLL, is that correct?

2) re: XWP NEW Feature request: now that I understand what's already there (or should be there), I would like to just stick to the menu selection which would simply show that BLDLEVEL info in it's own pop-up

28

Applications / Re: XWP v1.0.16

« on: April 29, 2024, 12:52:50 am »

Rich,

New feature request: would you consider implementing BLDLEVEL file object pop-up functionality?

What I'm envisioning is the ability to right click on a DLL, or any object that does contain the BLDLEVEL information, and have this stuff either pop-up directly under some sort of 'Version' or 'BldLevel' menu entry, or perhaps another place such as under 'Properties'

29

Multimedia / Re: mplayer - just stopped working...sort of...

« on: April 28, 2024, 08:01:50 pm »

Hello KO!

...

3. What's the value of '2D Acceleration' ?

"YES" on my machine

Then, your system should play a movie with 2D acceleration, that is, SNAP mode. Nevertheless, if it fails, your system or SNAP driver seem not to support 1080p with 2D acceleration. In order to verify this, how about other smaller clips than 1080p, such as 720p ?

Great pointer!!!

Sure enough, finding a few other videos I was able to play them through SNAP config, although that's not to say all 720s played, some would, some would not.

Then I remembered: the SNAP vidmem size is something I had tweaked in the past in order to free up max ram for my JFS cache (1G)...sure enough, I had it set to 18M, which for regular use was perfectly sufficient (1920x1200 x 2 heads). However, in this case, whether its the double-buffering or something else, perhaps this was causing me a problem?

I doubled up to 36M, and YUP...all of my 1080 vides play back just fine!!!

Eventually settled on 24M, which also happens to be the previous setting I had in place for a very long time...not sure why I had moved away from that, was probably experimenting with a larger JFS cache and just never remembered to bump that back up.

Anyways...sir: thank you for that spot-on remark!!!

30

Applications / Re: LarsenCommander - new test version

« on: April 28, 2024, 06:05:07 pm »

Hi Andi,
...
File xfer performance wise, here are the results for movement of a test 800M AVI file:

1) from SAMBA share to ramdisk
OLD:  Peak=58,270K, Avg=43,550K
NEW: Peak=56,220K, Avg=46,516K

...so I'm thinking this is more about being network bound (1G LAN, but of course the Samba share box - NAS is the limitation here)

2) from ramdisk to SSD drive (Samsung 860 Evo, SATA)
OLD:  Peak= 82,788K, Avg=  45,545K
NEW: Peak=310,118K, Avg=220,910K
...

Repeat of the same performance tests for the newest version:

1) from SAMBA share to ramdisk
OLD: Peak=56,220K, Avg=46,516K
NEW: Peak=51,367K, Avg=45,832K

2) from ramdisk to SSD drive (Samsung 860 Evo, SATA)
OLD: Peak=310,118K, Avg=220,910K
NEW: Peak=503,901K, Avg=311,825K

...which naturally made my eyeballs nearly pop out b/c let's be honest, my SSD isn't that fast!!!

So a re-do produced the following NEW:
NEW: Peak=430,674K, Avg=183,007K

...which while still pretty high for a Peak, I suspect this has everything to do with my crazy ass JFS cache, which is 1G in size.

Couple more tests later though the higher Peak appears to be sustained, so perhaps there is a little bit more improvement here Andi!!!?

Thank you again!