지풍@blog

This is a simplified model of TCP/IP over Ethernet behaviour of a single TCP connection intended to provide insight into throughput limitations of TCP/IP due to network transit latency. In the model, TCP/IP sends the maximum TCP receive window size worth of application data (filling the maximum possible receive buffer), then waits for a single acknowledgement for the entire max. window size burst. The model also assumes that the instant the acknowledgement is sent, the data is emptied from the receive buffer and the entire window size is again fully available.

Analysis assumes no lost data (no retransmits are required, no delay associated with retransmit timer waits & no ACK timer waits); All datagrams sent are maximum size; No allowance for TCP slow start algorithm delay; This results in an upper bound style result. Bear in mind that this simulates the performance of a single application, not an aggregate usage model of multiple simultaneous users on a network. Furthermore, at the upper limit of TCP performance the model assumes that computer hardware and network equipment can sustain the peak TCP allowed data rates.

In Basic TCP, the maximum number of bytes that can be in transit (specified by the TCP receive window size) is limited to 64KB by the 16 bit window size in the TCP header. Often the 64KB value is used to illustrate the maximum theoretical throughput of TCP. This is only partially true. In the early 1990s Van Jacobsen et Al. recognized that higher bandwidths were becoming available and that TCP needed to be updated to support high bandwidth, high latency networks. The work culminated in 1992 with the publication of RFC1323 which specified modifications to TCP to support the high bandwidth, high latency networks. This removed the 64 KB limit, in theory.

In practise, most TCP stacks do not support RFC 1323 extensions and still have a maximum TCP window size on the order of 8 KB. An example is Microsoft TCP/IP v.2.0 used in Windows NT. It has a 8760 Byte maximum receive window. Windows 2000, while supporting RFC 1323 extensions, by default has a maximum receive window of 17520 Bytes. To enable the RFC1323 extensions in Windows 2000, registry entries must be manually adjusted.

Select Line Rate : Gigabit Ethernet

Custom TCP Receive Window (for best perf. Use even multiples of 1460) : 65536 Bytes

Data:

Ethernet Frame Size : 1518 Bytes

Ethernet Preamble : 8 Bytes

Interframe Gap : 12 Bytes

Total Inter-Frame Time : 1538 Bytes

Ethernet Overhead : 38 Bytes

Ethernet Data : 1500 Bytes

IP Datagram Overhead : 20 Bytes

TCP Datagram Overhead : 20 Bytes

Maximum User Data per Ethernet Frame : 1460 Bytes

Line Rate

Ethernet 10000000 10000000

Fast Ethernet 100000000 100000000

Gigabit Ethernet 1000000000 1000000000

Maximum TCP Receive Window : 65536 Bytes

Maximum Windows NT TCP Receive Window (on Ethernet) : 8760 Bytes

Maximum Windows 2000 TCP Receive Window : 17520 Bytes

Application Throughput:

Application Data Size/(Ethernet Serialization Delay + Round Trip Latency)

출처 : http://www.babinszki.com/Networking/Max-Ethernet-and-TCP-Throughput.html

redhat 계열에서는(redhat, Fedora, Red Hat Enterprise Linux, CentOS등) 해당하는 배포판의 버전을 /etc/redhat-release에 해당하는 배포판의 버전이 있습니다

간혹 하위 버전의 배포판으로 만들어진 소스가 상위 버전의 배포판에서도 컴파일이 되지만

지원하지 않는 배포판이라고 컴파일이 안 될 경우에는 이 파일에 해당하는 하위 버전의 배포판으로 변경해 주면 됩니다

참고로 아래는 자주 쓰는 redhat 9 이랑 Fedora에서 redhat-release입니다

Fedora Core release 1 (Yarrow)
Fedora Core release 2 (Tettnang)
Fedora Core release 3 (Heidelberg)
Fedora Core release 4 (Stentz)
Fedora Core release 5 (Bordeaux)
Fedora Core release 6 (Zod)
Fedora Core release 7 (Moonshine)
Red Hat Linux release 9 (Shrike)

C/C++의 Data Type 입니다. 그런데 이것은 OS나 컴파일러에 따라서 차이가 있을 수 있습니다. 가령 16비트OS에서 int 는 16비트이고, 32비트OS에서 int 는 32비트입니다. 여기서는 일반적으로 가장 널리 쓰이는 "비주얼C++ (32비트 버전)"를 기준으로 한 것입니다.

