defragster
Senior Member+
... mister congenial here ...
Came back and TyComm was 'Not responding'.
Terminated and restarted. Changed its T_4.1 to .Av4Write each 100ms ... picked 100ms to shortcut the 120ms teensy timeout.
> started slower - showed a screen of garbage - picking up some speed ... another screen of garbage just seen.
> disabled TyComm save to RAM Disk.
Tsermon still running - with no .Av4Write
> with no while(.Av4Write) test it shows nothing under 50K lps, not seen any garbage pass, have seen it 'pause' and recover 2-3 times.
Tsermon and TyComm sharing some of same issues, except current Tsermon not showing garbage: suggesting indeed as expected the problem is in windows buffer handling, though the GUI may not display as fast as the data stream appears either.
Sort of interesting that Two nonstop T_4.1's working as well as one?
Of 16 (8*2) cores TWO are at 100%. One is 100% kernel time and the other about 30%. Those two are TyComm as 'Stop Serial' drops them out, except 15% of the shared core stays tied to Kernel.
One other core is ~60% with half Kernel time - assume that is Tsermon, and perhaps one more core at ~70% kernel time?
Other 12 cores all 3 to 13% showing Kernel time with some spikes.
TyComm just froze on garbage and went 'not reponding' ... so it is NOT keeping up as well as Tsermon ( and that it with possible waits each 100ms) - though it is monitoring 3 of 4 T_4.1 ports - where the two Dual Serial USB1 ports are idle - it is doing that on 1 thread AFAIk as implemented.
Came back and TyComm was 'Not responding'.
Terminated and restarted. Changed its T_4.1 to .Av4Write each 100ms ... picked 100ms to shortcut the 120ms teensy timeout.
> started slower - showed a screen of garbage - picking up some speed ... another screen of garbage just seen.
> disabled TyComm save to RAM Disk.
Tsermon still running - with no .Av4Write
> with no while(.Av4Write) test it shows nothing under 50K lps, not seen any garbage pass, have seen it 'pause' and recover 2-3 times.
Tsermon and TyComm sharing some of same issues, except current Tsermon not showing garbage: suggesting indeed as expected the problem is in windows buffer handling, though the GUI may not display as fast as the data stream appears either.
Sort of interesting that Two nonstop T_4.1's working as well as one?
Of 16 (8*2) cores TWO are at 100%. One is 100% kernel time and the other about 30%. Those two are TyComm as 'Stop Serial' drops them out, except 15% of the shared core stays tied to Kernel.
One other core is ~60% with half Kernel time - assume that is Tsermon, and perhaps one more core at ~70% kernel time?
Other 12 cores all 3 to 13% showing Kernel time with some spikes.
TyComm just froze on garbage and went 'not reponding' ... so it is NOT keeping up as well as Tsermon ( and that it with possible waits each 100ms) - though it is monitoring 3 of 4 T_4.1 ports - where the two Dual Serial USB1 ports are idle - it is doing that on 1 thread AFAIk as implemented.