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 ... 61 62 [63] 64 65 ... 89
931
Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 20, 2018, 04:49:25 pm »
Hi Lars,

OK, step by step explanation:

1) do you ONLY have HPFS386 partitions on your HD ? Or do you also have JFS partitions ?

Only using HPFS386 partitions. The only other IFSs deployed are: FAT32 & CDFS, but the CDFS is a standard these days and FAT32 is specific to just using memory cards/thumb drives.

Quote
2) have you been copying from G: to ramdisk ?

Yes, G: is my boot drive, I am copying various sized files from G: to ramdisk, which is drive Y:

Quote
3) What driveletter does your ramdisk have ? It seems that it is neither F: nor G: so what is it ?

Ramdisk is drive Y:

Quote
4) What is the switch to cache386 to explicitely turn on/off caching for a specific drive letter ?

Issuing 'cache386' @CLI shows the following:

Code: [Select]
[G:\]cache386
Valid options for CACHE386 (x is an optional drive letter):

/OPTIONS[:x]         Display current configuration
/STATS[:C|:D]        Display, clear, or dynamically display statistics
/LAZY[:x][:ON|:OFF]  Enable or disable lazy writing
/MAXAGE[:x]:n        Change msDataAge to n milliseconds
/BUFFERIDLE[:x]:n    Change msIdleBuf to n milliseconds

If no drive (x) is given, the option will apply to all HPFS drives.

Each option may be abbreviated to a single letter, for example:

CACHE386 /B:D:1000    (sets BufferIdle to 1000 for drive D)

So, to turn on the cache (lazy write really as per the option listing, but it appears to actually behave as if that controls the CACHE function) you issue 'cache386 /l:y:on', which can then be checked by issuing the following 'cache386 /o:y':

Code: [Select]
[G:\]cache386 /o:y
CACHE386 options
Cache Size    65536 KB

Drive Y:
   Lazy write:              ON   MaxAge:          15000 msec
                                 BufferIdle:       5000 msec

As best as I can tell issuing 'cache386 /l:y:off' disables or enables the HPFS386 cache:

Code: [Select]
[G:\]cache386 /o:y
CACHE386 options
Cache Size    65536 KB

Drive Y:
   Lazy write:             OFF

Therefore, the previously reported results are specific to the above method of turning on the HPFS386 cache (lazy write) for the ramdisk drive 'Y:'.

As far as I can tell there is nothing else in the HPFS386 module which allows one to explicitly control the cache function, instead I believe it is the 'LAZY write' control that actually does this.

932
Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 20, 2018, 04:28:33 pm »
...It's not easy to write a good installer, and the skills have more to do with test engineering than software engineering. OS4 would be especially challenging because any error leaves the installation unable to boot. The target installations are diverse -- OS/2, eCS and ArcaOS.

Neil's got a great point about the installer. Given that we now have several options available as far as picking the OS2 loader of choice, I would actually be hesitant to allow an installer to do this type of stuff.

Yeah, I know...may seem counter-intuitive, but I think there are far too many things that could go just 'wrong enough' to prevent my OS/2 machine from booting, that would make me feel comfortable doing this any other way.

Funny thing is, the request for additional info was literally my feedback to the OS4 folks in one of the other threads. But I think what I was talking about was a lot more like the stuff Lars mentioned here, that being: give me a better understanding of the internal design/implementation of the changes so that I can feel more confident in my decision to pursue this approach.

Having said all of the above, the actual (manual) install of the OS4 solution is not all that hard. The READMEs included do cover it fairly well, but yeah, go through them at least a couple of times. I think most of time would be spent in adjusting the default configuration, so getting yourself multiple CONFIG.SYS instances to give you the flexibility to either boot with the OS4 loader, or the default OS2 or maybe the AOS one.

933
Internet / Firefox - 45.9.0 for OS/2 GA1.1...anyone...anyone???
« on: April 20, 2018, 04:19:23 pm »
OK, what is happenning here??? LOL  :o

FF 45.9.0 (rel-3 I believe), which brought us up to GA 1.1 was published 2 days ago, yet the forum is DEAD QUIET...you people are starting to freak me out...!!!

C'mon, get out there, install, is the result better then previous releases? https://github.com/bitwiseworks/mozilla-os2/releases

Truth be told, other than the email notification I get on the testers' list, I did not see any other announcements...so I figured I'd post here. I did the d/l through the above link, as a ZIP file, un-packed to a non-RPM location, I do not see the official RPM package out yet, but then again, I am only looking at the public netlabs-rel repo.

