Heheheh... acho que encontrei algo interessante...

Lembram do meu problema com emeu modem, nao lembram?

O erro era "Chat_Write: No buffer space available."

Rodei o pp com truss, ativei o log do ppp em modo de depuracao, li muito...

Olhem o que eu encontrei:

em man tun:

" A write(2) call passes a packet in to be ``received'' on the pseudo-
    interface.  Each write(2) call supplies exactly one packet; the packet
    length is taken from the amount of data provided to write(2).  Writes
    will not block; if the packet cannot be accepted for a transient reason
(e.g., no buffer space available), it is silently dropped; if the reason
    is not transient (e.g., packet too large), an error is returned.  If
    ``link-layer mode'' is on (see TUNSLMODE below), the actual packet data
    must be preceded by a struct sockaddr.  The driver currently only
    inspects the sa_family field."

Segundo o manual, existe a possibilidade de nao haver buffer suficiente para o tamanho do pacote (nao saquei se era pacote ou janela).

Agora vendo a configuracao do kernel bsd, com sysctl (retirado de http://www.gsp.com/cgi-bin/man.cgi?section=7&topic=tuning#3):

"The / net.inet.tcp.sendspace/ and / net.inet.tcp.recvspace/ sysctls are of particular interest if you are running network intensive applications. They control the amount of send and receive buffer space allowed for any given TCP connection. The default sending buffer is 32K; the default receiving buffer is 64K. You can often improve bandwidth utilization by increasing the default at the cost of eating up more kernel memory for each connection. We do not recommend increasing the defaults if you are serving hundreds or thousands of simultaneous connections because it is possible to quickly run the system out of memory due to stalled connections building up. But if you need high bandwidth over a fewer number of connections, especially if you have gigabit Ethernet, increasing these defaults can make a huge difference. You can adjust the buffer size for incoming and outgoing data separately. For example, if your machine is primarily doing web serving you may want to decrease the recvspace in order to be able to increase the sendspace without eating too much kernel memory. Note that the routing table (see route <http://www.gsp.com/cgi-bin/man.cgi?section=8&topic=route>(8)) can be used to introduce route-specific send and receive buffer size defaults.

(...)

Setting the send or receive TCP buffer to values larger then 65535 will result in a marginal performance improvement unless both hosts support the window scaling extension of the TCP protocol, which is controlled by the / net.inet.tcp.rfc1323/ sysctl. These extensions should be enabled and the TCP buffer size should be set to a value larger than 65536 in order to obtain good performance from certain types of network links; specifically, gigabit WAN links and high-latency satellite links. RFC1323 support is enabled by default."

Tambem li sobre a rfc 1323:

"/Large Windows (RFC 1323)/

The initial design of TCP limits send and receive buffers to 64K. If the network BDP is small [either because the link is slow or the RTT is small, e.g. LAN] then these buffer sizes are adequate. However, on networks with a large BDP larger buffers are needed. RFC1323 describes a mechanism to allow for buffers larger than 64K and most modern TCP/IP stacks have this enabled by default. E.g. on Mac OS X, typing the following command in a Terminal window and scanning the output will reveal that the RFC1323 option is enabled:

sysctl net.inet.tcp.rfc1323"

Logo, concluo:

Ou eu ponho isso:

Name                        Old Value        New Value
net.inet.tcp.sendspace     32768             262144
net.inet.tcp.recvspace     32768             262144
net.inet.tcp.delayed_ack     1                 0
kern.ipc.maxsockbuf        262144            2097152

ou eu ponho:

net.inet.tcp.rfc1323 0

Nao sei se eu fiz uma pergunta ou se dei uma explicacao para o meu problema... hoje no final da tarde eu terei uma resposta, e espero poder postar na lista usando meu freebsd em casa com meu modem.

Ricardo.


_______________________________________________
Freebsd mailing list
Freebsd@fug.com.br
http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br

Responder a