Opened 12 years ago
Last modified 7 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 by , 12 years ago
comment:2 by , 12 years ago
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 by , 11 years ago
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).
comment:4 by , 10 years ago
Milestone: | 0.6.0 → 0.7.1 |
---|
comment:6 by , 7 years ago
Milestone: | 0.7.1 |
---|
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.