Anyways, it's out there...check it out, I figured I'd give it a few days' worth of runtime before sharing my assessment with the wider audience of the forum.

934
Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 18, 2018, 05:25:45 pm »
Hi Lars!

Umm...sorry...I completely do not get what led you to make the below statements, but allow me to re-iterate what I previously stated in my response to your post.

Originally you stated the following:

Why would you use HPFS386 on a ramdisk anyway ?

I then answered by providing the empirical evidence as per my tests:

You would think you are correct in that thinking. I would not use HPFS386 on a ramdisk if I had a choice, but it is a HPFS or HPFS386 type of a decision, so I have no choice in this matter, I am forced to run HPFS386 only. Since HPFS386 allows you to shut the cache off for the ramdisk created by QSINIT itself, as best as I can tell this should not a problem.

..and yet the numbers I see tell an entirely different story...

I am basing this last conclusion on the output I see from 'cache386 /o' command and throughput numbers I see from 'Lars Commander' during a file copy operation. If I then compare the speed throughput for the ramdisk with the cache ON and OFF I see the following:

1) HPFS386 cache ON - 600 Meg file copy from HD to ramdisk
Peak => 108,586K
Avg => 104,278K
Last => 108,420K

2) HPFS386 cache OFF
Peak => 53,079K
Avg => 26,325K
Last => 27,736K

...and that led you to conclude the following (which is what I do not understand at all):

You leave it completely unclear if "cache386 /o" turns off the cache for ALL HPFS386 formatted partitions or only for the Ramdisk. Then you leave it completely unclear if you were copying from/to a HPFS386 formatted partition to/from a HPFS386 formatted partition or to/from a partition unaffected by the cache setting.
I have the impression that both source and target partitions were HPFS386 partitions ...

So I thought it was pretty clear that in the context of the thread we were talking about the suitability of turning on the HPFS386 cache for a ramdisk, I mean after all, your original post response (which I quoted above for ease of reference) specifically stated so, or where you simply questioning whether one would want to use HPFS385 filesystem as opposed to something like FAT, FAT32 or JFS???

Alright, so let me confirm: YES, the HPFS386 cache is being turned ON for ramdisk and I am attempting to assess the impact on ramdisk performance with the HPFS386 cache being in either ON or OFF setting.

Further on, my reference to 'cache386 /o', given the context of the conversation, specifically relates to what cache386 output provides as applicable to the ramdisk, such as:

Code: [Select]
[G:\]cache386 /o
CACHE386 options
Cache Size    65536 KB

Drive F:
   Lazy write:             OFF

Drive G:
   Lazy write:              ON   MaxAge:          15000 msec
                                 BufferIdle:       5000 msec

In the above example this shows that HPFS386 cache is active for the G: drive (which is my boot drive), and it is not active for F: drive, which is my maintenance partition.

Therefore:

You leave it completely unclear if "cache386 /o" turns off the cache for ALL HPFS386 formatted partitions or only for the Ramdisk...

...as explained above, the 'cache386 /o' is applicable to the status of the HPFS386 cache for ramdisk only.

Further on:

...Then you leave it completely unclear if you were copying from/to a HPFS386 formatted partition to/from a HPFS386 formatted partition or to/from a partition unaffected by the cache setting...

...which is not the case since I specifically stated the following:

...
1) HPFS386 cache ON - 600 Meg file copy from HD to ramdisk
...

Given that I am looking to answer the 'should I turn ON the HPFS386 cache for ramdisk' question only, I would not be shutting OFF my physical HD HPFS386 cache, it simply would not make sense to do so since when the machine is in production mode it would never run without the HPFS386 cache being turned ON.

OK, I hope that clarified whatever may have been causing confusion.

935
Programming / Re: GCC - how to enable multi-threading in CPP?
« on: April 18, 2018, 06:31:41 am »
OK, so attempting to build a super-simple multi-threaded app:

Code: [Select]
#include <iostream>
#include <thread>

using namespace std;

void hello_world()
{
  cout << "Hello from thread!\n";
}

int main()
{
  thread t(hello_world);
  t.join();
  return 0;
}

Compiling with the following GCC options:
'-march=amdfam10 -O2 -pipe -v -idirafter g:/code/tools/toolkit/h -Zomf -std=c++11'

...produces the following compile time error:

Code: [Select]
G:\code\source\GCC\threads2.cpp:13:3: error: 'thread' was not declared in this scope
   thread t(hello_world);
   ^
