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 ... 38
Hardware / Re: SNAP and dual-head display setup recommendations...
« on: September 19, 2019, 03:41:15 pm »
Ah, one more question for everyone: what interfaces are you using to enable dual-head setups?

What I mean is the following:

1) Head_0 => DVI, Head_1 => RGB (my current config)
2) Head_0 => DVI, Head_1 => DVI (my understanding is that SNAP did not support this on any chipsets)

Here is specifically what I am referencing as it appears in the SNAP readme.txt file:

Code: [Select]
Please note that there are some restrictions imposed for MultiHead:

1. Only CRT (15-pin VGA) output is supported for MultiHead at this time.
   You may need to use DVI->VGA connectors on some graphics cards.  The
   only exception to this is the ATI Radeon chipsets, which can also do
   multihead in CRT+DFP configurations, due to native panel programming.
   CRT+LCD, CRT+TV, and DFP+DFP are all unsupported at this time.

My experience matches this, I'm curious what others have seen?

Hardware / Re: SNAP and dual-head display setup recommendations...
« on: September 19, 2019, 03:18:04 pm »
Hi ivan!

Now if SNAP would work with the Radeon Vega 8 Graphics of the Ryzen processor I could get back to what I used to have on my old computer, a couple of 28 inch 1920x1200 monitors.

SNAP is not happy with the Vega graphics and Panorama works as long as I don't want to do anything with extensive graphics activity.

You know, why I have been relying on my ancient (by today's standards anyways) ATI X850 XT PE video card to cover my OS/2 display needs, it is very clear that this hardware has exhausted all of it's power.

I have seen some feedback on the benefits of running the trully new hardware in native VESA mode (providing that the BIOS supports it) with something like the Panorama driver, end rsult being performance that is actually much better than the older hardware which had the optimized/accelerated device drivers (SNAP).

Since you seem to have Panorama working with at least a single display, how are you finding that performance in comparison to the SNAP driver setup?

Oh and regarding the extended graphics with Panorama, it is my understanding that there are 3rd party screen extenders that have been developed to enable this specific functionality...have you tried them?

Hardware / Re: SNAP and dual-head display setup recommendations...
« on: September 19, 2019, 03:12:12 pm »
Hi Doug!

I have a dual head display and it changed my life.

After getting the memory used by SNAP adjusted (down) to what was really needed, I haven't really had any issues...

I couldn't agree more...LOL, which is why it still kind of boggles my mind why we have not spent any more time/$$$ on getting us updated SNAP or expanded Panorama functionality (by that I mean native support for dual-head configuration as opposed to relying on 3rd party screen extenders, etc.). I understand that required funding, an for my part was always happy to support that specific feature with a real additional-cost funding...I just wish someone would take it on.

Agree with the application behaviour findings, seeing the same here.

Hardware / SNAP and dual-head display setup recommendations...
« on: September 17, 2019, 03:28:05 pm »
Hi Everyone,

So I got my dual-monitor setup up and running: ATI X850 Pro with two Samsung 245T panels. With their native resolution of 1920x1200 that gives me an OS/2 Desktop of 3840x1200...yey!!!

...but as I'm starting to discover there are some things that aren't quite biggie any of them (no hard errors or app crashes, more of an annoyance), but I'm looking for suggestions and/or helpfull hints that others with such dual-head setups have found beneficial.

Currently using the option to display pop-up windows on Head_0.


Networking / Re: NcFTP - RPM package application not quite right...
« on: September 15, 2019, 05:36:36 pm »
Hi Dave,

Try SET PAGER=less.exe

I've got this already in-place, or to be precise, the MAN page reader defaults to using 'less.exe', the other option was to actually set it to MORE, which I did not do.

But...just to be sure I did define that in the CLI window and started NcFTP from there. Issuing 'bookmarks' command still resulted in MORE being used, so it would appear NcFTP itself is coded to rely on MORE as opposed to the 'SET PAGER=' setting. That's OK, I now actually have visibility to the bookmarked FTP sites, which was previously broken.

Thanks for the suggestion though!

Networking / Re: NcFTP - RPM package application not quite right...
« on: September 09, 2019, 02:45:08 pm »
So after initially posting this off I went looking at this 'MORE' command...heck, I do know it works, I have used it previously, pretty much as the default until 'less' became available!

For some reason, not sure why, was missing from my boot drive..ugh??? :o

Luckily I had an older backup partition still kicking around and pulled that one over. Indeed, now NcFTP certainly works because the 'sh' shell commmand issues a 'more' statement which is intended to scroll the bookmarks contents.

You are right though Dave, I wish I could tweak that to use 'less' because that approach has some additional functionality that 'more' does not.

Hey Doug,


Personally, I wouldn't call that driver "stable", in any sense of the word...

Fair, but in my experience that is THE driver that works on my hardware. I find the device driver support rather lacking (even through AN) and given my previous experience of working several tickets (SNAP and Panorma, none of which went anywhere) I decided to avoid that approach altogether.

Look, given that David isn't having much luck with the latest and greatest MMRE drivers it would seem to me like an alternative approach is what's required, even if that means having an obsolete driver that actually works better than the generic & latest MMRE one!  :P

Networking / NcFTP - RPM package application not quite right...
« on: September 09, 2019, 02:19:19 am »
OK, so continuing on with my "mission" ::) to deploy RPM replacements for some of my current apps I decided to tackle NcFTP. Easy app I thought, and being CLI it was pretty suitable for being tossed into the giant \usr\bin bucket...

