Fork us on GitHub Follow us on Facebook Follow us on Twitter

Opened 7 years ago

Last modified 2 years ago

#535 new defect

tester print4 is slow on remcons

Reported by: Jiri Svoboda Owned by:
Priority: minor Milestone:
Component: helenos/unspecified Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:

Description

If you telnet into HelenOS and run 'tester print4' the output is excessively slow. It appears that each character is written out and sent over the network separately. Likely buffering that should be happening either in remcons or libc I/O code does not happen.

Change History (6)

comment:1 Changed 7 years ago by Jiri Svoboda

Apparently this is because the output is written using TPRINTF which prints to stderr stream which is unbuffered (stdout is line-buffered). Not sure whether/how changing this to a buffering variant is a good idea.

comment:2 Changed 7 years ago by Vojtech Horky

I think that adding buffering to stderr would break the purpose of seeing the error output as soon as possible. Thus, the only place to add the buffering would be somewhere in remcons. But I think that remcons should remain as simple as possible to be still usable as a debugging aid (e.g. when the GUI stops responding).

Furthermore, print4 is a very special case because under normal circumstances you do not print characters one by one. In my opinion, we should close this as wontfix.

comment:3 Changed 6 years ago by Jiri Svoboda

Also, probably part of the problem is that the text fragments are sent in separate TCP segments. Thus some buffering in the sockets/TCP code might help (either implementing Nagle's algorithm or simply not guarateeing the data to be sent uless it is pushed).

Version 0, edited 6 years ago by Jiri Svoboda (next)

comment:4 Changed 5 years ago by Jakub Jermář

Milestone: 0.6.00.7.1

comment:5 Changed 3 years ago by mtravis

Here is the wiki page for Nagel's algorithm

comment:6 Changed 2 years ago by Jakub Jermář

Milestone: 0.7.1
Note: See TracTickets for help on using tickets.