Author Topic: LarsenCommander - new test version  (Read 14775 times)

Andi B.

  • Hero Member
  • *****
  • Posts: 818
  • Karma: +11/-2
    • View Profile
Re: LarsenCommander - new test version
« Reply #15 on: December 03, 2023, 11:13:01 am »
Just a quick not about -
Quote
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

On Samba shares I can not get more then about 36MBytes/s. No matter what the other system is running. I think this is limited by our netdrive/samba client setup. It's not the GBit network. You can check with ftp to the same system and will get something more close to 1GBit (80-90MByte/s IIRC).

Ramdisk - writting to our RAMDISK is not more than about 55MBytes/s here. It would be faster when using strategy 1 but this would limit to <2GB and does have other big problems which is the reason I stick without /1.

I wonder about your really fast SATA performance. I've tested here with Samsung 850 Pro, Samsung EVO 870, Samsung 860 QVD and various HDDs including my WD black. It seems my 9 year old 4 core system can not handle more than about 160MBytes/s. So I currently I can't test with systems as fast as yours.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1324
  • Karma: +26/-0
    • View Profile
Re: LarsenCommander - new test version
« Reply #16 on: December 03, 2023, 06:53:15 pm »
Andi,

...
On Samba shares I can not get more then about 36MBytes/s. No matter what the other system is running. I think this is limited by our netdrive/samba client setup. It's not the GBit network. You can check with ftp to the same system and will get something more close to 1GBit (80-90MByte/s IIRC).

Totally agree, here is what Kai Uwe Rommel's excellent NETIO utility reports ('orclsrvr' is my Win7Pro box on the LAN):

Code: [Select]
[G:\]netio -t orclsrvr

NETIO - Network Throughput Benchmark, Version 1.30
(C) 1997-2008 Kai Uwe Rommel

TCP connection established.
Packet size  1k bytes:  108.65 MByte/s Tx,  82.77 MByte/s Rx.
Packet size  2k bytes:  109.66 MByte/s Tx,  108.81 MByte/s Rx.
Packet size  4k bytes:  108.43 MByte/s Tx,  111.03 MByte/s Rx.
Packet size  8k bytes:  106.60 MByte/s Tx,  105.70 MByte/s Rx.
Packet size 16k bytes:  104.48 MByte/s Tx,  9.06 MByte/s Rx.
Packet size 32k bytes:  110.89 MByte/s Tx,  111.15 MByte/s Rx.

So the pipe is big enough, althought the severe drop with the 16k packet is always there, but otherwise it's pretty much using the full Gig.

Just to stay consistent in my testing (given that the network throughput is being tested against a different box - not the NAS one) I re-ran the same test but just with the NEW LCMD version:

1) from SAMBA WIN7 share to ramdisk
NEW: Peak=74,012K, Avg=50,996K

The NAS box is just a little slower, although I do NOT see this when moving stuff between the Win7 and NAS boxes, so that tells me it is indeed our Samba client.

...Ramdisk - writting to our RAMDISK is not more than about 55MBytes/s here. It would be faster when using strategy 1 but this would limit to <2GB and does have other big problems which is the reason I stick without /1.

I wonder about your really fast SATA performance. I've tested here with Samsung 850 Pro, Samsung EVO 870, Samsung 860 QVD and various HDDs including my WD black. It seems my 9 year old 4 core system can not handle more than about 160MBytes/s. So I currently I can't test with systems as fast as yours.

For my RAMDISK I just have the following in my CONFIG.SYS:

'BASEDEV=HD4DISK.ADD /V'

...and my QSSETUP.CMD shows:

'ramdisk Y: jfs'

It's been a while since I was testing the performance of that configuration...probably not since I moved from HPFS386 to JFS actually.

Here are the DISKIO metrics for my SSDs:

1) Evo 850
Quote
[G:\]diskio -hd 2
DISKIO - Fixed Disk Benchmark, Version 1.20

Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 6089057 runs/sec

Hard disk 2: 255 sides, 30401 cylinders, 63 sectors per track = 238472 MB
Drive cache/bus transfer rate: 129526 k/sec
Data transfer rate on cylinder 0   : 349038 k/sec
Data transfer rate on cylinder 30399: 318076 k/sec
CPU usage by full speed disk transfers: 6%
Average latency time: 0.1 ms
Average data access time: Disk read error.

Multithreaded disk I/O (4 threads):
 124476 k/sec, 4% CPU usage

and here is the Evo 860
Quote
[G:\]diskio -hd 4
DISKIO - Fixed Disk Benchmark, Version 1.20