Install went fine, I moved my bookmarks, etc. to the \home\.ncftp directory, that was recognized. However, strangely enough I ran into a problem when actually attempting to VIEW the bookmarks in the app. Case in point, when issueing 'bookmarks' command inside NcFTP window I get the following response:

Code: [Select]
ncftp> bookmarks
sh.exe: 1: more: not found

To use a bookmark, use the "open" command with the name of the bookmark.

...but if I do something like "open hobbes" that certainly the bookmarks are there and are being recognized. The separate bookmarkmanager app works fine, that does actually show the bookmarks and allow you to manipulte then as needed.

Alright, so that error message appeared to have something to do with the 'sh' shell and perhaps 'more' command? I confirmed that 'sh' is installed here and working fine, 'more' on the other hand is not. But the 'more' is just a guess on my part, one could easily confuse that for something like 'dir | more', right?

What is a bit weird is that the 'more' command is something that should be executable in OS/2 to start off with. You can certainly pull up HELP on that command and yet trying 'more' by itself @CLI only shows:

Code: [Select]
SYS1041: The name more is not recognized as an
internal or external command, operable program or batch file.

So am I inherently missing something here in my base OS/2 install?

Can you specify 'the last stable Realtek driver'?

Ahh....of course, sorry...rushed through that response having focused on the PCI Device_ID, should have posted the driver info to start off with.

OK, here it is:

Code: [Select]
[G:\ibmcom\macs]dir R8169.OS2

The volume label in drive G is OS2.
The Volume Serial Number is 45B6:75C3.
Directory of G:\ibmcom\macs

 9-03-15   3:26p     53724           0  r8169.os2
        1 file(s)      53724 bytes used
                 155185074 K bytes free

[G:\ibmcom\macs]bldlevel r8169.os2
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#Arca Noae LLC:1.0.2#@##1## 3 Sep 2015 15:26:18      DAZAR1
 ::::2::SVN48@@Realtek 8169/1Gb PCIe MAC Driver Copyright (c) 2014 Arca Noae LLC

Vendor:          Arca Noae LLC
Revision:        1.00.2
Date/Time:       3 Sep 2015 15:26:18
Build Machine:   DAZAR1
FixPak Version:  SVN48
File Version:    1.0.2
Description:     Realtek 8169/1Gb PCIe MAC Driver Copyright (c) 2014 Arca Noae L

Hi David,

Both are using the latest 32 bit MultiMac from Arca Noae...

I have ran into TRAPs with the newer MMRE drivers, subsequently I went back to the last stable RealTek drivers I had here and all is fine.

PCI reports the following device ID info for my NIC:

Code: [Select]
Vendor 10ECh Realtek Semiconductor Co., Ltd.
 Device 8168h RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller it similar to what you are running? Maybe worth a try to go back to the old RealTek drivers?

Hi Remy, everyone...

...In my case, I set the RWIN to 128480  because the max allowed into inetcfg.ini is not a multiple of MSS (MSS=1460 and MTU=1500 in my case)...

I've played around with these a few times, so far this is my current best-combo:

Code: [Select]

