Changes between Version 7 and Version 8 of Old/Documentation/OTG/UserManual


Ignore:
Timestamp:
Oct 6, 2005, 4:52:49 PM (19 years ago)
Author:
zhibinwu
Comment:

—

Legend:

Unmodified
Added
Removed
Modified

  • Old/Documentation/OTG/UserManual

    v7 v8  
    176176== Understanding Measurements  ==
    177177
    178 We defined three OML tables which contains measurments:
     178We defined three OML tables which contains measurements:
    179179||senderport||receiverport||flow||
    180180||pkt_seqno[[BR]]pkt_size[[BR]]gen_timestamp[[BR]]tx_timestamp||pkt_seqno[[BR]]flow_no[[BR]]rcvd_packet_size[[BR]]rx_timestamp[[BR]]rssi[[BR]]xmit_rate||flow_ no[[BR]]sender_ip[[BR]]sender_port||
    181181
    182 === Explantation of the Metric ===
     182=== Explanation of the Metric ===
    183183|| '''name''' || '''usage''' || '''unit''' ||
    184184||pkt_seqno || Packet sequence number in the sender stream, this number is stamped in UDP payload and can be recovered in receiver side||  ||
    … …  
    203203
    204204Suppose one OTG sends packet to one OTR. The senderport table will record all information in sender side.
    205 the receiveport table will record per-packet informatino in receiver side.
     205the receiveport table will record per-packet information in receiver side.
    206206 * '''Offerload''': by summing the pkt_size metric in one second, the value indicates how many Bps traffic is supplied
    207207 * '''Throughput''': by summing the rcvd_packet_size metric in one second, the value indicates how many Bps traffic is received
    208208 * '''Packet loss''' : A good use of '''pkt_seqno''' is that by comparing the pkt_seqno of this two tables, you could find exactly what packet gets lost in the LUT (Link Under Test). But this feature cannot be used for TCP traffic.
    209  * '''Delay''': The packet delay could be determined by substracting rx_timestamp with tx_stamp of the same packet. This feature cannot be used for TCP traffic because TCP does not receive packets in frames.
     209 * '''Delay''': The packet delay could be determined by subtracting rx_timestamp with tx_stamp of the same packet. This feature cannot be used for TCP traffic because TCP does not receive packets in frames.
    210210 * '''Jitter''': (option feature) by apply a differential filter to rx_timestamp metric, the jitter could be determined.
    211211
    212 In this case, the 3rd table will not be very useful becasue there is only one flow.
     212In this case, the 3rd table will not be very useful because there is only one flow.
    213213
    214214=== Case 2: Many-to-One Communication ===
    … …  
    218218
    219219Suppose multiple OTGs run in different stations and all send packets to one OTR. In this case, the receiverport table will record all packets from different OTG clients.
    220 To dsitinguish the souce address of a packet, '''flow_no''' is the approriate identifier.  Then user could check "flow" table for further information about this flow_no, including sender'IP address and port number.
    221 
     220To distinguish the source address of a packet, '''flow_no''' is the appropriate identifier.  Then user could check "flow" table for further information about this flow_no, including sender'IP address and port number.