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 ... 32 33 [34] 35 36 ... 89
496
Hardware / Re: Snap Vs Panorama - Refresh rate problem.
« on: December 20, 2020, 07:15:46 pm »
SNAP and SMP operations...quite possible, but depending on your hardware/software config you may end up with a slow video performance.

Case in point: 850 XT PE video card, non-AOS SNAP release would work quite fine here (accelerated, etc.) but attempting to boot with the full 6 cores of the AMD Phenom II X6 CPU would sause a WPS blue-screen hang.

AOS has released some SNAP updates, their latest ones work perfectly fine with my setup and finally allow the WPS to boot-up with the full 6-cores of the CPU:

Code: [Select]
Graphics device configuration:
  Manufacturer......... ATI
  Chipset.............. Radeon X850 Series
  Bus Type............. PCI Express
  Memory............... 24576 KB
  DAC.................. ATI Internal 24 bit DAC
  Clock................ ATI Internal Clock
  Memory Clock......... 400 MHz
  Default Memory Clock. 400 MHz
  Maximum Memory Clock. 400 MHz
  Driver Revision...... 3.2, Build 29
  Driver Build......... May  2 2017
  Certified Version.... Not Certified

497
Storage / Re: DISKIO - updated version in need of TEST
« on: December 20, 2020, 04:07:40 am »
Hi David,

...
Hard disk 2: 255 sides, 60321 cylinders, 127 sectors per track = 953855 MB
Drive cache/bus transfer rate: -107190 k/sec
Data transfer rate on cylinder 0   : 185943 k/sec
Data transfer rate on cylinder 60319: 87011 k/sec
CPU usage by full speed disk transfers: 35%
Average latency time: 0.0 ms
Average data access time: 15.3 ms
Multithreaded disk I/O (4 threads): 45298 k/sec, 28% CPU usage

Can you run the DEBUG version for this drive?

The 'cache/bus transfer rate' shows overflow and I'm curious what the raw counters actually are.

... It gave an error on the command line, I'm guessing because it detected 5 drives, but there are really only 3 (Drive C: is an SSD, Drive D: is a rotating hard drive, Drive Z: is a RAM drive) but the other 2 are possible USB drives. CDROMs there is only 1 (empty) and the other is also a possible USB drive. Not sure what to make of the results otherwise....

Yeah, I think this is the same issue Martin reported and which I was able to reproduce here. This happens when I run the full DISKIO and it kicks off a test for each storage device without me explicitly specifying which device it should be testing.