정수 자료형

실수 자료형

 출처 : http://mwultong.blogspot.com/2006/09/c-char-int-float-data-type-ranges.html

리눅스 부팅 프로세스 연구 (한글)
Master Boot Record 부터 사용자 공간 애플리케이션 까지 부팅 가이드

난이도 : 초급

M. Tim Jones, Consultant Engineer, Emulex

2006 년 8 월 18 일

리눅스® 시스템의 부팅 과정은 많은 단계들을 거칩니다. 표준 x86 데스크탑을 부팅하든 아니면 PowerPC®를 부팅하든 그 단계는 놀랍게도 많이 비슷합니다. 이 글에서는 리눅스 부팅 과정을 초기 부트스트랩부터 첫 번째 사용자 애플리케이션의 시작 단계 까지 설명합니다. 아울러 부트 로더, 커널 디컴프레션(decompression), 초기 RAM 디스크, 기타 리눅스 부트 엘리먼트를 설명합니다.

초기에 컴퓨터를 부트스트랩(bootstrapping) 한다고 하면 부트 프로그램이 포함된 종이 테이프를 공급하거나 프론트 패널 address/data/control 스위치를 사용하여 부트 프로그램을 직접 로딩하는 것을 의미했다. 오늘날 컴퓨터에는 부팅 과정을 단순화시키는 장치들이 장착되어 있지만 꼭 그렇게 단순한 것 같지는 않다.

리눅스 부팅 과정을 보다 높은 시각에서 조망해야지만 전체적으로 볼 수 있다. 그런 다음 각각의 단계를 자세히 살펴봐야겠다. 곳곳에 첨부한 소스 자료가 커널 트리를 연구하는데 도움이 될 것이다.


개요

그림 1은 리눅스 부트 프로세스 개요도이다.

부팅 장치를 찾으면 첫 번째 단계 부트 로더는 RAM으로 로딩되어 실행된다. 이 부트 로더는 길이는 512 바이트 미만이고 하는 일은 두 번째 단계의 부트 로더를 로딩하는 것이다.

제 2 단계 부트 로더가 RAM에 있고 실행되면 스플래시 스크린이 디스플레이 되고 리눅스와 초기 RAM 디스크 옵션(임시 루트 파일 시스템)이 메모리에 로딩된다. 이미지가 로딩될 때 2 단계 부트 로더는 제어를 커널 이미지로 전달하고 커널은 압축이 해제되어 초기화 된다. 이 때 2 단계 부트 로더는 시스템 하드웨어를 검사하고 첨부된 하드웨어 장치들을 열거하고, 루트 장치를 마운트 하고 필요한 커널 모듈을 로딩한다. 완료되면 첫 번째 사용자-공간 프로그램(init)이 시작되고 고급 시스템 초기화가 이루어진다.

여기까지가 리눅스 부팅 과정을 간략하게 묘사한 것이다. 이제 리눅스 부팅 과정을 보다 자세하게 살펴보도록 하자.


시스템 시작

시스템 시작 단계는 리눅스가 부팅되는 하드웨어에 기반하고 있다. 임베디드 플랫폼에서, 부트스트랩 환경은 시스템이 켜지거나 리셋될 때 사용된다. U-Boot, RedBoot, MicroMonitor 등이 그 예이다. 임베디드 플랫폼에는 일반적으로 부트 모니터가 장착된다. 이 프로그램들은 목표 하드웨어의 플래시 메모리의 특별한 영역에 있고 리눅스 커널 이미지를 플래시 메모리로 다운로드 하는 방식을 제공하고 이를 실행한다. 리눅스 이미지를 저장하고 부팅하는 기능 외에도 이 부트 모니터는 시스템 테스트와 하드웨어 초기화를 수행한다. 임베디드 환경에서 이러한 부트 모니터들은 제 1 부트 로더와 제 2 부트 로더를 관장한다.

PC에서 리눅스 부팅은 BIOS에서 주소 0xFFFF0로 시작된다. BIOS의 첫 번째 단계는 POST (power-on self test)이다. POST가 하는 일은 하드웨어를 검사하는 것이다. BIOS의 두 번째 단계는 로컬 장치 열거(enumeration)와 초기화이다.

BIOS 기능에 따라 사용처도 다르며, BIOS는 두 부분으로 구성된다. POST 코드와 런타임 서비스이다. POST가 완료된 후에 이것은 메모리에서 플러시(flush)되지만 BIOS 런타임 서비스는 그대로 남아있고 해당 운영 체계에서 사용할 수 있다.

