distributed performance test

[Serge Aleynikov]

Sean/Matthias,

Thank you, thank you, thank you!!!

The devlinuxpro2 Linux server was indeed running eth0 in 100BaseTX 
half-duplex mode.

After I set the interface to full-duplex, and rebooted, the speed tests 
ran as expected.

Regards,

Serge

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...

Sean Hinde wrote:

> 
> On 25 Apr 2005, at 10:30, Matthias Lang wrote:
> 
>> Sean Hinde writes:
>>
>>> We have seen such problems when networks/NICs are set up incorrectly
>>> (e.g. one end forced to 10/half duplex, the other to 100/full
>>> duplex).
>>
>>
>> Methinks the details have gotten messed up in your memory.
> 
> 
> That, or perhaps it was an expression of artistic licence designed to 
> increase the impact. Clearly such flights of fancy get the drubbing they 
> deserve on this mailing list :-)
> 
> (BTW I have copied the list on your answer because this is actually 
> quite useful information)
> 
>>
>> There's no way you can have one end at 10Mbit and the other at 100 and
>> still have communication (10Mbit uses manchester coding, 100Mbit uses
>> something completely different).
>>
>> You're probably remembering one end forced to 100/full duplex with no
>> autonegotiation and other end on autonegotiate. One end then uses
>> 100/full and the other 100/half---the standard requires this (broken)
>> behaviour.
> 
> 
> Very interesting. This figures more closely with my real memory. We have 
> seen this (I was told, by another well meaning techie) when 
> auto-negotiation didn't "work properly" with Solaris, meaning that both 
> ends need to be pinned to the same settings. I never dug very deeply, 
> and the UNIX guys always needed to fix it, but it sounds like the UNIX 
> guys were fixing a problem caused by the network guys.
> 
> On reflection that sounds about right.
> 
> Sean
> 
>>
>> The clearest symptom is that the half-duplex side sees late
>> collisions. _Late_ collisions should never be present on an ethernet.
>> Up higher, you see TCP connections which have occasional low
>> throughput and difficulty getting started.
>>
>> I've seen this twice in the field, both times it's involved an
>> expensive switch and a well-meaning techie who insisted on configuring
>> everything for "maximum performance".
> 
> 
> 

-- 
================================================================
| Serge Aleynikov                          Tel: (973) 438-3436
| MIS Telecom                              Fax: (973) 438-1457
| IDT Corp.                                   serge@REDACTED
================================================================