Dhrystone 2.1 C benchmark routines (C) 1988 Reinhold P. Weicker
Dhrystone benchmark for this CPU: 6047660 runs/sec

Hard disk 4: 255 sides, 15960 cylinders, 240 sectors per track = 476929 MB
Drive cache/bus transfer rate: 151264 k/sec
Data transfer rate on cylinder 0   : 373430 k/sec
Data transfer rate on cylinder 15958: 384912 k/sec
CPU usage by full speed disk transfers: 21%
Average latency time: 0.0 ms
Average data access time: 0.3 ms

Multithreaded disk I/O (4 threads):
 216995 k/sec, 29% CPU usage

My box is pretty ancient by today's standards as well (MSI 890FXA-GD70), but it has SATA3 SB850 controller, which did make a difference when I moved to that motherboard from my old SATA2 controller one.

...but anyways, that's just a tanget to this core LCMD changes feedback.
« Last Edit: December 03, 2023, 07:15:33 pm by Dariusz Piatkowski »

Andy Willis

  • Sr. Member
  • ****
  • Posts: 292
  • Karma: +7/-0
    • View Profile
Re: LarsenCommander - new test version
« Reply #17 on: December 05, 2023, 06:45:03 am »
Thank you for your work.
I pulled the source from git and find there were build changes:
call envtk45.cmd -noansi
call envicc40.cmd $ -noansi
These cmd files are not in the repository and I do not have them in my build environment.  Are these files you built or should I have them in my environment?


Andi B.

  • Hero Member
  • *****
  • Posts: 818
  • Karma: +11/-2
    • View Profile
Re: LarsenCommander - new test version
« Reply #18 on: December 05, 2023, 09:20:58 am »
Thank you for your work.
I pulled the source from git and find there were build changes:
call envtk45.cmd -noansi
call envicc40.cmd $ -noansi
These cmd files are not in the repository and I do not have them in my build environment.  Are these files you built or should I have them in my environment?
Thanks for testing the new repository. Obviously I've checked in some local changes I made long ago which I have never updated in the svn.
envtk45.cmd and envicc40.cmd are my local files similar to the setenv* commands for toolkit 45 and vacpp40. But instead changing to fixed inc/lib/paths I check before if the needed files are accessible and only add the new paths when they are not already set. So this is only to ensure that the proper toolkit and compiler environment is set.

I wonder if I should add these files to the repository cause they are kind of quick and dirty REXX scripts. And they include my fixed drive/path settings. Maybe I should rem them out in the repo. If you wonder about the -noansi - this is for running them within Slickedit to suppress the colored output which is funny for running from 4os2. I think in the Linux world the -color option would be the more common term for such behavior. You may found out I usually compile within Visual Slickedit calling vs_make.cmd by simply pressing <F5> (Project properties - Build options....).

Alfredo Fernández Díaz

  • Jr. Member
  • **
  • Posts: 55
  • Karma: +0/-0
    • View Profile
Re: LarsenCommander - new test version
« Reply #19 on: December 05, 2023, 03:32:36 pm »
I'm glad to to see LC actively developed once again. Thank you, Andi - will be giving it a spin : )
Quick question - is NLS functional?

Andi B.

  • Hero Member
  • *****
  • Posts: 818
  • Karma: +11/-2
    • View Profile
Re: LarsenCommander - new test version
« Reply #20 on: December 08, 2023, 10:58:16 am »
I'm glad to to see LC actively developed once again. Thank you, Andi - will be giving it a spin : )
Quick question - is NLS functional?
It should be all included in the package. I remember I've worked on adding all necessary components for NLS to the distribution script long time ago. But I didn't test it. So feedback is appreciated.

Remember at https://sourceforge.net/p/lcmd-git/tickets/ there's a ticket system. Although I try to read all infos here, chances that something get remembered in future is much higher when there's a ticket ;-). No clue if you need an account for that. For me sourceforge works pretty good with our ancient SM (and so FF I think). In contrary to other sites username/password authentication still works.

Alfredo Fernández Díaz

  • Jr. Member
  • **
  • Posts: 55
  • Karma: +0/-0
    • View Profile
Re: LarsenCommander - new test version
« Reply #21 on: December 08, 2023, 08:23:49 pm »
Hi again, Andi, thank you...
It should be all included in the package.

