*
two...@gmail.com
| 1. It seems from your post that your network topology is that
| only the one system is remote. Can we assume the others are
| all local, on the same lan? If so, if would be fascinating to
| see if moving that remote machine onto the same lan with the
| other systems that don't have the problem would then clear up
| this one issue. Probably too much work though :(
Should have been more specific in my original message...
'Remote' is not really 'remote' in the sense of WAN. It is a PC talking
to an embedded device running Busybox-Linux. The two are directly
connected via Ethernet via one cable, only these two share this
connection/cable. So 'remote' is only to denote "not on the same computer".
When I say "other machines", it means this embedded device directly
connected to another computer, Windows or Linux. The connection is
always "exclusive cable use" :-)
| 3. I misread the 2 second timeout data point. I now see that 2s
| is built into your test code with
>
| while (elapsed_ms() <= 2000)
>
| So, what if that were longer, say 5000, or
| even longer. Does it totally deadlock or would it eventually
| continue? That at least should be a simple test.
Easy to do, indeed, will provide a means to specify the timeout in the
tests scheduled later today. I do not expect to make that any difference.
| In poking around the internet for "slow" and "one byte" and "windows"
| one finds many discussions which make it sound like windows has some
| undocumented code along with the nagle algorithm. One thing keeps popping
| up is a mention of delayed acks. However, they are only supposed to be
| 200 ms. Probably just a red herring, but curious.
Yes, I've seen these 200ms articles, too. But I don't see a 200ms delay
on any other Windows machine. The 'O' is sent, I wait 100ms, and in the
next Tcl_Gets(), the answer is there.
set fd [socket 192.168.2.1 65422]
fconfigure $fd -buffering none -blocking 0 -encoding binary
fileevent $fd readable [list read_answer $fd]
proc read_answer {fd} {
set now [clock milliseconds]
set line [gets $fd]
if {$line ne ""} {
puts "LINE {$line} [expr {$now-$::start}]ms"
}
if {[eof $fd]} {
close $fd
}
}
puts -nonewline $fd "O"
set start [clock milliseconds]
vwait forever
Roundtrip time on Linux with no waiting at all after the 'O':
LINE {v3 ... } 2ms
LINE {v3 ... } 2ms
LINE {v3 ... } 2ms
LINE {v3 ... } 2ms
Windows:
LINE {v3 ... } 2ms
LINE {v3 ... } 3ms
LINE {v3 ... } 2ms
LINE {v3 ... } 2ms
| The bottom line for me is that it only occurs on 1 windows system, so that
| itself would seem to rule out the nagle algorithm, unless there's something
| happening on the hops between this system and your other systems. I think
| getting to what's different is probably the key.
As said before, Nagle should kick in only for the 2nd ff transmissions
on one socket. Since the single byte is the very first byte on that
connection, it should not be Nagle.
More tests follow this afternoon CEST, stay tuned...
R'