Eric Pouech wrote:
James Courtier-Dutton a écrit :
I attach two logs taken with the command: - WINEDEBUG=+comm wine ttermpro.exe
WINEDEBUG="+comm,+file,+ntdll" would be more helpful. TIA.
I linked two computers together. ttermpro on one, and kermit on the other. When I type characters on the ttermpro console, each character appears on the kermit console immeadiately.
After looking at the first log: comm-file-ntdll.txt I noticed messages like this: - trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 1/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 2/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 3/1024 so far trace:ntdll:FILE_AsyncReadService 0x43bdf8 0x43f080 trace:ntdll:FILE_AsyncReadService read 1 more bytes 4/1024 so far
I then thought. What would happen if I typed 1024 characters. So, in the second log file I do that: comm-file-ntdll-2.txt
Eventually, after typing 1024 characters, they actually arrive on the ttermpro console.
Summary: - All characters are getting through the comms link, except that on the receive (READ) path, individual chars are getting buffered, and only when the buffer is full do they reach the application.
This sounds to me like some Nagle algorithm gone wrong. We would want this buffering to happen if there was a lot of traffic (e.g. PPP internet link), as it would reduce the amount of api calls, but for simple interactive terminal session, if a new char has not arrived within 2 or 3 chars periods at the current baud rate, the buffer should be forwarded to the application.
I attach two log files, one where I type a few characters, and one where I typed more than 1024.
I hope this helps
Can other people verify my findings regarding the 1024 char threshold?
Cheers James