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
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
"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:
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:
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.
Freebsd mailing list