Pular para o conteúdo principal

Tempos de transferência FTP dolorosamente altos, tempo de resposta de login interativo muito longo, tirando 1 mbps de sua rede de 100 mbps. Embora eu sempre prefira culpar a rede, tenho que admitir que às vezes ela não é a rede.

A primeira coisa a ser procurada ao lidar com um problema de desempenho TCP é uma questão de baixo nível de Ethernet e de longe a questão mais comum é um descasamento duplex. A Ethernet pode funcionar tanto em modo full quanto half duplex. No modo full duplex, tanto o adaptador do módulo quanto o dispositivo ao qual ele está conectado, seu ponto de conexão (normalmente um switch, mas nem sempre) pode transmitir ao mesmo tempo. No modo half duplex, apenas um lado pode transmitir. Há uma janela no tempo em que ambos os lados podem pensar que é possível transmitir e fazê-lo, quando isso acontece uma colisão é declarada, ambos os lados param de transmitir, esperam uma quantidade aleatória de tempo e tentam novamente. É importante entender que, quando ambos os lados estão em modo half duplex, estas colisões não reduzem significativamente a taxa de transmissão da rede.
Em um desfasamento duplex, um lado está em modo full duplex e seu link peer está em modo half duplex. O lado em modo half duplex pode sofrer colisões tardias e colisões excessivas, estes tipos de erros reduzem significativamente a produção. Quaisquer colisões tardias ou excessivas são uma indicação de um problema. A desaceleração da rede pode parecer desproporcional ao número de colisões tardias e excessivas, pois em uma condição de descoordenação duplex, mesmo colisões normais reduzirão a produção, pois o link peer não retransmitirá o quadro, pois não reconhecerá uma colisão no modo full duplex.
Então, como você sabe se isso está acontecendo com você? O "netstat -interface" mostrará as estatísticas que lhe permitirão determinar se está ocorrendo um descasamento duplex. No exemplo a seguir, as estatísticas para o adaptador ativo do #sdlmux.m16.11-3 interface são exibidas. Retirei as estatísticas do adaptador de espera para economizar espaço e acrescentei os números de linha.
Se o adaptador estiver em modo half duplex você verá contagens positivas nas linhas 25 (Transmit frame foi diferido), 26 (Transmit frame após uma única tentativa) e 27 (Transmit frame após múltiplas tentativas). Estes são os contadores de colisão normais. Se você vir contagens positivas nas linhas 24 (Transmit frame descartado, colisões tardias) e/ou 28 (Transmit frame descartado, reentrada excessiva) você provavelmente tem ou teve uma incompatibilidade duplex. Estes contadores só são reinicializados quando o adaptador é reinicializado, então valores positivos são uma indicação de que houve um problema; os contadores que continuam a subir são uma indicação de que você ainda tem um problema. Se o adaptador estiver no modo full duplex e você vir um valor positivo na linha 32 (Receber frame descartado, CRC ruim), o link peer provavelmente está no modo half duplex.
1    netstat -interface #sdlmux.m16.11-3
2
3    Ethernet adapters are grouped
4    Number of failovers = 0
5
6    Active Device Statistics:
7
8
9    MAC Type   : CSMA/CD
10    MAC Address: 00:00:a8:43:52:22
11    Device Name: #sdlmux.m16.11-3
12    Line Speed : 100 mb/s
13    Line Duplex: Full-Duplex
14
15    MAC Statistics:
16     Received frames                          : 20783181
17     Received multicast and broadcast frames : 2984375
18     Received octets                          : 1787913869
19     Transmitted frames                       : 9747015
20     Transmitted octets                       : 2780485819
21     LAN Chipset re-initialized               : 0
22     SQE error                                : 0
23     Transmit ring full                       : 0
24     Transmit frame discarded, late collisions: 0
25     Transmit frame was deferred              : 0
26     Transmit frame after a single retry      : 0
27     Transmit frame after multiple retry      : 0
28     Transmit frame discarded, excessive retry: 0
29     Receive frame discarded, lack of buffers : 0
30     Receive frame discarded, improper framing: 0
31     Receive frame discarded, an overflow     : 0
32     Receive frame discarded, bad CRC         : 674
33     Receive frame discarded, bad address     : 0
34     Receive frame discarded, congestion      : 0
35
36    MAC Summary:
37     Transmitted frames         : 9747015
38     Transmitted octets         : 2780485819
39     Retransmitted frames       : 0
40     Received frames            : 23767556
41     Received octets            : 1787913869
42     Total of lost frames       : 0
43    Partner Device Statistics:
. . . .
ready 08:35:14
Como você entrou neste cenário de descoordenação duplex? É claro que é possível ter um dispositivo configurado para rodar em modo full duplex e o link peer configurado para modo half duplex MAS o cenário mais comum é ter um dispositivo configurado para full duplex e o link peer configurado para auto-negociação. A maioria dos dispositivos quando configurados para o modo full duplex não irá auto-negociar e de acordo com a especificação de auto-negociação o lado que tenta auto-negociar deve voltar ao modo half duplex quando não vê o protocolo de auto-negociação a partir do link peer.
Por padrão, os adaptadores Ethernet usados pela OpenVOS irão auto-negociar, a menos que o link peer também esteja configurado para auto-negociação ou modo half duplex, você terá um descasamento duplex. Para configurar um adaptador para um modo duplex específico, você precisa adicionar o “-duplex full” ou “-duplex half” string para o campo de parâmetros no dispositivo.tin entry para o adaptador. Você também deve definir a velocidade. O OpenVOS Streams TCP/IP Administrator's Guide (R419) descreve isto em detalhes.
Uma nota final, se o adaptador estiver funcionando a 1 gigabit, então ele também estará funcionando em modo full duplex. Ninguém suporta meio duplex gigabit.

© 2024 Stratus Technologies.