G:\code\source\GCC\threads2.cpp:14:3: error: 't' was not declared in this scope
   t.join();

So what's the secret? I see a lot of similar problems on the Winx version of their GCC port (MinGW), mostly stating that the thread library does not implement the native threads...is that a problem for us on OS/2 as well?

936
Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 18, 2018, 05:35:30 am »
Hi dixie,

/1 forces system to use ancient STRAT1 method. This is fatal for most of file system drivers. Actually, only kernel's FAT implementation and HPFS.IFS able to use it.

HPFS386 looks more advanced as well as JFS. Nothing to do here...

One more thing I wanted to ask a clarification for.

You can create a ramdisk by using the following command in your QSSETUP.CMD: 'ramdisk y: hpfs', and this appears sufficient enough to give you a working HPFS formatted ramdisk. So is there any real need and/or benefit to running this command which I see mentioned several times in the readme as well: ' format Y: /quick /fs:hpfs /q'?

This is a stand-alone format of a ramdisk as a HPFS filesystem, I can only imagine one would want to perhaps use it in some situations, but I do not think this is necessary in any way, is that correct?

937
Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 17, 2018, 06:32:05 pm »
You can try File i/o test in sysbench :) I found one, was launched on HPFS386 too...

So here are the results of the Sysbench 'File I/O' test that I reported the results for in my previous update. Take a look at them, they are pretty close, but at times significantly different. I think what may be getting muddied up by Sysbench is this whole 'Cached' vs 'Uncached' result...I have no idea how Sysbench controls that.

938
Applications / Re: OS/4 (technical details only)
« on: April 17, 2018, 05:10:44 pm »
OK, OS4User, time for me to get off of my butt and get the debug info to troubleshoot the hard trap right after PMSHELL comes up. With FreeRDP making progress and VBox supporting extra features of the OS4KRNL I have no reason to delay further.

I re-read the Wiki you posted above and will get the debug kernel setup and ready to go. Beyond this though, is there anything specific I need to do in order to capture the "moment" the system traps?

My assumption is that maybe through the debug kernel I have some way to communicate with the OS/2 box, but even if that is the case, once the trap occurs, how do I know what additional information to log? Can you provide any 'working instructions' for this? Even high-level stuff might help...

Thanks!

939
Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 17, 2018, 04:43:18 pm »
Hi Lars,

Why would you use HPFS386 on a ramdisk anyway ?
Optimizing sector accesses is irrelevant for a ram disk. Caching will even make things worse: you waste additional memory for no gain in speed (after all, on a ram disk, each data sector is already in memory ...)
And it does not look like the OP cares about the file access protection features that HPFS386 offers on top of HPFS.

However, I don't know if you can load HPFS.IFS and HPFS386.IFS at the same time. Most likely not ...

You would think you are correct in that thinking. I would not use HPFS386 on a ramdisk if I had a choice, but it is a HPFS or HPFS386 type of a decision, so I have no choice in this matter, I am forced to run HPFS386 only. Since HPFS386 allows you to shut the cache off for the ramdisk created by QSINIT itself, as best as I can tell this should not a problem.

..and yet the numbers I see tell an entirely different story...

I am basing this last conclusion on the output I see from 'cache386 /o' command and throughput numbers I see from 'Lars Commander' during a file copy operation. If I then compare the speed throughput for the ramdisk with the cache ON and OFF I see the following:

1) HPFS386 cache ON - 600 Meg file copy from HD to ramdisk
Peak => 108,586K
Avg => 104,278K
Last => 108,420K

2) HPFS386 cache OFF
Peak => 53,079K
Avg => 26,325K
Last => 27,736K

I specifically selected a large source file for this initial test so that it is bigger than my HPFS386 cache of 64Meg. Yet despite this, I am seeing the same level of performance difference across both small and large files, that being nearly 4x faster throughput on cached ramdisk.

Lars, unless your throughput measure is being skewed by something else, the numbers here tell a different story. The only negative downside to keeping the HPFS386 cache on for the ramdisk is the 'pollution' of the true cache for the other real HDs in my system.

Sysbench (0.9.5d) 'Disk I/O' test is completely messed up by the ramdisk, the only number that actually comes back is the bus xfer which is 355MByte/s. However, the 'File I/O' results give 216157 for non-cache and 260371 for cached configurations.

Therefore, in the end, given what I see above and the fact that most files tossed on the ramdisk will normally be small (therefore implying the true cache pollution to be small) it actually seems like leaving the HPFS386 cache ON for the ramdisk gives the better performance.