keepalive 60 7800 0 7800 KeepAlive (sec)
tcpswinsize 246723 32768 1024 246723 TCP SendWindow Size
tcprwinsize 246723 32768 1024 246723 TCP RecvWindow Size
udpswinsize 246723 9216 1024 246723 UDP SendWindow Size
udprwinsize 246723 41600 1024 246723 UDP RecvWindow Size
lingertime 120 120 0 65535 Linger Time (sec)
probecnt 8 8 1 8 Number Of KeepAlive Probes
ipforward 0 0 0 1 IP Forwarding flag ON/OFF
mtudiscover 1 1 0 1 TCP Path MTU Discovery ON/OFF
arpkillc 1200 1200 180 15300 ARP Complete TimeOut (sec)
arpkilli 180 180 60 1200 ARP InComplete TimeOut (sec)
lipcstswinsize 246723 10240 1024 246723 LIPC Stream SendWindow Size
lipcstrwinsize 246723 10240 1024 246723 LIPC Stream RecvWindow Size
lipcdgswinsize 246723 2048 1024 246723 LIPC Dgram SendWindow Size
lipcdgrwinsize 246723 4096 1024 246723 LIPC Dgram RecvWindow Size
synattack 0 0 0 1 SYN Attack Flag ON/OFF
syncookie 0 0 0 1 SYN Cookie Flag ON/OFF
firewall 0 0 0 1 FIREWALL ON/OFF
multidefrt 1 1 0 1 Multiple Default Routes ON/OFF
winscale 1 1 0 1 TCP Window Scale ON/OFF
timestmp 0 0 0 1 TCP TimeStamps ON/OFF
realslow 20 20 1 100 TCP TW Q Slow Timeout ticks
perfhttp 1 1 0 1 Fast Path HTTP ON/OFF
tcpttl 64 64 1 255 TCP  TTL (hops)
udpttl 64 64 1 255 UDP  TTL (hops)
icmpttl 64 64 1 255 ICMP TTL (hops)
fragttl 60 60 1 255 Fragment TTL (sec)
reusetw 1 1 0 1 Reuse Time Wait ON/OFF
msl 30 30 1 16384 TCP MaxSegLifeTime (sec)
cc 0 0 0 1 TTCP function ON/OFF
sack 1 0 0 1 Selective ACK ON/OFF

...and here are the SpeedGuide results:

Code: [Select]
« TCP Analyzer Results »
Tested on: 2019.09.07 17:52
IP address:
TCP options string: 020405ac0101040201030302
MSS: 1452
MTU: 1492
TCP Window: 246720 (not multiple of MSS)
RWIN Scaling: 2 bits (2^2=4)
Unscaled RWIN : 61680
Recommended RWINs: 63888, 127776, 255552, 511104, 1022208
BDP limit (200ms): 9869kbps (1234KBytes/s)
BDP limit (500ms): 3948kbps (493KBytes/s)
MTU Discovery: ON
TTL: 48
Timestamps: OFF
IP ToS: 00100000 (32)
    Precedence: 001 (priority)
    Delay: 0 (normal delay)
    Throughput: 0 (normal throughput)
    Reliability: 0 (normal reliability)
    Cost: 0 (normal cost)
    Check bit: 0 (correct)
DSCP (DiffServ): CS1 001000 (8) - class 1 (RFC 2474). Similar forwarding behavior to the ToS Precedence field.

Things are basically maxed-out, the OS2 tcpip stack has been working fine (no traps) and that allows my machine to fly when I do have a connection to a really big pipe. Rarely ever do I actually utilize more than 25% of my 1Gig fibre link though.

Networking / Re: Samba - cached server IP address?
« on: September 06, 2019, 02:07:20 pm »
Yup, lmhosts is the culprit, both of you were right on the money. Thank you for the great pointer!

Now, how did I get to that point?

Well, I have both NetDrive and EVFSGUI installed here. As it turns out the 'Global settings' tab of EVFSGUI shows 'name resolve order' and has 'Manage LMHosts' checked. Subsequently I find the following in the contents of that file:

Code: [Select]
[G:\mptn\etc\samba]type lmhosts
# Created by EVFSGUI Version 2.5.RC7-[2014-11-14] on 29 May 2019 at 21:33:45
# Syntax:
# IP-address             NetBIOS-name     [Role]              NAS              ROUTERDLNA             WINMAIN

So that explains the root cause. Quick fix here produced the result I was looking for.

Now that begs the question: should I, or shouldn't I be using the LMHosts approach? I suspect that given the description in EVFSGUI of how the lmhosts usually ends up producing a faster resolve time I may have actually chosen to use this approach - as opposed to this being the default setting (although I do not know this to be the case for sure).

Right now the 'name resolve order' is set to: lmhosts => wins => host => bcast

I suspect that given my LAN setups it would just as easily work if I had used: host => lmhosts => bcast => wins.

What the 'wins' option allows me to do is to use the WINS resolution instead, but is that of any use? DNS maps TCP/IP host names to IP addresses through the HOSTS file and WINS maps NetBIOS host names to IP addresses. So in a LAN where I have both Linux and Win servers, does WINS belong?

Applications / Re: AVxCAT
« on: September 05, 2019, 04:24:53 am »
Hi Remy,

OK, upgraded but ran into an issue.

At some point in time you developed a new feature for me specifically which allowed me to rely on a file called "owncmd.txt" to insert some OS level calls.

In my case the application would completely freeze the system unless I shut OFF all by 1 CPU core. So in that file I literally placed the following:

Code: [Select]
A @smpoff
B @smpon

Now this was previously working fine, however with this latest update it no longer appears to be utilized. Subsequently my machine freezes immediately as the application attempts to start the video encoding process.

Do you recall whether this functionality is still present in your application, but maybe just some names changed? Or perhaps I need to include any additional setups? I installed the update into the existing installation directory, so all my previous settings were preserved.