운영 체계를 부팅하기 위해서 BIOS 런타임은 complementary metal oxide semiconductor (CMOS)에서 정의된 선호도 순으로 활성화 되고 부팅 가능한 장치를 찾는다. 부트 장치는 플로피 디스크, CD-ROM, 하드 디스크 파티션, 네트워크 상의 장치, USB 플래시 메모리 스틱이 될 수도 있다.

일반적으로 리눅스는 하드 디스크에서 부팅되고, Master Boot Record (MBR)에는 주 부트 로더가 포함되어 있다. MBR은 512-바이트 섹터이고 디스크의 첫 번째 섹터(sector 1 of cylinder 0, head 0)에 위치해 있다. MBR이 RAM이 로딩된 후에 BIOS는 제어권을 여기에 넘겨준다.


Stage 1 부트 로더

MBR에 있는 주 부트 로더는 512-바이트 이미지로서 프로그램 코드와 작은 파티션 테이블이 포함되어 있다. (그림 2) 첫 번째 446 바이트는 주 부트 로더이고 여기에는 실행 코드와 에러 메시지 텍스트가 포함된다. 그 다음 64 바이트는 파티션 테이블인데, 네 개의 파티션(각 16 바이트)의 레코드가 포함되어 있다. MBR은 매직 넘버(0xAA55)로 정의된 2 바이트로 끝난다. 매직 넘버는 MBR의 밸리데이션에 사용된다.

주 부트 로더의 작업은 2차 부트 로더(stage 2)를 찾아 로딩하는 것이다. 액티브 파티션을 찾기 위해 파티션 테이블을 검사한다. 액티브 파티션을 찾으면 테이블에 남아있는 파티션들을 검사하여 이들이 모두 비활성 상태인지를 확인한다. 확인이 되면 액티브 파티션의 부트 레코드는 장치에서 RAM으로 읽혀지고 실행된다.


Stage 2 부트 로더

2차 또는 제 2 단계 부트 로더는 커널 로더라고 불린다. 이 단계에서의 작업은 리눅스 커널과 선택적인 초기 RAM 디스크를 로딩하는 것이다.

주/부 부트 로더의 결합은 x86 PC 환경에서 Linux Loader (LILO) 또는 GRand Unified Bootloader (GRUB)이라고 한다. LILO는 몇 가지 단점을 갖고 있고 GRUB이 이를 수정했으므로 GRUB을 살펴보도록 하자. (GRUB과 LILO에 대한 자세한 내용은 참고자료를 참조하라.)

GRUB의 좋은 점은 리눅스 파일 시스템을 알고 있다는 점이다. LILO 처럼 디스크 상의 미가공 섹터를 사용하는 대신 GRUB은 ext2 또는 ext3 파일 시스템에서 리눅스 커널을 로딩할 수 있다. 2 단계 부트 로더를 3 단계 부트 로더로 만든다. Stage 1 (MBR)은 리눅스 커널 이미지를 포함하고 있는 특정 파일 시스템을 알고 있는 stage 1.5 부트 로더를 부팅한다. reiserfs_stage1_5 (Reiser 저널링 파일 시스템에서 로딩함) 또는 e2fs_stage1_5 (ext2 또는 ext3 파일 시스템에서 로딩함)가 좋은 예이다. stage 1.5 부트 로더가 로딩 및 실행되면 stage 2 부트 로더가 로딩될 수 있다.

stage 2가 로딩되면서 GRUB은 사용 할 수 있는 커널 리스트를 디스플레이 한다. (/etc/grub.conf에서 정의됨. /etc/grub/menu.lst 와 /etc/grub.conf의 링크 포함). 여러분은 커널을 선택하고 추가 커널 매개변수로 이를 수정할 수도 있다. 부트 프로세스에 보다 직접적인 관여를 하려면 명령행 쉘을 사용할 수도 있다.

Stage 2 부트 로더가 메모리에 있는 상태에서 파일 시스템이 참조되고 디폴트 커널 이미지와 initrd이미지가 메모리로 로딩된다. 이미지가 준비되면 stage 2 부트 로더는 커널 이미지를 호출한다.


커널

