[FUG-BR] PPP??? [pergunta ou resposta?]

[Ricardo Maia]

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 em fug.com.br
http://mail.fug.com.br/mailman/listinfo/freebsd_fug.com.br