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.
Pages: [1] 2
1
Programming / Re: Openssl 3.0.2, Ubuntu22: Could not locate entry point 'SSL_get_peer_certificate'
« on: October 19, 2022, 08:35:52 AM »
Looks like I was able to simply download openssl, compile it and just point the libraries to it and it seems to be working, let me do some more tests. Thanks!
set PXP_CRYPTO_LIB=....
set PXP_SSL_LIB=...
set PXP_CRYPTO_LIB=....
set PXP_SSL_LIB=...
2
Programming / Re: Openssl 3.0.2, Ubuntu22: Could not locate entry point 'SSL_get_peer_certificate'
« on: October 18, 2022, 09:18:34 PM »
Thanks Mike, no real urgency, I was just upgrading and I figure why not go to Ubuntu's latest. I can wait for 2023 I suppose. I just wasn't sure if it was something I was doing wrong because the document said pvxplus supported 3.0.2 SSL.
3
Programming / Openssl 3.0.2, Ubuntu22: Could not locate entry point 'SSL_get_peer_certificate'
« on: October 18, 2022, 07:55:05 PM »
Hi, I'm going from obsolete to latest greatest 
root@art-orion:/lib# openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
I linked :
/lib/libssl.so -> /lib/x86_64-linux-gnu/ibssl.so.3
/lib/libcrypto.so -> /lib/x86_64-linux-gnu/libcrypto.so.3
I am getting this error opening a secure channel:
-}OPEN (1) "[tcp]www.pvxplus.com;443;secure"
Error #99: Feature not supported
Last IO to [tcp]www.pvxplus.com;443;secure, channel 1
Could not locate entry point 'SSL_get_peer_certificate' in libssl library.
Likely an incompatible SSL Interface. (err/ret=0/0)
I see 3.0.2 is supported is that windows only? Or do I just need to wait for pvxplus built for ubuntu 22? Thank for your time.
root@art-orion:/lib# openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
I linked :
/lib/libssl.so -> /lib/x86_64-linux-gnu/ibssl.so.3
/lib/libcrypto.so -> /lib/x86_64-linux-gnu/libcrypto.so.3
I am getting this error opening a secure channel:
-}OPEN (1) "[tcp]www.pvxplus.com;443;secure"
Error #99: Feature not supported
Last IO to [tcp]www.pvxplus.com;443;secure, channel 1
Could not locate entry point 'SSL_get_peer_certificate' in libssl library.
Likely an incompatible SSL Interface. (err/ret=0/0)
I see 3.0.2 is supported is that windows only? Or do I just need to wait for pvxplus built for ubuntu 22? Thank for your time.
4
Web Services / Re: Pvxweb File Upload
« on: March 29, 2022, 10:43:44 AM »
Thanks for the ideas Mike! Perfect.
Martin
Martin
5
Web Services / Pvxweb File Upload
« on: March 26, 2022, 05:28:17 PM »
Is there a way to receive a file with the pvxweb server? (Web browser uploads file to pvxweb serevr)
I was able to do it by using apache and PHP, but I was curious if I can handle the POST of the binary file through the pvxweb server alone?
Thanks.
I was able to do it by using apache and PHP, but I was curious if I can handle the POST of the binary file through the pvxweb server alone?
Thanks.
6
Thin Client/WindX / Windows 11 - strange window sizes with older windx/
« on: December 06, 2021, 11:51:43 AM »
Having lots of issues with an older pvx 5.14 windx on windows 11. Anyone else notice this as well? Mostly maximizing, extends larger than the screen all the time.
I tried the newer windx which helped running on older server. I guess its time to upgrade?
I tried the newer windx which helped running on older server. I guess its time to upgrade?
7
General Announcements / Re: PxPlus 2021 Release Candidate 1 now available
« on: June 01, 2021, 10:30:29 PM »
Great release! How many users (using Webster+) for example a 2-3 license support comfortably? Is this similar to the pvxplus web server task handler in terms of capability? I'd imagine the pvxweb server is slightly more responsive but I am interested. Thanks.
8
Programming / Re: New Linux Versions = Decreased performance?
« on: December 29, 2020, 10:38:50 PM »
Bingo! We got it Mike!
I can't believe the performance hit this has resulted in.
There are ways to disable the fixes on the linux kernel which are available by research but I won't post those there due to security. However I am glad the reason was found. I am personally surprised at the level of impact it has on pvx. It's probably because pvx is so fast as well that its a full single thread process that any delays are exasperated.
I had updated my ubuntu16 test machine and afterwards it too was patched and began to have the slow down.
Even though the test example I gave was an extreme case, I did notice a noticeable performance hit across the board. Now in order to overcome these fixes, one needs to purchase newer hardware that are not affected by these security flaws.
Thanks again for your help on this, I'm not sure if this will help others or just help answer my stubbornness to understand the issue. At least I have some baselines and examples to compare with now.
Have a great new years
I can't believe the performance hit this has resulted in.
There are ways to disable the fixes on the linux kernel which are available by research but I won't post those there due to security. However I am glad the reason was found. I am personally surprised at the level of impact it has on pvx. It's probably because pvx is so fast as well that its a full single thread process that any delays are exasperated.
I had updated my ubuntu16 test machine and afterwards it too was patched and began to have the slow down.
Even though the test example I gave was an extreme case, I did notice a noticeable performance hit across the board. Now in order to overcome these fixes, one needs to purchase newer hardware that are not affected by these security flaws.
Thanks again for your help on this, I'm not sure if this will help others or just help answer my stubbornness to understand the issue. At least I have some baselines and examples to compare with now.
Have a great new years
9
Programming / Re: New Linux Versions = Decreased performance?
« on: December 29, 2020, 07:19:52 PM »
I also did another test by creating a ramdisk and transferred the test file to the ramdisk and the results were exactly as when the file is fully cached, no improvement.
I looked into some of the kernel tuning parameters, and I can't find anything to really get this to go any faster like the earlier kernels.
I looked into some of the kernel tuning parameters, and I can't find anything to really get this to go any faster like the earlier kernels.
10
Programming / Re: New Linux Versions = Decreased performance?
« on: December 29, 2020, 04:05:35 PM »
Thanks Mike, I checked the free -m on two of them both appear to fill up the cash properly during the test and remain as I re-test. I see no disk access during the tests.
The reason I am reporting this, is I notice across the board performance reduction, though it may not be as 'apparent' to the average user.
ubuntu 12:
total used free shared buffers cached
Mem: 7890 1056 6834 0 17 883
-/+ buffers/cache: 155 7735
Swap: 8092 0 8092
ubuntu 20:
total used free shared buff/cache available
Mem: 7865 171 6688 2 1005 7447
Swap: 8191 0 8191
The reason I am reporting this, is I notice across the board performance reduction, though it may not be as 'apparent' to the average user.
ubuntu 12:
total used free shared buffers cached
Mem: 7890 1056 6834 0 17 883
-/+ buffers/cache: 155 7735
Swap: 8092 0 8092
ubuntu 20:
total used free shared buff/cache available
Mem: 7865 171 6688 2 1005 7447
Swap: 8191 0 8191
11
Programming / New Linux Versions = Decreased performance?
« on: December 29, 2020, 02:04:58 PM »
Hey everyone, I am in the process of upgrading one of our servers and I have noticed a decrease in performance from newer versions of Linux.
To perform this test I have a large file and doing a basic read cycle test. The file contains:
Maximum Record size ..........: 256 (Variable)
Maximum # records ............: (No limit)
Current # records ............: 1867559
Size of key block ............: 4096 bytes
Record Expansion factor ......: 10%
External key size ............: 0
Alt. key 0 ...................: [1:1:6]+[2:1:8]+[3:1:2]+[4:1:3]+[5:1:5]+[6:1:2]+[7:1:16]
Read Cycle Program:
0010 BEGIN
0020 PRINT DTE(0:"%hz:%mz:%sz")
0030 OPEN (1)"/home/martin/TESTFILE"
0040 LET X$=KEY(1,END=0099)
0050 READ (1,KEY=X$)A$
0060 T++
0070 GOTO 0040
0099 PRINT DTE(0:"%hz:%mz:%sz")
The important part of this test is that it is to be run *MULTIPLE* times to fill the memory. Usually two passes complete filling the memory. Afterwards zero disk access is used, it's all memory based. This eliminates the disk-io variable from the test.
Test Results:
All tests were done with pvx17 64-bit and the same hardware, however I've seen the same results with older providex as well.
So my current conclusions are something has happened around the 4.4+ kernel that seems to be causing this as you can see a 5 second difference between 16.04 and 18.04. I'm not sure what the solution is yet, as I have just discovered this after numerous tests, I'd like to hear from the staff at pvxplus before I do any more tests.
Thanks for any thoughts,
Martin
To perform this test I have a large file and doing a basic read cycle test. The file contains:
Maximum Record size ..........: 256 (Variable)
Maximum # records ............: (No limit)
Current # records ............: 1867559
Size of key block ............: 4096 bytes
Record Expansion factor ......: 10%
External key size ............: 0
Alt. key 0 ...................: [1:1:6]+[2:1:8]+[3:1:2]+[4:1:3]+[5:1:5]+[6:1:2]+[7:1:16]
Read Cycle Program:
0010 BEGIN
0020 PRINT DTE(0:"%hz:%mz:%sz")
0030 OPEN (1)"/home/martin/TESTFILE"
0040 LET X$=KEY(1,END=0099)
0050 READ (1,KEY=X$)A$
0060 T++
0070 GOTO 0040
0099 PRINT DTE(0:"%hz:%mz:%sz")
The important part of this test is that it is to be run *MULTIPLE* times to fill the memory. Usually two passes complete filling the memory. Afterwards zero disk access is used, it's all memory based. This eliminates the disk-io variable from the test.
Test Results:
Code: [Select]
ubuntu server 10.04 = 9 seconds 2.6.32-38-server
ubuntu server 12.04 = 9 seconds 3.2.0-23-generic
ubuntu server 16.04 = 9 seconds 4.4.0-21-generic
ubuntu server 18.04 = 14 seconds 4.15.0-128-generic #131 (running pxp for ub16)
ubuntu server 20.04 = 14 seconds 5.4.0-58-generic #64
debian 10 = 14 seconds 4.19.0-13-amd64
windows10 = 11 seconds 20H2 - 19042.685
All tests were done with pvx17 64-bit and the same hardware, however I've seen the same results with older providex as well.
So my current conclusions are something has happened around the 4.4+ kernel that seems to be causing this as you can see a 5 second difference between 16.04 and 18.04. I'm not sure what the solution is yet, as I have just discovered this after numerous tests, I'd like to hear from the staff at pvxplus before I do any more tests.
Thanks for any thoughts,
Martin
12
Programming / Re: Can't close window/dialogue (double clicking top-left box)
« on: December 22, 2020, 11:24:37 AM »
Devon, Just related to this, was the Esc key also trapped at some point? It also used to close windows as well.
Thanks,
Martin
Thanks,
Martin
13
Thin Client/WindX / Re: winproc.rsz performance - increasing speed
« on: December 21, 2020, 12:33:27 PM »
Thanks Mike, for commenting. We are using the 'TU' turbo mode and I tried the new '+W' compression.
PS. I could prepare a video comparing the two performances if it would be of value.
PS. I could prepare a video comparing the two performances if it would be of value.
14
Thin Client/WindX / winproc.rsz performance - increasing speed
« on: December 21, 2020, 10:18:47 AM »
Hi, I am still noticing significant performance issues with the *winproc.rsz screen and *winproc. I've seen this issue in all the PVX routines since version 5 and it's never been addressed. In fact the performance is getting slower and slower as more features get added, which is both understandable but also concerning.
This is mostly due to having a panel that is resized on start up with the *winpnl functionality and an automatically 'maximized' window. (There are a few other routines in *winproc that can help as well)
Removing the GOSUB CHECK_MANUAL_MANIPULATION almost doubles the speed right away which is a great improvement (if you do not need that functionality)
If you are testing this on a local network you will not experience this as bad however its slightly visible.
On an internet connection it is very apparent (even a fast low latency connection).
With my panel example (Folder panel, automatically maximized via *winpnl)
Currently: pxplus has an 8 second delay.
Currently: pxplus with check_manual_manipulation removed: 4 seconds
Older PVX5.14: My screens at a snappy 2 second delay.
This is easily reproduced on the simple client server.
Thinking forward, perhaps I can eliminate the maximize feature and redraw the screen at a higher resolution however it would be nice if the response/packets could be improved. It's been many years and the problem is still there.
Thanks for your time.
This is mostly due to having a panel that is resized on start up with the *winpnl functionality and an automatically 'maximized' window. (There are a few other routines in *winproc that can help as well)
Removing the GOSUB CHECK_MANUAL_MANIPULATION almost doubles the speed right away which is a great improvement (if you do not need that functionality)
If you are testing this on a local network you will not experience this as bad however its slightly visible.
On an internet connection it is very apparent (even a fast low latency connection).
With my panel example (Folder panel, automatically maximized via *winpnl)
Currently: pxplus has an 8 second delay.
Currently: pxplus with check_manual_manipulation removed: 4 seconds
Older PVX5.14: My screens at a snappy 2 second delay.
This is easily reproduced on the simple client server.
Thinking forward, perhaps I can eliminate the maximize feature and redraw the screen at a higher resolution however it would be nice if the response/packets could be improved. It's been many years and the problem is still there.
Thanks for your time.
15
Programming / Re: Can't close window/dialogue (double clicking top-left box)
« on: December 14, 2020, 01:25:10 PM »
Thanks Devon!
Pages: [1] 2