'開發 - Computer/Network'에 해당되는 글 6건

  1. 2013.10.04 AWS Region별 속도 테스트
  2. 2011.04.14 (Recommend) WWW (HTTP/HTTPS/FTP) Client using WININET
  3. 2009.10.16 802.11b 간단한 성능 계산
  4. 2009.09.11 Snoop과 TCPW+의 단점...
  5. 2008.04.02 ns-2: New Trace Format 1
  6. 2008.02.24 IEEE 802.11 용어 몇 가지 1

모든 테스트는 BORANET(by LGU+) 망의 PC에서 수행.



CloudPing을 이용한 Latency 테스트


US-East (Virginia)

234 ms

US-West (California)

141 ms

US-West (Oregon)

158 ms

Europe (Ireland)

298 ms

Asia Pacific (Singapore)

202 ms

Asia Pacific (Sydney)

152 ms

Asia Pacific (Japan)

67 ms

South America (Brazil)

341 ms

참고: http://www.cloudping.info/




EC2 업/다운로드 Throughput 테스트


US-West(Oregon), Asia-Pacific(Singapore), Asia-Pacific(Japan)의 EC2 인스턴스가 대상.

업로드는 rsync, 다운로드는 wget을 이용.


결과:

US-West(Oregon), Asia-Pacific(Singapore):

업/다운로드 모두 600~1200 KB/s의 속도를 보임.

동시 업/다운로드에서 속도 저하 없음.

긴 Latency로 인한 다운로드 속도의 변화폭은 그리 크지 않음.


Asia-Pacific(Japan):

1.6~1.8 MB/s 의 양호한 속도.



비고:

1. Olleh uCloud의 VM에서 테스트를 한 결과, 3 MB/s 쯤에서 다운로드가 완료되었는데 속도는 계속 상승 중이었음. 데이타 센터의 기간망이 빠르긴 하겠지만, 그래도 KT 망에서 더 빠른 속도를 낼 것이라 희망적으로 예상.



S3 업로드 Throughput 테스트


결과#1 US-West(Oregon):

200 ~ 350 KB/s 정도로 조금 변동폭 있음.

긴 Latency로 인한 다운로드 속도의 변화폭은 그리 크지 않음.


결과#2 Asia-Pacific(Singapore)

250 KB/s 정도로 균일함.


결과#3 Asia-Pacific(Japan)

최대 750 KB/s 까지 상승했지만 대체로 600 KB/s 안팎 수준에서 안정.




비고:

1. 모든 업/다운로드가 10 KB/s 수준의 속도에서 시작하는 것으로 보아, 초기 TCP Window 크기가 작은 것으로 추정됨.


Posted by 배트
,
Windows/C++ 용 HTTP 라이브러리는 그냥 이게 갑인 듯.
http://www.codeproject.com/KB/IP/w3client.aspx
Posted by 배트
,
RTS/CTS 없음

Average CW

15

blocks

SlotTime

20

us

SIFS

10

us

DIFS

50

us

Preamamble

144

bit

PLCPHeader

48

bit

PLCPRate

1000000

bps

FCSLen

32

bit

BasicRate

1000000

bps

DataRate

11000000

bps

TCPSegmentSize

1460

Bytes

TCPDataFrameSize

1520

Bytes

TCPAckFrameSize

68

Bytes

MacAckFrameSize

28

Bytes

PropagationDelay

2

us





 

TCP Data

DIFS

Backoff

Preamble

PLCP

Data

FCS

Delay

Total

time(us)

50.00

300.00

144.00

48.00

1105.45

2.91

2.00

1652.36

 

MAC Ack

SIFS

 

Preamble

PLCP

Data

FCS

Delay

Total

time(us)

10.00

 

144.00

48.00

20.36

2.91

2.00

227.27

 

TCP Ack(us)

DIFS

Backoff

Preamble

PLCP

Data

FCS

Delay

Total

time(us)

50.00

300.00

144.00

48.00

0.00

2.91

2.00

546.91



TCP 프레임 하나 전송에 걸리는 시간 = TCP_Data + TCP_Ack + 2 * MAC_Ack = 2644 us
별다른 지연이 없다고 할 때,TCP에서 측정한 Goodput = 4417549 bps = 539.25 KB/s

생각보다 적게 나온다. 계산 잘못했나?ㅋㅋ
Posted by 배트
,
Snoop, however, has its own limitations. First, it requires a snoop proxy in the base station. Also, if the TCP sender is the mobile, the TCP code must be modified to respond to Explicit Loss Notification (ELN) packets from the base station.