Truth be told changing the code to automatically exclude a USB drive (when it's not mounted) is probably beyond my OS/2 coding skillset...but I'll investigate it to learn a thing or two!

Much appreciate the feedback David! Thanks...

498
Storage / Re: DISKIO - updated version in need of TEST
« on: December 20, 2020, 03:59:37 am »
Hi Martin,

...
- Can it be possible to release it as 1.19? so it can not get confused with 1.18z
- Is it possible to share the source code to update the github repository? - once you produce the final release.

Yes, absolutely. For now my focus is on getting as many samples of different hardware as possible. I suspect the really big drives (well, one should not think of a 1T that as being that big anymore...LOL, but David's example below still shows an issue there).

Once the little tweaks are behind us this is of course going out there. My changes are really tiny things, and quite honestly very simple changes from 'int' to 'long' or ULONG variables for the most part.

...
It seems to me that tthe program runs fine (diskio and debug)
But when I try to create an output file this way, I get this error?
Quote
[C:\HOME\DOWNLOADS\DISKIO_FIX_1]diskio-debug >debug.txt

SYS1808:
The process has stopped.  The software diagnostic
code (exception code) is  009B.

Aha...so I wasn't getting this in my tests because I was individually testing just my SSD or HDD devices, but running it just like you did eventually produced the same result. What I found is the following in my POPUPLOG.OS2:

Code: [Select]
12-19-2020  20:49:36  SYS3184  PID 0819  TID 0001  Slot 0125
Y:\TMP\DISKIO.EXE
c000009b
00022182
EAX=00000000  EBX=00000000  ECX=000402ec  EDX=00000000
ESI=00000090  EDI=00000090 
DS=0053  DSACC=f0f3  DSLIM=ffffffff 
ES=0053  ESACC=f0f3  ESLIM=ffffffff 
FS=150b  FSACC=00f3  FSLIM=00000030
GS=0000  GSACC=****  GSLIM=********
CS:EIP=005b:00022182  CSACC=f0df  CSLIM=ffffffff
SS:ESP=0053:00092440  SSACC=f0f3  SSLIM=ffffffff
EBP=000924fc  FLG=00210246

DISKIO.EXE 0002:00002182

...and SYS3184 is a "Divide by Zero".

Looking at where my output from DISKIO stopped it looks like the un-mounted USB removable drive is what caused the problem here. I'm running the DEBUG version right now to see the raw data but I'm sure that pesky 0 (zero) will show up.

In the meantime: thank you for the test and feedback!

499
Storage / DISKIO - updated version in need of TEST
« on: December 20, 2020, 01:46:36 am »
Hi Everyone,

I figured I'd take a stab at resolving the annoying issue with DISKIO not reporting correct throughput rates for the modern hardware, i.e. stuff like the fast SSD devices, etc.

Alright, so to that end, here is a DEBUG run for my SSD (Samsung 850 Evo - OK, I said "modern", yes, it's a few years old  ;), but it's what pushed DISKIO over the edge on my box here):

Code: [Select]
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 2283670 runs/sec

Hard disk 2: 255 sides, 30401 cylinders, 63 sectors per track = 238472 MB
Drive cache/bus transfer rate:
 DEBUG => nData is: 1189762560
 DEBUG => nTime is: 10260
115961 k/sec
Data transfer rate on cylinder 0   :
 DEBUG => nData is: 3087028224
 DEBUG => nTime is: 10264
300762 k/sec
Data transfer rate on cylinder 30399:
 DEBUG => nData is: 2904620544
 DEBUG => nTime is: 10244
283543 k/sec
CPU usage by full speed disk transfers: 23%
Average latency time:
 DEBUG => nTime is: 10036.599360
 DEBUG => nCnt is: 85352.196980
0.1 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): 121669 k/sec, 19% CPU usage

The stuff marked as "DEBUG => " is the raw data, if you're going to run this on your machine please report back the full output.

And here is the RETAIL output:

Code: [Select]
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 2088687 runs/sec

Hard disk 2: 255 sides, 30401 cylinders, 63 sectors per track = 238472 MB
Drive cache/bus transfer rate: 118449 k/sec
Data transfer rate on cylinder 0   : 332803 k/sec
Data transfer rate on cylinder 30399: 302953 k/sec
CPU usage by full speed disk transfers: 23%
Average latency time: 0.1 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): 122717 k/sec, 23% CPU usage

As you can tell, the numbers are much better (no more overflow) and they for the most part jive with what I see in SysBench.

There are a few outstanding issues that I'm aware of:

1) this build is optimized for Pentium2, that's old stuff, I need to either remove or optimize for Pentium4, I just haven't looked up all the ICC flags & options, may be the reason why the Dhrystone value reported by this build is about 50% of what the official build has, not sure yet

2) the "Average data access time: Disk read error" is still here, this only fails on my SSD drive, I need to dig into the DosDevIOCtl API

3) "Drive cache/bus transfer rate:" shows a smaller rate than SysBench, not sure why that is, need to review further

4) RAMDISK numbers are still bad, or just flat out error out

ZIP attachment has two builds :

1) DEBUG - has the extra raw data dumps
2) RETAIL - if you just want an updated (hopefully correct) result and that's all you want

Feedback is welcome and appreciated!

-Dariusz


500
Article Discussions / Re: OS/2 - ArcaOS 64Bits Kernel Discussion
« on: December 17, 2020, 03:44:43 pm »
...It's old and could use a couple of updates, measurement of my fastest drives bus speed is negative so a variable needs to be bigger and it considers too fast of a seek time like the ram disk or SSD to be a disk error but it measures reading track 0 and the last track directly.
There is also a NT binary in the package.

Matching my experience, although the RAMDISK here fails to get most of the metrics:

Code: [Select]
Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 2185936 runs/sec

Hard disk 1: 255 sides, 636 cylinders, 63 sectors per track = 4988 MB
Drive cache/bus transfer rate: 26754 k/sec
Data transfer rate on cylinder 0   : Disk read error.
Data transfer rate on cylinder 634 : Disk read error.
CPU usage by full speed disk transfers: Disk read error.
Average latency time: 0.0 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): Disk read error.
-470888 k/sec, 29% CPU usage

...and numbers for something like my SSD show the obvious overflow errors:

