I'm sure you know this, but unbuffered I/O can be painfully slow. The
problem is that buffering can also cause problems for certain network
protocols: imagine an MTA (message transfer agent) sending QUIT to
terminate an SMTP session. If the TCP stack hadn't filled the
advertised window, it could simply wait for more data to become
available before actually sending a TCP segment. But of course, no
further data is forthcoming, so we have a problem. My guess is that
GT.M is doing no buffering at all but just handing data off to Linux,
which implements the sliding window protocol, effectively creating an
adaptive buffer. When no data is received, the remote TCP will
periodically send an empty ACK shrinking the window size. Not ideal,
but it should work, especially if your data transfers are not
particularly bursty.
===
Gregory Woodhouse
[EMAIL PROTECTED]
"The most incomprehensible thing about
the world is that it is at all comprehensible."
--Albert Einstein (1879-1955)
On Aug 23, 2005, at 2:23 PM, Jim Self wrote:
Bhaskar wrote:
On Tue, 2005-08-23 at 11:53 -0500, Kevin Toppenberg wrote:
[KSB] <...snip...>
P.S. Kevin, did you ever get your IO working? I think that was
what
started the thread.
No I didn't. But this thread got off track, so I started a new one.
I can't get block reads to work properly.
I hope this helps (4 lines; watch out for line breaks):
iodemo set file="/etc/dictionaries-common/words"
open file:(readonly:fixed:recordsize=80)
for use file read x use $P write $l(x),! zwrite x quit:$ZEOF
quit
I use zwrite to demonstrate that linefeeds are being read in as
characters into strings.
I haven't worked with this level of code in quite awhile and I
forget what differences in
device parameters apply to different device types, such as for
sockets and communication
between processes, such as we use in CGI between Apache and GT.M.
In making M2Web capable of uploading binary files from web
browsers, we settled a long
time ago on using READ * (single character) because it works - and
incidentally is MUCH
faster than Kevin's previous example would indicate. (I think I
sent such a response to
the list, but it might still be waiting in my outbox.)
I remember that READ * is unacceptably slow on other MUMPS, but it
seems to work quite
well on GT.M. Do you think we can get significantly better
performance with block reads
now with the latest versions of GT.M.
---------------------------------------
Jim Self
Systems Architect, Lead Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Hardhats-members mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/hardhats-members
