clues to source of this delay?

[Markus Stenberg]

Markus Stenberg <mstenber at cc.Helsinki.FI> writes:
> Markus Stenberg <mstenber at cc.Helsinki.FI> writes:
> > And the CPU spent is about 2%, thus the delays are .. somewhere. Any
> > insights on where? The Linux performance is sufficient, but NT performance
> > most definitely is _NOT_.
> To follow-up to my own query:
> 	- NT4 server did _not_ perform any better (5 roundtrips/sec, @whee)
> 	- Eliminating select altogether did not help at all
> Thus, it seems it's out of Python's hands for 95% of the
> time. .. sigh. This twilight zone stuff just isn't for me :P

.. final update (hopefully):

Just for laughs I wrote the simplified version of the whole thing in C;
basically, a server that accepts only one connection in recv+send+send
loop, client with connect and then send+send+recv loop. Timings did not
change at all.

Problem was _still_ unsolved (something's out there, mr. Mulder).  Values,
respectively: NT 2.5, HPUX 3.5, Linux 25 (dual roundtrip's) per second.
For some reason, offers of 'get a Linux box' will probably receive great
deal of scorn; thus I'd like to see this solved, one day.. siigh. :-P

And as if to scorn me, the _simplistic_ send+recv clients written in Python
continue to score much faster roundtrips, despite the fact that the
packets' _length_ is the same, even. Grrr....

Finally I observed the problem in my protocol; number of sends per
iteration != number of recvs per iteration (per participant).  In general
(for each received non-ack message, the client/server sends ack _and_ new
message in the echo mode). For some reason, TCP's slow start on the boxen
involved did _not_ work as advertised, and therefore window size stayed at
1 and the speed stayed constant.

That's what I figured, anyhow; after a small rewrite the new protocol with
slightly better buffering, and therefore just send+recv/recv+send cycles,
gets fairly close to saturating my ethernet.

-Markus, signing off after a fairly frustrating 13+-hour code marathon.

-- 
----- BEGIN GEEK CODE v3.0 BLOCK (*) -----
GCS d- s+: !a C+(++) UL+++$ P--- L+++ E++ W-- N+ W--- O---- M-- V- PS+++
Y+ PGP++>+++ t+@ 5++ X+ R* tv-- b+++ DI+++>++++ D---- G++ e++ h* r% z+
----- END GEEK CODE v3.0 BLOCK -----
* For spoilers, check http://www.geekcode.com