Networking / Samba - cached server IP address?
« on: September 05, 2019, 04:08:35 am »
I run static IP addresses on my LAN, all of it served out by the router where the MAC address to IP address assignment is made. Most devices (where possible) are set to DYNAMIC IP, but of course the router serves up the pre-defined static IP out to the device. If that is not possible some devices actually have the IP address set to STATIC and it's directly updated on the device itself.

OK, all good.

The other day we picked up a Google Home Hub Display device, my wife wanted to have something in the kitchen that would serve up the cooking recipes and give her easy access to on-line stuff w/o having to rely on a laptop or another display. Easy enough right?

Well, I pre-allocate my IP blocks per groups of devices, meaning: media devices are lumped into an IP address range, as are the PCs, the mobile devices, and so on.

I needed to make room for the Google Hub and that meant I had to bump my NAS box from it's IP address to something new. No problem there, router was updated, NAS re-booted, it picked up the new IP.

I then updated my HOSTS file to reflect the new addresses, re-booted (just to be safe) only to discover upon a re-boot that my NetDrive mapping would no longer find the NAS box. So off I went investigating and found that if I replace the alias I was using in the NetDrive resource mapping with an actual IP address the connectivity is back up (see this logging in the debug listing below).

That leads me to believe that the Samba client is maintaining a mapping of the actual IP address the alias was previously pointing to and re-using it instead of querrying it up each time.

The question therefore is: does anyone know where that alias to IP address mapping is cached in the Samba configuration?

While the static IP address setup works, I really do not want to use that in the NetDrive resource setups and would prefer to use the alias instead and rely on the HOSTS file driven mapping.

btw: doing 'ping nas' from CLI successfully shows the new IP address, I can also point the browser to that nas box and reach it successfully.

Code: [Select]
Samba client 3.6.0 build 20190324 based on 4.10.6
This build is maintained by netlabs
2019/09/04 21:31:20.24: 9 1: Working with 64 bit fileio NDFS
2019/09/04 21:31:20.38: 9 1: NdpIOCTL init thread
2019/09/04 21:32:00.74: 9 2: NdpCreateConnection in
2019/09/04 21:32:00.74: 9 2: NdpCreateConnection send CONNECT
2019/09/04 21:32:00.74: 1 2: Connecting to \\admin:*********@home:nas\vol1. Master HOME:1
2019/09/04 21:32:05.79: 4 2: Connection to nas failed (Error NT_STATUS_IO_TIMEOUT)
2019/09/04 21:32:05.79: 9 2: NdpCreateConnection [0] 87
2019/09/04 21:32:05.79: 9 2: NdpCreateConnection in
2019/09/04 21:34:37.75: 9 2: checkMountResource in tid#2
2019/09/04 21:34:37.75: 1 2: Connecting to \\admin:*********@home:nas\vol1. Master HOME:1
2019/09/04 21:34:42.77: 4 2: Connection to nas failed (Error NT_STATUS_IO_TIMEOUT)
2019/09/04 21:34:42.77: 9 2: NdpMountResource rc=58
2019/09/04 21:43:58.58: 9 2: NdpMountResource in
2019/09/04 21:43:58.58: 9 2: dircache_create: 10 seconds, 32 entries
2019/09/04 21:43:58.58: 9 2: dircache_create: 0x6d3f20, rc = 0
2019/09/04 21:43:58.58: 9 2: checkMountResource in tid#2
2019/09/04 21:43:58.58: 1 2: Connecting to \\admin:*********@HOME:\vol1. Master HOME:1
2019/09/04 21:43:58.59: 4 2: Server supports NT1 protocol
2019/09/04 21:43:58.62: 4 2:  session setup ok. Sending tconx <vol1> <********>
2019/09/04 21:43:58.63: 4 2:  tconx ok.
2019/09/04 21:43:58.63: 9 2: NdpMountResource rc=0
2019/09/04 21:43:58.63: 9 2: NdpRsrcQueryInfo in
2019/09/04 21:43:58.63: 9 2: NdpRsrcQueryInfo 0
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo in
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo 0
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo in
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo 0
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo in
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo 0
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo in
2019/09/04 21:43:58.81: 9 1: NdpRsrcQueryInfo 0
2019/09/04 21:44:05.21: 9 2: NdpCreateConnection in
2019/09/04 21:44:05.21: 9 2: NdpCreateConnection send CONNECT
2019/09/04 21:44:05.21: 1 2: Connecting to \\admin:*********@HOME:\vol1. Master HOME:1
2019/09/04 21:44:05.22: 4 2: Server supports NT1 protocol
2019/09/04 21:44:05.23: 4 2:  session setup ok. Sending tconx <vol1> <********>
2019/09/04 21:44:05.24: 4 2:  tconx ok.

Pages: [1] 2 3 ... 38