커널 이미지가 메모리에 있고 stage 2 부트 로더에서 컨트롤도 넘어왔다면 커널 단계가 시작된다. 커널 이미지는 실행 커널은 아니고 다만 압축된 커널 이미지이다. 일반적으로 이것은 zImage (압축 이미지, 512KB이하) 또는 bzImage (큰 압축 이미지, 512KB 이상)이고 이들은 이전에 zlib로 압축된 것이다. 커널 이미지의 앞에 있는 루틴은 최소한의 하드웨어 설정을 수행한 다음 커널 이미지에 포함된 커널의 압축을 풀고 이를 큰 메모리에 둔다. 초기 RAM 디스크 이미지가 있다면 이 루틴은 이것을 메모리로 옮기고 기록해 둔다. 루틴은 커널을 호출하고 커널 부팅이 시작된다.

bzImage (i386 이미지 용)가 호출되면 start 어셈블리 루틴(그림 3의 주 흐름도 참조)의 ./arch/i386/boot/head.S에서 시작한다. 이 루틴은 기본적인 하드웨어 설정을 수행하고 ./arch/i386/boot/compressed/head.S에 있는 startup_32 루틴을 호출한다. 이 루틴은 기본 환경(스택 같은)을 설정하고 Block Started by Symbol (BSS)을 청소한다. 커널은 decompress_kernel (./arch/i386/boot/compressed/misc.c에 있음)이라고 하는 C 함수를 호출하여 압축이 풀린다.

새로운 startup_32 함수(swapper 또는 process 0)에서, 페이지 테이블이 초기화되고 메모리 페이징이 실행된다. CPU 유형이 검사되고 아울러 FPU (floating-point unit)도 검사된다. start_kernel 함수가 호출되면(init/main.c) 일반(non-architecture specific) 리눅스 커널이 된다.

커널이 부팅되는 동안 stage 2 부트 로더에 의해 메모리로 로딩된 initial-RAM disk (initrd)가 RAM으로 복사 및 마운트 된다. initrd는 RAM에서 임시 루트 파일 시스템의 역할을 하고 커널이 물리적 디스크를 마운트 하지 않고도 완전히 부팅될 수 있도록 한다. 주변 기기와 인터페이싱 할 때 필요한 모듈이 initrd의 일부가 될 수 있기 때문에 커널은 매우 작아질 수 있지만 그래도 여전히 많은 하드웨어 설정들을 지원한다. 커널이 부팅된 후에 루트 파일 시스템이 (pivot_root를 통해) 회전되고 이곳에서 initrd 루트 파일 시스템이 언마운트(unmount)되어 실제 루트 파일 시스템이 마운트 된다.

Init

커널이 부팅 및 초기화 된 후에 커널은 최초의 사용자 공간(user-space) 애플리케이션을 시작한다. 이것은 표준 C 라이브러리로 컴파일 된 첫 번째 프로그램이다. 이전에는 어떤 표준의 C 애플리케이션도 실행되지 않았다.

데스크탑 리눅스 시스템에서 시작된 첫 번째 애플리케이션은 일반적으로 /sbin/init이다. 하지만 꼭 이럴 필요는 없다. 임베디드 시스템은 init (/etc/inittab을 통해 설정됨)에서 제공하는 초기화를 거의 필요로 하지 않는다. 많은 경우에, 필요한 임베디드 애플리케이션을 시작하는 간단한 쉘 스크립트를 호출하곤 한다.


요약

리눅스가 그러하듯, 리눅스 부트 프로세스도 매우 유연하고 많은 프로세서와 하드웨어 플랫폼을 지원한다. 초기에는 loadlin 부트 로더가 있었다. LILO 부트 로더는 부팅 기능을 확장했지만 파일 시스템 인식 부분에서 부족했다. GRUB과 같은 최신 부트 로더가 생기면서 많은 파일 시스템(Minix 부터 Reiser 까지)에서 리눅스를 부팅할 수 있게 되었다.


필자소개

구글 툴바를 사용시 주소창에 넣은 한글도메인을 기본적으로 검색하는 기능을 지원합니다

아래와 같이 "우리은행"을 입력시 우리은행 홈페이지로 들어 가는게 아니라 우리은행을 구글에서 검색하게 됩니다

XMB란 Xross Media Bar의 약자로

PSP와 PS3에 채택된 십자가 형식의 메뉴의 인터페이스를 말하는 것이라고 하네요

아래는 PSP에서의 XMB 입니다

그리고 아래는 PS3에서의 XMB 입니다