Saverio Mascolo, Politecnico Di Bari, Claudio Casetti, Politecnico Di Torino, Mario Gerla, M. Y. Sanadidi, and Ren Wang
"TCP Westwood: Bandwidth Estimation for Enhanced Transport over Wireless Links"


TCP Westwood+, in contradiction to the initial version of Westwood, computes one sample of available bandwidth every RTT using all data acknowledged in the specific RTT, therefore obtaining more accurate estimates (Fig. 6a). However, from the perspective of real-time delivery, Westwood+’s efficiency is not evident, since it delivers a considerable amount of delayed packets (Fig. 6d). Inline with our analytical approach, reaching the downlink capacity (i.e. flows 30–50) maximizes transmission time T(n) and results in variable transmission periods which impact video delivery. The protocol responds inappropriately to the variation in the rate of arriving ACKs, since the disturbed inter-ACK spacing reflects the fluctuations in the receiving rate, due to congestion incidents.

Vassilis Tsaoussidis, Panagiotis Papadimitriou
"On TCP performance over asymmetric satellite links with real-time constraints"


TCPW나 TCPW+의 단점은 명확하지가 않네...
Posted by 배트
,
간접출처
http://overegoz.tistory.com/669

References

[1] http://4ellene.net/tt/1075


This revised trace support is backwards compatible with the old trace formatting and can be enabled by the following command:


$ns use-newtrace


This command should be called before the universal trace command $ns trace-all trace-fd. Primitive use-newtrace sets up new format for wireless tracing by setting a simulator variable called newTraceFormat. Currently this new trace support is available for wireless simulations only and shall be extended to rest of in the near future.




Event type : 이벤트

In the traces above, the first field (as in the older trace format) describes the type of event taking place at the node and can be one of the four types:

S : send / r : receive / d : drop / f : forward


General tag

The second field starting with "-t" may stand for time or global setting

-t : time / -t : * (global setting)


Node property tags

This field denotes the node properties like node-id, the level at which tracing is being done like agent, router or MAC. The tags start with a leading "-N" and are listed as below:

-Ni: node id

-Nx: node's x-coordinate

-Ny: node's y-coordinate

-Nz: node's z-coordinate

-Ne: node energy level

-Nl: trace level, such as AGT, RTR, MAC

-Nw: reason for the event. The different reasons for dropping a packet are given below:

"END" DROP_END_OF_SIMULATION

"COL" DROP_MAC_COLLISION

"DUP" DROP_MAC_DUPLICATE

"ERR" DROP_MAC_PACKET_ERROR

"RET" DROP_MAC_RETRY_COUNT_EXCEEDED

"STA" DROP_MAC_INVALID_STATE

"BSY" DROP_MAC_BUSY

"NRTE" DROP_RTR_NO_ROUTE i.e no route is available.

"LOOP" DROP_RTR_ROUTE_LOOP i.e there is a routing loop

"TTL" DROP_RTR_TTL i.e TTL has reached zero.

"TOUT" DROP_RTR_QTIMEOUT i.e packet has expired.

"CBK" DROP_RTR_MAC_CALLBACK

"IFQ" DROP_IFQ_QFULL i.e no buffer space in IFQ.

"ARP" DROP_IFQ_ARP_FULL i.e dropped by ARP

"OUT" DROP_OUTSIDE_SUBNET i.e dropped by base stations on receiving routing updates from nodes outside its domain.

Packet information at IP level

The tags for this field start with a leading "-I" and are listed along with their explanations as following:

-Is: source address.source port number

-Id: dest address.dest port number

-It: packet type

-Il: packet size

-If: flow id

-Ii: unique id

-Iv: ttl value

Next hop info

This field provides next hop info and the tag starts with a leading "-H".

-Hs: id for this node

-Hd: id for next hop towards the destination.

Packet info at MAC level

This field gives MAC layer information and starts with a leading "-M" as shown below:

-Ma: duration

-Md: dst's ethernet address

-Ms: src's ethernet address

-Mt: ethernet type

Packet info at "Application level"

The packet information at application level consists of the type of application like ARP, TCP, the type of adhoc routing protocol like DSDV, DSR, AODV etc being traced. This field consists of a leading "-P" and list of tags for different application is listed as below:

-P arp

Address Resolution Protocol. Details for ARP is given by the following tags:

-Po: ARP Request/Reply

-Pm: src mac address

-Ps: src address

