Workbench 3.1.4 drag-n-drop copy = multitasking issue?

[patrik]

Background:

On my A1200 I am most of the time using TCP/IP based, software controlled, mouse/keyboard input (SynergyClient). When a process is using a lot of CPU, the mouse movements normally become a bit jerky as the TCP/IP stack does not get enough CPU time (unless you give it a higher priority than 0). This is expected and it is still usable.

Problem:

I noticed that when drag-n-drop copying in Workbench 3.1.4, the mouse movements would completely stop and Synergy server considers the A1200 client dead as it doesn't answer to the alive messages it sends.

Did some basic tests during which I copied a 64M file between two partitions (1 min+ copy). This showed some very strange results:
1. 'ping'ing the A1200 from another machine shows that during the copy, it answers to about 2-3 ping requests, with 20-40 seconds delay.
2. If I run a simple script that is continously updating during the copy, no lines are printed out.
Script:

Lab begin
date
wait 1
Skip BACK begin

Output (observe the huge gap in time during the copy):

7.Ram Disk:> execute ram:datescript 
Sunday 20-Jan-19 14:08:20
Sunday 20-Jan-19 14:08:21
Sunday 20-Jan-19 14:08:23
Sunday 20-Jan-19 14:09:31
Sunday 20-Jan-19 14:09:33

Did some comparisons when using other copy solutions:
- This does not happen when using the C:Copy command.

- This does not happen when doing the same drag-n-drop copy in Workbench 3.9. The 3.9 test is with scsi.device and FastFileSystem from 3.1.4 to make the test as similar as possible.

Tried to figure out what the drag-n-drop copy in Workbench 3.1.4 does different compared to the other copy variants by monitoring it with SnoopDos. The only thing I can see is that it reads/writes smaller chunks of data:

Workbench 3.1.4 drag-n-drop-copy (0x5000 = 20480Bytes chunks):

Time     Process Name       Action     Target Name                    Optio Res.
----     ------------       ------     -----------                    ----- ----
14:45:17 [6] Workbench      #READ      60084B44, 605F0690,     5000   DH8   OK  
14:45:17 [6] Workbench      #WRITE     6007E3FC, 605F0690,     5000   DH7   OK

C:Copy 3.1.4 (0x10000 = 65536Bytes chunks):

Time     Process Name       Action     Target Name                    Optio Res.
----     ------------       ------     -----------                    ----- ----
14:25:34 [7] copy           #READ      60084B9C, 60482D9C,    10000   DH8   OK  
14:25:34 [7] copy           #WRITE     6007E3A4, 60482D9C,    10000   DH7   OK

Workbench 3.9 drag-n-drop-copy (0x10000 = 65536Bytes chunks):

Time     Process Name       Action     Target Name                    Optio Res.
----     ------------       ------     -----------                    ----- ----
13:23:00 AsyncWB - copy pro #READ      6008516C, 6047CE70,    10000   DH8   OK  
13:23:00 AsyncWB - copy pro #WRITE     6007E86C, 6047CE70,    10000   DH7   OK

C:Copy 3.9 (0x10000 = 65536Bytes chunks):

Time     Process Name       Action     Target Name                    Optio Res.
----     ------------       ------     -----------                    ----- ----
13:26:58 [7] copy           #READ      6008516C, 60534F94,    10000   DH8   OK  
13:26:58 [7] copy           #WRITE     6007E8C4, 60534F94,    10000   DH7   OK

The A1200 has a Blizzard1260+SCSI-kit-IV with 060@50MHz, 144MB FastRAM, 24GB mSATA SSD on A1200-IDE via mSATA<->IDE-adapter, real 3.1.4 kickstart and MapROM enabled.

I have tested both with FastFileSystem 46.13 and pfsaio 19.2 with the same result.

[pipper]

Maybe exec’s scheduler is starving the tcp/ip stack in favor of disk IO processes.
Have you tried ‘Executive’? It’s available on Aminet and replaces the scheduler with one (actually there are multiple available to chose from) that is less prone to starve processes.

[indigolemon]

Could it be as simple as no ASyncWB ? I had to bring it over from my 3.9 install to preserve my sanity.

[patrik]

Originally Posted by pipper

Maybe exec’s scheduler is starving the tcp/ip stack in favor of disk IO processes.
Have you tried ‘Executive’? It’s available on Aminet and replaces the scheduler with one (actually there are multiple available to chose from) that is less prone to starve processes.

Yes, both the TCP/IP stack and the example script was obviously completely starved of CPU time. Even if executive might solve this situation, Workbench 3.1.4 should not require executive to maintain system multitasking during file copy when neither Workbench 3.9 or the regular C:Copy command does so.

Originally Posted by indigolemon

Could it be as simple as no ASyncWB ? I had to bring it over from my 3.9 install to preserve my sanity.

It is true that Workbench 3.1.4 in itself doesn't multitask when copying files, but it shouldn't stop the whole machine from multitasking while doing it .