distributed performance test

[Serge Aleynikov]

Thanks Per!  For those who experience similar issues, I'd like to add 
another variable - it turned out that in our case the port on the 
Eithernet switch that this host was connected to was indeed set to 
100BaseTX full-duplex mode only - I suppose this would be causing 
collisions that may not necessarily would be seen at one of the hosts. 
So what you described below applies to all interconnects in the path 
between two hosts talking to each other.

Its at such moments when you think that it would have been much better 
if the Networking and the Systems Development departments were working 
more closely, but I believe that's not a reality of any large 
organization...  ;-)

Serge

Per Hedeland wrote:
> Serge Aleynikov <serge@REDACTED> wrote:
> 
>>Sean Hinde wrote:
>>
>>>>P.S. The only question I have remaining is why would half-duplex 
>>>>setting not have any speed impact on a single client talking to a 
>>>>synchronous server, but only on multiple clients...
>>>
>>>
>>>Well, I guess that a single client is actually only exercising half of a 
>>>duplex. There is never any time when traffic wants to flow both ways at 
>>>the same time.
>>
>>You know, I forgot to mention another interesting fact.  When I tried to 
>>troubleshoot this issue, I extended my test_client/test_server to be 
>>able to send/receive messages using three transports: erlang/tcp/udp. 
>>Here are the results of my tests when the eth0 was set to half-duplex:
>>
>>(n1@REDACTED)15> test_client:test_erl(n2@REDACTED, 10, 500).
>>  -> AvgTime=0.022 (45.360 c/s)
>>
>>(n1@REDACTED)17> test_client:test_udp({10,227,1,200}, 10, 500).
>>  -> AvgTime=0.000 (3355.705 c/s)
>>
>>(n1@REDACTED)18> test_client:test_tcp({10,227,1,200}, 10, 500).
>>  -> AvgTime=0.000 (3144.654 c/s)
>>
>>So, if your statement were true, then it would've had impact on all 
>>tcp/udp/erlang transports, wouldn't it?  Yet in this case somehow it 
>>only impacted Erlang's message passing speed.
> 
> 
> Whether the full-duplex side's making use of the full duplexity is
> actually seen as collisions by the half-duplex side can't really be
> pre-determined, since it is highly dependant on traffic patterns and
> timing. E.g. UDP doesn't have ACKs, which reduces the risk of
> "collisions", and while the Erlang distribution uses TCP it does so with
> the "Nagle algorithm" disabled, which will make the pattern different
> from "normal" TCP.
> 
> We've had quite a few full/half duplex mismatch cases in the field with
> our products (not specifically with the Erlang distribution traffic
> though), and the only general observation you can make is that it
> doesn't really become a problem until you have "a lot" of traffic, at
> which point performance goes down the drain. (The cause of these cases
> is invariably that a network admin doesn't "trust" Ethernet auto-
> negotiation, and insists on locking interfaces at 100Mb/FD - but forgets
> that he has to do that at both ends, with the result that the auto-
> negotiating end goes into 100Mb/HD - per the specs.)
> 
> --Per