- Community Home
- >
- HPE Community, Korea
- >
- HP-UX
- >
- unix domain socket buffer size ?
HP-UX
1752808
회원
5954
온라인
108789
솔루션
포럼
범주
Company
Local Language
뒤로
포럼
토론 게시판
포럼
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
토론 게시판
토론 게시판
포럼
토론 게시판
뒤로
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
블로그
정보
커뮤니티 언어
언어
포럼
블로그
1 응답 1
- 신규로 표시
- 북마크
- 구독
- 소거
- RSS 피드 구독
- 강조
- 인쇄
- 부적절한 컨텐트 신고
날짜: 01-13-2004 11:00 PM
날짜: 01-13-2004 11:00 PM
unix domain socket buffer size ?
domain buffer size라고 하니 좀 이해하기 힘들군요.
혹 tcp send/received buffer size를 얘기 하시는건 아니신지요.
(setsockopt(), getsockopt())
SO_SNDBUF = send buffer high-water mark(tcp_xmit_hiwater_def)
SO_RCVBUF = receive buffer high-water mark(tcp_recv_hiwater_def
tcp_recv_hiwater_def
====================
Every single TCP connection has a special amount of memory
allocated to store the packets. The application reads from
this buffer and TCP writes to it.
If the application does not read fast enough, the buffer gets
filled and TCP is no longer able to write to it.
This tunable changes the amount of buffer space that is
available for default tcp connections (more on this later).
It is meant for local LAN type (ie. ethernet, fddi, token)
connections.
There are two other tunables which are similar but for other
media types.
tcp_recv_hiwater_lfp - is responsible for the Long, Fat Pipes,
this means fast connections like Fiber
Channel.
tcp_recv_hiwater_lnp - regulates the Long, Narrow Pipes, which
are slow connections like PPP.
This value is given in bytes.
The minimum is 4096 bytes and no maximum limit is defined.
The default is set to 32K (32768).
Why should this be changed?
If the application is not fast enough to read all the
information from the buffer, and memory is available,
performance can be improved by increasing this value.
If the machine has depleted most of its available memory to
several tcp connections that are writing into the buffers,
it could be useful to decrease this tunable to limit the memory
usage to a bearable amount.
Usable commands:
Check the current value:
ndd -get /dev/tcp tcp_recv_hiwater_def
Set the window size to 64K (65536):
ndd -set /dev/tcp tcp_recv_hiwater_def 65536
nddconf entry example:
TRANSPORT_NAME=tcp
NDD_NAME=tcp_recv_hiwater_def
NDD_VALUE=65536
tcp_xmit_hiwater_def
====================
For every TCP connection a buffer is allocated.
The application writes into this buffer and TCP is responsible
for sending it to the distant host. Sometimes it happens that
the other host is not able to receive further data, so TCP can
not send more data out on the interface.
In this case the allocated buffer fills up and at one point we
reach a limit where we must stop the application from sending
more data to the buffer.
This higher limit is called the high-water mark. We prevent the
application from sending any further data until TCP is able to
send enough packets out so that we reach another lower limit the
tcp_xmit_lowater_def which again allows the application to write
data into the buffer.
Since different connections could differ in their speed of
filling up this limit, we have two other high-water marks:
tcp_xmit_hiwater_lfp is for fast connection, whereas
tcp_xmit_hiwater_lnp is for slow connections.
Also the low-water mark has two other equivalents for fast
connections it is tcp_xmit_lowater_lfp and for the slow
connections it is tcp_xmit_lowater_lnp.
This value is given in bytes.
The minimum is 4096, there is no defined maximum.
The default is set to 32K (32768).
Why should this be changed?
Normally it is not necessary to change this value, but if the
connections are faster than expected you could increase it or if
they are slower decrease them.
Usable commands:
Check the current value:
ndd -get /dev/tcp tcp_xmit_hiwater_def
Set the high-water mark to 64K:
ndd -set /dev/tcp tcp_xmit_hiwater_def 65536
nddconf entry example:
TRANSPORT_NAME=tcp
NDD_NAME=tcp_xmit_hiwater_def
NDD_VALUE=65536
happy new year!
혹 tcp send/received buffer size를 얘기 하시는건 아니신지요.
(setsockopt(), getsockopt())
SO_SNDBUF = send buffer high-water mark(tcp_xmit_hiwater_def)
SO_RCVBUF = receive buffer high-water mark(tcp_recv_hiwater_def
tcp_recv_hiwater_def
====================
Every single TCP connection has a special amount of memory
allocated to store the packets. The application reads from
this buffer and TCP writes to it.
If the application does not read fast enough, the buffer gets
filled and TCP is no longer able to write to it.
This tunable changes the amount of buffer space that is
available for default tcp connections (more on this later).
It is meant for local LAN type (ie. ethernet, fddi, token)
connections.
There are two other tunables which are similar but for other
media types.
tcp_recv_hiwater_lfp - is responsible for the Long, Fat Pipes,
this means fast connections like Fiber
Channel.
tcp_recv_hiwater_lnp - regulates the Long, Narrow Pipes, which
are slow connections like PPP.
This value is given in bytes.
The minimum is 4096 bytes and no maximum limit is defined.
The default is set to 32K (32768).
Why should this be changed?
If the application is not fast enough to read all the
information from the buffer, and memory is available,
performance can be improved by increasing this value.
If the machine has depleted most of its available memory to
several tcp connections that are writing into the buffers,
it could be useful to decrease this tunable to limit the memory
usage to a bearable amount.
Usable commands:
Check the current value:
ndd -get /dev/tcp tcp_recv_hiwater_def
Set the window size to 64K (65536):
ndd -set /dev/tcp tcp_recv_hiwater_def 65536
nddconf entry example:
TRANSPORT_NAME=tcp
NDD_NAME=tcp_recv_hiwater_def
NDD_VALUE=65536
tcp_xmit_hiwater_def
====================
For every TCP connection a buffer is allocated.
The application writes into this buffer and TCP is responsible
for sending it to the distant host. Sometimes it happens that
the other host is not able to receive further data, so TCP can
not send more data out on the interface.
In this case the allocated buffer fills up and at one point we
reach a limit where we must stop the application from sending
more data to the buffer.
This higher limit is called the high-water mark. We prevent the
application from sending any further data until TCP is able to
send enough packets out so that we reach another lower limit the
tcp_xmit_lowater_def which again allows the application to write
data into the buffer.
Since different connections could differ in their speed of
filling up this limit, we have two other high-water marks:
tcp_xmit_hiwater_lfp is for fast connection, whereas
tcp_xmit_hiwater_lnp is for slow connections.
Also the low-water mark has two other equivalents for fast
connections it is tcp_xmit_lowater_lfp and for the slow
connections it is tcp_xmit_lowater_lnp.
This value is given in bytes.
The minimum is 4096, there is no defined maximum.
The default is set to 32K (32768).
Why should this be changed?
Normally it is not necessary to change this value, but if the
connections are faster than expected you could increase it or if
they are slower decrease them.
Usable commands:
Check the current value:
ndd -get /dev/tcp tcp_xmit_hiwater_def
Set the high-water mark to 64K:
ndd -set /dev/tcp tcp_xmit_hiwater_def 65536
nddconf entry example:
TRANSPORT_NAME=tcp
NDD_NAME=tcp_xmit_hiwater_def
NDD_VALUE=65536
happy new year!
위에 명시된 의견은 Hewlett Packard Enterprise가 아닌 저자의 개인 의견입니다. 이 사이트를 사용하면 이용 약관에 동의하게되며 참여 규칙 .
뉴스 및 이벤트
© Copyright 2024 Hewlett Packard Enterprise Development LP