Code: [Select]
Hard disk 2: 255 sides, 30401 cylinders, 63 sectors per track = 238472 MB
Drive cache/bus transfer rate: 115349 k/sec
Data transfer rate on cylinder 0   : -84103 k/sec
Data transfer rate on cylinder 30399: -133819 k/sec
CPU usage by full speed disk transfers: 24%
Average latency time: 0.1 ms
Average data access time: Disk read error.
Multithreaded disk I/O (4 threads): 115870 k/sec, 22% CPU usage

I did compile that source back in April of this year b/c I was trying to look at fixing those little things, and while that did give me a successfull build, more work needed to be devoted to that task...aha...Holidays are here...maybe now???  ;D

501
Hardware / Re: What happened to the hardware database on ecomstation.ru?
« on: December 13, 2020, 03:24:25 pm »
Hmm...not sure, but I did spot the following error message in the corner of the page:

"...Can't connect to MySQL server on '127.0.0.1' (61)Can't connect to local MySQL server through socket '\socket\MySQL' (49)Can't connect to local MySQL server through socket '\socket\MySQL' (49)..."

Given that it's pointing to 127.0.0.1 maybe there is a miss-config somewhere on that box, perhaps the MySQL server/service is down itself?

502
...I am pretty sure that nobody looks at that information, for our ancient version of Firefox anyway.

Even when you're not collecting the FULL bucket of data, the 'about:telemetry' page does have some interesting information, worth a look.

503
Networking / Re: patched AFINETK.SYS: anyone willing to test ?
« on: November 29, 2020, 08:00:58 pm »
Hi Lars,

OK, a bit of an update, not as crystal clear as I have hoped to report though.

So here is the thing:

1) OLD hardware => MSI 880G-E45 motherboard, NIC was:
Code: [Select]
Vendor 10ECh Realtek Semiconductor Co., Ltd.
 Device 8168h RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

2) NEW hardware => MSI 890FXA-GD70, NIC is:
Code: [Select]
Vendor 10ECh Realtek Semiconductor Co., Ltd.
 Device 8168h RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller

By all appearances, the same networking hardware. The motherboard spec sheet also says both are equipped with RealTek 8111DL controller. However, it is different hardware after all since the NIC is in a different motherboard.

So...what did I notice? Well, with the patched AFINETK.SYS and the non-MMRE NIC driver I was fine on the old motherboard (but it was a short test, only about a day or so of usage), basically things seemed like they were working fine. However on the new motherboard I started to see weird non-responsive tcp/ip events. For example, the browser (FF45.9) would just say "...waiting for server to repond..." when attempting to load a page, and yet simply re-loading the very same URL would bring the page up. This happened multiple times, over numerous non-related websites, and across a few re-boots just to rule out a possibility that something else was interfering with the test.

I eventually moved back to the un-patched AFINETK.SYS driver and those events are no longer present. So it feels like something was off...just not sure what to attribute it to?

On the other hand, the MMRE situation is much more clear. When I deployed that NIC driver for my RealTek NIC I ended up with a TRAP in OS2KRNL within 1/2 hr of usage. A few passes of the speedtest worked fine, but on the 3rd attempt it trapped. So that remained consistent on the NEW motherboard hardware with the results I previously saw on the OLD motherboard hardware. The fact that it's still present leads me to conclude that the patches did not address whatever the MMRE driver was having a problem with. Regardless, the patches you produced may never help the MMRE situation to start off with, but it was the only clear symptom that I could watch out for during my testing.

Alright sir, that's all I can report. Happy to test further changes if you want to pursue further Lars!

504
Storage / FAT32 - Netlabs or AN?
« on: November 27, 2020, 08:35:47 pm »
The subject says it all...what have you picked/installed, and why?

I ask b/c I have had the Netlabs 0.9.13 release on my machine from quite some time now. It has worked for me quite well since the extent of using FATanything was to simply pull the pics off of my digital camera. That's a FAT32 card, easy to mount, easy to copy off of, done!

However, as storage capacities got larger and now it's somewhat easy to have a multi-gig FAT device I figured I should perhaps update my install.

Now, here is the decision point: run with the updated Netlabs release, or move over to AN one? If I understood the AN release notes, their goal is to have the basic FAT32 capability, no other fancy stuff. Seems simple enough....but that also appears to really narrow things down to just the stuff that's pure FAT32 as opposed to having capability to mount exFAT, etc.

So I'm curious how others have gone about this? What have you deployed, why and how is that working for you?

Thanks!

505
What version of Thunderbird are you running?

Dave released an update a couple of weeks ago, you can find it on Hobbes. I am running 45.8.0 which came from thunderbird-45.8.0.en-US.os2-Pentium-m-17112020.zip, so far no problems, the update went fine although I did have to add LIBVPX RPM package I think.