I asked whether it is functional because I saw a bunch of old RC translated files under the 'locale' subdir with no obvious way to switch languages from within the application (and still can't find it).

Quote
I remember I've worked on adding all necessary components for NLS to the distribution script long time ago. But I didn't test it. So feedback is appreciated.

OK, fiddling about a bit, under locale there is an old email called 'reply.txt' that you can get rid of. Its slightly more updated cousin 'readme_translation.txt' (which you could refactor) reads "start Larsen Commander version 1.5.1 or 1.5.2 with this command: LCMD.EXE -rcFileLocale lcmd_it.rc" . I cloned the English file onto a Spanish one in the LC folder and changed a few strings -- LC picks it up with the proper parameters in place in the program object. Functional, but a bit cumbersome to keep switching languages while translation is in progress.

Quote
Remember at https://sourceforge.net/p/lcmd-git/tickets/ there's a ticket system. Although I try to read all infos here, chances that something get remembered in future is much higher when there's a ticket ;-). No clue if you need an account for that. For me sourceforge works pretty good with our ancient SM (and so FF I think). In contrary to other sites username/password authentication still works.

OK, but let me see first if I can figure out the locale format ("text" and "hint" are obvious, but what are "alt1", 2, and 3?), how everything is put together (menus seem to be scattered), and whether the autogenerated mnemonics and such do not make translation much of a PITA.

Andi B.

  • Hero Member
  • *****
  • Posts: 818
  • Karma: +11/-2
    • View Profile
Re: LarsenCommander - new test version
« Reply #22 on: December 14, 2023, 10:36:50 pm »
The solution to this particular problem is to get rid of the DLL -- there's no reaon for it to exist. The original author claimed that VACPP 4.0 couldn't handle a 16-bit call so he created a separately-compiled file. But rather than simply linking it into the exe with all the other .obj files, he created a dll. Why?
...

It seems it was that easy - add '      source "gl16os2.obj"' to lcmd.icc and don't delete gl16os2.obj during the build. As far as I can see the only 16 bit function which is used by lcmd is Dos16MemAvail. But no clue when it is called. Have to test a while to be sure there's no sideeffect.

Andi B.

  • Hero Member
  • *****
  • Posts: 818
  • Karma: +11/-2
    • View Profile
Re: LarsenCommander - new test version
« Reply #23 on: April 19, 2024, 07:41:52 pm »
I've just uploaded v1.08.02 at https://sourceforge.net/projects/lcmd-git/files/

From the Readme -
Code: [Select]
Change History:
---------------
20240416 v1.8.2
- Improve EA handling routines to reduce memory leaks and silent crashes
- Fix TRAP 000e in JFS while copying >69000 files. Hint, please use latest ArcaOS (kernel, JFS, ACPI 3.23.17, ...)
- Removed gl16os2.dll dependency (link .obj into .exe)
- Handel out of memory conditions more gracefully
- Added abtrace for logging via pmprintf.dll (if available on target system)
- Improved build cmd files to break on error (ERRORLEVEL handling)
- Tuneed lxlite options to not remove bldlevel info
- Change to David G. icon files (no clue where they are used)
- Again tuning of dynamic copy buffer size adoption (even more speed on my system :-) )
- Change icons to the ones supplied by David G. Thanks for that although it's not clear to me where they are used.
(- Disable integrated exception handlers in favor of exceptq) reverted back
- Disabled ExceptQ handler as I can't get it to work in conjunction with lcmds own handlers

Bug reports please here - https://sourceforge.net/p/lcmd-git/tickets/

Of course I'll keep reading here as well from time to time. Have fun.

Btw. I've a really hard time to track down and reduce this terrible JFS traps when copying a lot of files. It seems to me that JFS still does not touch some memory pages when feed with >4k buffers some times which I guess leads to these 000e traps. Combined with the memory leaks which LCMD suffered when lot of files where copied I had uncountable crashes with long chkdsks afterwards. Now the I reduced memory need for extended attribute handling I can't see these memory leaks anymore with above512. But on some scenarios LCMD still seems to eat up some system resources which report out of memory. Closing LCMD will recover from such situations now.

If you encounter hangs of LCMD you may look at the lcmd.log file in the directory of lcmd.exe. F.i. tail -n 50 lcmd.log will show you the last messages which usually shows some exception infos. For this you've to enable 'Debug' or 'Test' in Help - Debug - Options. Be aware running LCMD with 'Debug' for a long time or while copying huge amount of files let lcmd.log become very big in minutes.

Btw. if you've pmprintf.dll on your system PmPrintf.exe will show you these messages from LCMD with 'Debug' or 'Test' enabled too.
« Last Edit: April 19, 2024, 07:59:17 pm by Andi B. »