-Pa: dst mac address

-Pd: dst address

-P dsr

This denotes the adhoc routing protocol called Dynamic source routing. Information on DSR is represented by the following tags:

-Pn: how many nodes traversed

-Pq: routing request flag

-Pi: route request sequence number

-Pp: routing reply flag

-Pl: reply length

-Pe: src of srcrouting->dst of the source routing

-Pw: error report flag ?

-Pm: number of errors

-Pc: report to whom

-Pb: link error from linka->linkb

-P cbr

Constant bit rate. Information about the CBR application is represented by the following tags:

-Pi: sequence number

-Pf: how many times this pkt was forwarded

-Po: optimal number of forwards

-P tcp

Information about TCP flow is given by the following subtags:

-Ps: seq number

-Pa: ack number

-Pf: how many times this pkt was forwarded

-Po: optimal number of forwards

This field is still under development and new tags shall be added for other applications as they get included along the way.


s -t 0.267662078 -Hs 0 -Hd -1 -Ni 0 -Nx 5.00 -Ny 2.00 -Nz 0.00 –Ne -1.000000 -Nl RTR -Nw --- -Ma 0 -Md 0 -Ms 0 -Mt 0 –Ii 20 -Is 0.255 -Id -1.255 –It


-S : 이벤트 ex) sent

-t 0.267662078 : 시간

-Hs 0 : 소스 노드(Hs) 0 에서

-Hd -1 : 목적지 노드(Hd) 1

-Ni 0 : 소스 노드 ID 는 0

-Nx 5.00 : x-co-ordinate는 5.00

-Ny 2.00 : s y-co-ordinate 은 2.00

-Nz 0.00 : z-co-ordinate은 0.00

–Ne -1.000000 : 에너지 레벨은 1.000000

-Nl RTR : 트레이스 레벨은 RTR

-Nw --- : 노드 이벤트는 없음

-Ma 0 : The MAC level information is given by duration (Ma) 0

-Md 0 : 목적지 이더넷 주소 (Md)0

-Ms 0 : 발신지 이더넷 주소(Ms)0

-Mt 0 : 이더넷 종류 0

–Ii 20 : The IP packet level information like packet id (Ii)

-Is 0.255 : 발신자 주소.발신자 포트번호

-Id -1.255 : 목적지 주소.목적지 포트번호

–It

Here, we see that a packet was sent (s) at time (t) 0.267662078 sec, 
from source node (Hs) 0 to destination node (Hd) 1.
The source node id (Ni) is 0, it's x-co-ordinate (Nx) is 5.00,
it's y-co-ordinate (Ny) is 2.00, it's z-co-ordinate (Nz) is 0.00,
it's energy level (Ne) is 1.000000, the trace level (Nl) is
RTR and the node event (Nw) is blank. The MAC level information is
given by duration (Ma) 0, destination Ethernet address (Md) 0,
the source Ethernet address (Ms) is 0 and Ethernet type (Mt) is 0.
The  IP packet level information like packet id (Ii), 
source address.source port number is given by (Is) while the destination address.
destination port number is (Id).
Posted by 배트
,
사용자 삽입 이미지
Hidden node(terminal) problem
Wireless networking에서, AP와 통신이 가능한 다른 두 노드가 서로 통신이 불가능한 경우 발생한다.











Exposed node(terminal) problem

Wireless networking에서, 두 개의 이웃한 송신 노드가 서로 다른 수신 노드에게 전송을 시도할 때 서로 방해받는 현상. 이웃한 송신 노드 송신 노드 A가 다른 수신 노드 B에게 전송을 시도를 할 때, 이웃한 송신 노드 C가 A의 권외(out of range)인 수신 노드 D에게 이미 전송을 하고 있다면, A와 D는 권외임에도 불구하고 A의 전송은 방해를 받는다.
사용자 삽입 이미지












RTS/
CTS
Request to Send / Celar to Send
802.11에서, 송신을 원하는 노드는 RTS를 보내고, 수신 노드는 CTS로 회답하여 연결을 초기화한다.
RTS/CTS로 초기화가 되면 두 노드는 통신 가능으로 간주하여 전송을 시작하고(AP의 정보에 의존하지 않음, Hidden node problem 해결), RTS/CTS를 모두 수신한 이웃 노드는 전송을 방해 받지만, RTS/CTS 중 하나만 수신한 노드는 다른 노드와 전송이 가능하다.(Exposed node problem 해결)


이미지 출처 : 위키피디아
Posted by 배트
,