506
Programming / Re: MAKEFILES suck!!!
« on: November 26, 2020, 05:10:54 pm »
Hi Lars,

Why don't you dynamically query the number of processors (DosQuerySysInfo with QSV_NUMPROCESSORS) and then allocate the structures dynamically ?
I have a system with 8 cores. I'll then miss all the good things. If that is too complicated, then use 64 entries. That is the absolute maximum that the SMP kernel can handle. Dynamically is preferred, though.

Well, truth be told this CPU-spike issue really belonged in the nuisance category for me. The code itself is fairly complex in a sense that the author developed his own display-cell library (which does appear to be pretty feature-rich), but that also requires you to trully understand how the STATs tracking converts into the display-cell updates, and that is beyond my current level of "wanting" to get it done.

I think you are absolutely right that making this fully dynamic would be the best approach, which is really what I didn't get about the code to start off with as I attempted to understand how the information DosQuerySysInfo provides is being used. There appears to be a real gap here in a sense that this API call is used to determine how many CPUs exist, but beyond that the program logic itself seems to be hard-coded for a max of 4 CPUs.

Given that my current goal has been accomplished I will expand my static fix up to 12 CPUs, which today gets anyone up to that Ryzen 9 5900X level (12 core/24 thread). One of these days, when it is viable to run something like the Threadripper maybe a re-write of this code would be worthwhile, eh?

507
Programming / Re: MAKEFILES suck!!!
« on: November 25, 2020, 05:18:02 pm »
Hi Lars,

if the target of your inference rule is
{.\obj}.obj
then a concrete target would be
{.\obj}\cell.obj
Because this is clumsy,many makefiles define Makros for Source and Object directories.

Yeah, I think I understand that now. I also suspect that the Inference Rules I created cover far too large of a grouping of file extensions, which is why that additional comment you provided below makes that much more sense to me now.

...The same holds for dependencies. As to included h files, apart from being a dependency, they also need to be found by the compiler. That is, you will need to add the -I switch with the proper subdirectory to your compile inference rules....

Well, but you see this already in place because I do have the CC and CFLAGS macros defined and specifically the CFLAGS macro shows the following:

Code: [Select]
CCFLAGS     = -O+ -Oc+ -Ss+ -G5 -Q+ -Gm+ -I..\include

However, what I think is hapening is that I do not end up compiling the individual objects with those flags, instead I use a straight forward '$(CC) /c /Fo$@  $<' and that misses the mark.

So I'll re-define a few more things in my VACPP makefile, I'd like to make this work, if anything it's a great learning experience.

Appreciate the feedback Lars!

508
Programming / Re: MAKEFILES suck!!!
« on: November 25, 2020, 05:10:26 pm »
Hi Dave!

Did you read the readme.txt? To quote from v2-1b166,
Quote
To build PU Monitor from sources, you'll need Watcom C++ 10.6 and
MAKE utility from Borland C++ 2.0 for OS/2 (it is also provided with TASM 4.1).
There are no known dependencies on this tools so you may try to compile
sources by another compiler. All you'll need is to write new MAKEFILE.

I'll attach the BC make I have. You'll have to install OW if you don't already have it, or write a nmake makefile.

Oh yes sure read that file, c'mon...give me a little creadit here  :(. However, excellent question nonetheless, so let me explain: given that 2nd last sentence re: "...may try to compile sources by another compiler..." made me think that I should try my VACPP 3.6.5 install fist - since this is what I normally experiment with. I honestly thought it should be nearly trivial to convert the existing makefile to something that works with VACPP. Not so, so far anyways.

But...since I have BCOS2 installed as well, I took your advice and re-pointed to the BC make.exe as opposed to trying to re-create a native VACPP one, while still using VACPP for the compile and linkage duaties. Indeed sir...excellent idea to re-point the obvious, that succeeded!!!