940
Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 17, 2018, 03:46:36 pm »
Hey Doug,

...The way that I use the RAMDISK, is to use all memory above what OS/2 uses normally, for the RAMDISK. Then, I use HPFS for the RAMDISK (I also make the cache as small as possible - 64K- because the cache slows it down). All of my other partitions are JFS (which is probably better than HPFS386 anyway), except for one that is FAT32, for sharing files with windows.

Yup, similar configuration to what I currently have. My operating partitions are all HPFS386, the nightly backup partitions are HPFS386 as well but no CACHE on them. Neither is the RAMDISK, else it defeats the purpse.

941
Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 17, 2018, 04:59:26 am »
Quote
I think it is you who have completely missed that fact that I am NOT running AOS.

Yes, I did miss that. I still suggest using QSINIT, and it's RAMDISK (if you don't use ArcaOS)...

Dave is right, there are many versions and configurations of OS/2 floating around, so it's super easy to fork-off on that road, no biggie, easy miss, but you gave me the needed "push" ;D to re-visit the QSINIT utility.

I had previously installed it some time ago to investigate the functionality, but it was in it's early days and I didn't feel it offered much to warrant replacing the standard process.

So here is a bit of an update, and this will have specific info for those running HPFS386, because certain option available in the current latest version of QSINIT doesn't quite "play nice" with a HPFS386 machine...read on!

OK, so here is what I have done:

1) install QSINIT
2) add BASEDEV=HD4DISK.ADD to my CONFIG.SYS
3) add 'ramdisk Y: hpfs' to QSSETUP.CMD

...seemed like that's all that was required to get a plain-vanilla install. However, upon a re-boot I was greeted by numerous HPFS error messages pertaining to just that RAMDISK. I emailed dixie (QSINIT) author who confirmed this and explained that HPFS386 in particular has a problem with the RAMDISK in that it always thinks the volume is dirty because it always considers the volume to be a brand NEW volume.

Indeed, that required me adding the new 'Y' (my drive letter) to the CONFIG.SYS HPFS386.IFS line:
IFS=G:\IBM386FS\HPFS386.IFS /AUTOCHECK:FGY

Now with this auto-check in-place upon a re-boot there is a very quick CHKDSK that runs on the RAMDISK, because HPFS386 thinks it's NEW and therefore dirty and must be cleaned. The QSINIT dirty flag set utility does not help. But, this process is super quick and gives me a nice, nearly 5Gig ramdisk, plenty of storage.

Further on, I attempted to use the '/1' switch for HD4DISK.ADD, this however leads to a hard stop at bootup where the RAMDISK is not initialized and the device itself is only available as a DASD unit, the error message below is what I see:
Code: [Select]
HFS0109: The disk device driver for the 386 HPFS volume on drive Y: does not support memory above 16MB. The volume was mounted for DASD access only.

I do not understand the cause, but somehow the suggested '/1' parameter for use with HPFS formatted ramdisks does not work here. Playing with the 'useallmem' setting in HPFS386.INI does not help. Could be the size of my HPFS386 cache (only 64Meg), or it could be due to some difference between regular HPFS and HPFS386.

Anyways, I will let dixie know about this, maybe he is willing to debug further.

942
Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 15, 2018, 06:58:45 pm »
Doug,

...oh boy... ::)

You seem to have completely missed the fact that the recommended RAMDISK has nothing, at all, to do with RAMFS. It is a completely NEW RAMDISK, based on the QSINIT project (look it up, if you feel that is necessary)...

I think it is you who have completely missed that fact that I am NOT running AOS...so the whole time you have been responding in this thread you are making a massive assumption that not just myself, but perhaps others as well, Ben for example, are running AOS. Meanwhile, I have clearly stated that I have not deployed AOS, I am running W4.52 FP6, 201SMP kernel (if you must know).

Sooo...that means the following:

1) QSINIT is not part of my install, unless i manually deploy it, which I have not done
2) RAMFS package deployed on my machine is composed of two elements:
- RAMFS.IFS
- RAMDISK.EXE

Therefore, given the above and having hopefully set the matter straight, is it starting to come together that regardless of what you say here, unless I have AOS deployed and can test/verify/assess I simply can not deploy your suggested setup regardless of how many times you tell me "...RAMDISK has nothing, at all, to do with RAMFS. It is a completely NEW RAMDISK...".

943
Setup & Installation / Re: RAM disk and temp folders...what else?
« on: April 15, 2018, 05:33:15 pm »
Hey Ben!