I was able to compile the app, which then ran successfully. Further on, I made the changes to the code sections which I believe were causing a problem and whala...happy times are here again, PUMonitor works fine now w/o causing the annoying CPU spikes. I extended the existing limit of 4 CPUs out to 6 CPUs (that's applicable to both the global variable that controls the max CPU limit as well as the underlying structs that support the stats tracking for these).

The un-expected ROI is that fact that enabling the Hi-Res Timer for the 'Memory Meter' function no longer causes my uptime counts to get all whacky!!!

Again, thank you for that suggestion.


509
Hardware / Re: Cloning OS2 with different Motherboard
« on: November 25, 2020, 04:52:42 pm »
Matt brought up an excellent point, I'm curious though: are you able to boot to just a CLI instead of bringing up the whole WPS?

I ask because a large part of the drivers today, such as ACPI, HDD stuff (Dani and/or AHCI), maybe even some NIC stuff (MMRE comes to mind) is fairly generic in a sense that it supports a wide range of hardware. There are, and always will be execeptions to this, but in general you should be OK to at least get to CLI.

510
Programming / MAKEFILES suck!!!
« on: November 25, 2020, 04:51:23 am »
...alright, maybe not that badly, I have used them for much smaller projects in the past and they were great, but I'm attempting to compile the PUMonitor utility here and that provided makefile doesn't work with my VAC 3.6.5 install.

So help me out please, my eyeballs are red from reading about NMAKE32 (as opposed to NMAKE), but clearly I'm still confused...LOL!  :-\

Here is what I have:

1) structure of the project source files
Code: [Select]
Directory of G:\code\source\os2\pumonitor\src

11-24-20  9:25a         <DIR>      0 ----  .
 8-25-18  5:42p         <DIR>    369 ----  ..
 2-19-02  1:13p           302      0 a---  build.opt
 8-25-18  5:42p         <DIR>      0 ----  include
 2-19-02  1:13p           105      0 a---  library.rsp
11-23-20 11:50p         2,151     35 a---  makefile
 8-25-18  5:42p         <DIR>      0 ----  obj
11-24-20 10:24p         2,330     35 a---  pumonitor.mak
 8-25-18  5:42p         <DIR>      0 ----  source

Basically the *.c and *.cpp is all in source, *.h and *.hpp in include, and the remaining *.ico, *.rc and *.lib files are in source.

2) 'makefile' is the original makefile distributed with the project source, but despite the fact that it reads like it's meant to work with VAC, it doesn't work with my 3.6.5 setup here

3) 'pumonitor.mak' is my attempt at converting the project sources and the build process as I understand it to be structured in the original 'makefile' into a VAC 3.6.5 version

Sooo...having said that, when attempting to process with NMAKE32 I get the following error:

Code: [Select]
MAK3035: Do not know how to make target 'cell.cpp'.

Now this part is really confusing for me, because if I force the full path for the source files in the target, all works fine, here is the section we are talking about:

Code: [Select]
cell.obj    : cell.cpp .\include\cell.h .\include\cvars.h .\include\util.h

...substituting with

Code: [Select]
cell.obj    : .\source\cell.cpp .\include\cell.h .\include\cvars.h .\include\util.h

...now allows me to pass that test but still fails with the following:

Code: [Select]
MAK3035: Do not know how to make target 'cell.obj'.

...which of course can be addressed if I provide an explicit command, such as:
Code: [Select]
$(CC) /c /Fo$@  $<

...then compiles, although it still producs a pile of errors:

Code: [Select]
...
icc.exe /c /Focell.obj .\source\cell.cpp
IBM* C and C++ Compilers for OS/2*, AIX* and for Windows NT**, Version 3.6
(C) Copyright IBM Corp. 1991, 1997   All Rights Reserved.
* registered trademarks of IBM Corp., ** registered trademark of Microsoft Corp.

.\source\cell.cpp(19:10) : error EDC3008: Source file <cell.h> cannot be opened.
.\source\cell.cpp(20:10) : error EDC3008: Source file <cvars.h> cannot be opened.
...

All of this begs the question: why isn't my Inference Rule working? It clearly spells out where to find all the *.h and *.hpp files....so what gives?

Here is the Inference Rule section in my makefile:

Code: [Select]
# The Make utility looks in the directory specified by frompath for files with the fromext extension.
# It executes the commands to build files with the toext extension in the directory specified by topath.
# {frompath}.fromext{topath}.toext
# commands
# :

{.\source}.c{.\obj}.obj:
    $(CC) /c /Fo$@  $<
   
{.\source}.cpp{.\obj}.obj:
    $(CC) /c /Fo$@  $<
   
{.\source}.lib{.\obj}.obj:
    $(CC) /c /Fo$@  $<
   
{.\source}.rc{.\obj}.res:
    $(RC) /r $< $@
   
{.\include}.h{.\obj}.obj:
    $(CC) /c /Fo$@  $<

{.\include}.hpp{.\obj}.obj:
    $(CC) /c /Fo$@  $<

This is far beyond anything I've tried before...so obviously I'm lost!!! lol

Pages: 1 ... 32 33 [34] 35 36 ... 89