I am just wondering if I have this straight; is the RAMDISK.exe that comes with the RAMIFS the same RAMDISK.exe that comes with ArcOS?

There seems to be some debate....

LOL, great question...that was precisely what I was pointing out in my previous response to Doug's recommendation to use just RAMDISK.EXE. The RAMFS package which I have installed here is composed of:

1) RAMFS.IFS
2) RAMDISK.EXE

The README specifically instructs you to deploy RAMFS.IFS and use RAMDISK.EXE for the more "advanced" features, literally, here is the quote from the document:

Code: [Select]
...
Installation and use
~~~~~~~~~~~~~~~~~~~~
Add "IFS=d:\path\RAMFS.IFS" to CONFIG.SYS and reboot. During boot, it will
show a short version message.

Then, from an OS/2 prompt, use RAMDISK.EXE to create a RAM drive. To create a
drive R:, type "RAMDISK R:" To have a RAM drive created at every boot, you
can add "CALL=d:\path\RAMDISK R:" to CONFIG.SYS.
...

I have AOS 5.0.2 here, so all my comparisons are done against the install media only (no actual live installation) and all I can find is the RAMDISK.EXE file. Comparing that file to the one included in the RAMFS package yields a match, so they are the same files.

My suspicion therefore is that the use of RAMDISK.EXE is meant to allow you to create additional ramdisks following system boot, since you clearly could not mount RAMFS.IFS once you are up-and-running. That makese sense.

So my question is: can someone look up the details of the AOS configuration? As Dave Yeo pointed out:

Quote
...Under System Setup, there is a ramdisk icon, this will allow you to use the memory above 4GB...

???

944
Internet / Re: Firefox and Traps
« on: April 15, 2018, 05:14:40 pm »
Hi Ben,

...If I have duplicate dlls on my system they are well hidden; is there a program that can search for duplicate DLLs? Whichdll only tells you which dll is loaded as the name declares...

I see BS_Info has been brought up, an alternative is a really simple scan utility called 'dupfind.cmd', here is the link to Hobbes (http://hobbes.nmsu.edu/download/pub/os2/util/system/dupfind-v1.1.zip).

You could do something like this @ CLI: 'dupfind drive: *.dll', this would look for duplicate DLLs only on your 'drive:', where of course 'drive:' is replaced by your boot drive, so c:, maybe d: or as in my case g:, I hope this is self-explanatory.

I used this handy util with great success to simplify my move from the home-grown DLL management environment to YUM/RPM driven one.

945
Applications / Re: VirtualAddressLimit
« on: April 15, 2018, 01:47:14 am »
Doug,

Hi Doug. How much memory does your video card have? Possibly that is why you need such a low virtualaddresslimit setting. IIRC, there is a way to lower usage, I think Dariusz has experience in that.

...follow-up to Dave's post above.

I am using SNAP, my ATI X850 PE card has 256MB on-board memory, but I have this lowered to just 32MB to free up the remaining memory, otherwise SNAP will grab that from the available OS/2 pool.

If you are also using SNAP use the following command @ CLI: 'gaoption vidmem 32'. To confirm that this is active issue the following command 'gaoption show', which will show you all SNAP options, you are specifically looking for the following output (in-between ==> x <== below):

Code: [Select]
Options for ATI Radeon X850 Series (device 0):

  Invert .................. Off
  Rotation ................ Off
  Flipped ................. Off
  Reduced DVI Timings...... Off
  Prefer 16 bit per pixel.. On
  Prefer 32 bit per pixel.. On
  Compressed Framebuffer... On
  Allow DDC BIOS........... On
  PCI bus mastering........ On
  Video memory packets..... On
  Hardware acceleration.... Full
  Multi Head Display....... Off
  VESA DPVL Mode........... Off

Global options for all devices:

  Force VBE Fallback ...... Off
  Force VGA Fallback ...... Off
  Allow non-certified ..... On
  Disable write combining . Off
  Use BIOS for LCD panel... Auto
==>  Video Memory Limit....... 32 Mb <===
  Shared AGP memory size... 4096 Kb
  Use system memory driver. Off
  Disable DDC detection.... Off
  Enable AGP FastWrite..... Off
  Maximum AGP data rate.... 8X
  Virtual Display.......... Off

I am running VIRTUALADDRESSLIMIT=2560 on my machine, 3072 boots as well, but I have to seriously downsize the HPFS386 cache, which just doesn't make sense for me.

Pages: 1 ... 61 62 [63] 64 65 ... 89