For the below attached tcptrace output (this is taken from the site http://tcptrace.org/manual/index.html under RTT stats)
1 arg remaining, starting with 'indica.dmp.gz'
Ostermann's tcptrace -- version 6.4.5 -- Fri Jun 13, 2003
153 packets seen, 153 TCP packets traced
elapsed wallclock time: 0:00:00.128422, 1191 pkts/sec analyzed
trace file elapsed time: 0:00:19.092645
TCP connection info:
1 TCP connection traced:
TCP connection 1:
host a: 192.168.0.70:32791
host b: webco.ent.ohiou.edu:23
complete conn: yes
first packet: Thu Aug 29 18:54:54.782937 2002
last packet: Thu Aug 29 18:55:13.875583 2002
elapsed time: 0:00:19.092645
total packets: 153
filename: indica.dmp.gz
a->b: b->a:
total packets: 91 total packets: 62
. . . . . .
. . . . . .
throughput: 10 Bps throughput: 94 Bps
RTT samples: 48 RTT samples: 47
RTT min: 74.1 ms RTT min: 0.1 ms
RTT max: 204.0 ms RTT max: 38.8 ms
RTT avg: 108.6 ms RTT avg: 8.1 ms
RTT stdev: 44.2 ms RTT stdev: 14.7 ms
RTT from 3WHS: 75.0 ms RTT from 3WHS: 0.1 ms
RTT full_sz smpls: 1 RTT full_sz smpls: 1
RTT full_sz min: 79.5 ms RTT full_sz min: 0.1 ms
RTT full_sz max: 79.5 ms RTT full_sz max: 0.1 ms
RTT full_sz avg: 79.5 ms RTT full_sz avg: 0.1 ms
RTT full_sz stdev: 0.0 ms RTT full_sz stdev: 0.0 ms
post-loss acks: 0 post-loss acks: 0
So the question I have is that if you see RTT average for a->b and for b->a there is a major difference in the values. I dont expect them to be exaclty the same but the difference is quite big. I think there is something happening behind the scene in the way RTT is being calculated which I am not sure of.
Summary: Make sure you look at the RTT for the correct half of the conversation, depending on where you made the capture
This answer explains that tcptrace uses the difference between timestamps of the data segment and that of the ACK that acknowledges it to calculate RTT. This means that the RTT calculation will depend on where you are capturing the trace
For example, if you are capturing packets on node A, you will see A's ACK almost immediately after you see the corresponding segment arriving from node B and thus see a very low value for RTT in the B->A segments. For A->B segments you will be measuring the real RTT as a 'real' round-trip will have occurred between seeing the segment from A and the corresponding ACK from b.
If you made the capture on node b the situation would be reversed, and if you made the capture somewhere in the middle the 'true' RTT would be approximately the sum of A->B + B->A.
The RTT calculations are not made at the sender node. They could have been made at a point along the path. The a->b and b->a is not necessarily between the sender and receiver nodes.
It can be something like this
S--A--------->R where S is Sender and R is receiver and A is some point between S and R. a->b can represent the RTT from A to R while b->a can represent RTT from A to S.
Related
Here is my question:
We wish to send a message of size 150,000 bytes over the network. There are four hops, each of length 20km and running at 100 Mb/s. However, before sending we split the message into 1500 byte packets. What is the end-to-end delay of the message? Use speed of light in copper = c = 2 * 10^8 m/s, and round your answer to the nearest integer millisecond.
What I have so far is 48ms, which I calculated in the following fashion:
1500 bytes = 12,000 bits
12,000 bits/(100x10^6)[100Mb/s] = 0.00012s
20km/(2*10^8)[speed of light in this equation] = 1e-7
Add them up and you get 0.0001201s per hop x 4 hops = 0.0004804s -> 48ms rounded to nearest integer.
Apparently this is not correct and I cannot figure out my error. My online course has no assistance available so I'm turning to SO. If anyone can point me in the right direct, I would appreciate the help.
Edit:
I think I got it finally. The network topology looks like this:
source - link#1 - router#1 - link#2 - router#2 - link#3 - router#3 - link#4 - dest
Let's first consider it from the perspective of the source. We're sending the message packet by packet. As soon as we put the first packet on the wire, we're sending the second one, then the 3rd, etc. How long does it take to put all 100 packets on the wire?
100 * 1500B * 8(b/B) / 100 Mb/s = 12 ms
End to end delay is the time it takes to transfer the whole message from source to dest. So now that the source just put the packet #100 on the link#1, let's follow that last packet life. For that last packet it takes
20km/(2 * 10^8 m/s) = 0.1 ms - to get to the router#1
1500B * 8(b/B) / 100 Mb/s = 0.12 ms - to put it on the link#2
20km/(2 * 10^8 m/s) = 0.1 ms - to get to the router#2
1500B * 8(b/B) / 100 Mb/s = 0.12 ms - to put it on the link#3
20km/(2 * 10^8 m/s) = 0.1 ms - to get to the router#3
1500B * 8(b/B) / 100 Mb/s = 0.12 ms - to put it on the link#4
20km/(2 * 10^8 m/s) = 0.1 ms - to get to the dest
so in total it takes the last packet 0.76 ms to get to the final destination after it was put on the link#1 by the source. Which gives us the final answer:
12 ms + 0.76 ms = 12.76 ms ~= 13 ms
Original answer:
Below is apparently a correct answer but I don't understand why we don't multiply the second part of the sum by 4, there are 4 hoops after all. If somebody can explain, I would be very grateful.
EXPLANATION
13ms. We calculate the end-to-end delay as follows:
4 * (1500B * 8(b/B) / 100 Mb/s + 20km/2 * 10^8 m/s)
+ (150,000/1500 - 1) * (1500 * 8 (b/B) / 100Mb/s) = 12.76 ms
4 Hops means
S->r1->r2->r3->D
No. of packets is =15*10^4 / 1500 = 100 packets
T.D=> 15*10^2*8 / 100* 10^6 (this is for 1 packet) = 0.12ms
P.D=> 20*10^3 / 2* 10^8 = 0.1ms
Total is =>0.1+0.12 = 0.22ms
4 hops takes => 0.22*4=0.88ms
0.88ms is for 1st packet only
The first packet will take 0.88 ms to reach D.
While first packet was reaching D, other packets must have been processing in parallel. So D will receive remaining packets 1 packet per 0.12 ms from R2.
So other 99 packets take 0.12*99 ms.//Only transmission delay is multiplied by (N-1) packets
Answer is => 0.88 + 0.12*99=12.76ms
FORMULA for calculating any such type of question->
Total delay=No. of hops(1st packet total delay) + TransmissionN - (Transmission delay + Processing + Queuing)
OR
(IF processing delay and queuing delay = 0 then)
Total delay=No. of hops*(1st packet total delay) + Transmission delay*(N - 1)
PPT HIGHLY RECOMMENDED EXAMPLES
Another Example
Calculate the time for one packet (p/r + l/c):
single packet size : 1500 byte * 8 = 12000 bit
network speed : 100 Megabit * 1 000 000 = 100 000 000 bit / sec
12 000 bit / 100 000 000 bit/sec = 0.00012 sec (0.12 ms)
propagation delay: 20 000 / (2 * 10 ^ 8) = 0.0001 sec (0.1 ms)
total delay during one hop: 0.12 ms + 0.1 ms = 0.22 ms
4 hops so total time in ms = 4 * 0.22 ms = 0.88 ms
The second part only needs to calculate how long it takes to put the rest onto the link (remember, you are not waiting for the first packet to arrive at the destination before putting the second on the link)
remainder to put on the link = 150 000 byte - 1 500 byte = 148 500byte
which is (148500 * 8 =) 1 188 000 bit
So 1 188 000 bit / 100 000 000 bit/sec = 0.01188 sec (**11.88ms**)
Total is then
11.88 ms + 0.88 ms = 12.76 (13 due to rounding to nearest integer ms)
For individual bits, the router works in store-and-forward mode, i.e. it waits for the whole packet to arrive before moving on to the next hop.
When you send packets, you do not need to wait for all packets to arrive to the router before sending on an individual packet.
Youhe "packetization delay" for packets themselves which only depends on the slowest link, the size of the packet and the number of packets.
My interpretation:
The first question is to illustrate how long it takes if we don't break down the packet
The second question is to illustrate the advantage of break down to a smaller size
As explained in video, if we don't break it down, the transmission will need to wait for complete data transfer for each hop. But if we break it down, the first will wait shorter (smaller size), the latter packets can then load to the network to streamline the transmission.
End to End Delay can be calculated by multiplying number of links with total delay in network.
you can use this online End to End Delay tool.
The key point is, the router needs to wait until a full packet received, then it starts to forward the packet to next router. In the first case, when the 150,000 bytes message is not divided into 100 packets of 1500 bytes, each router needs to wait (150,000 * 8) / (100 * 10^6) seconds until it can start to forward the message. i.e., the router is stuck for this time long. However, in the second case, if the message is divided, then each router only needs to wait (1500 * 8) / (100 * 10^6) seconds before it starting to forward the packet, which is 1/100 of the previous case. Because in this case, it is a kind of pipelining, the router is able to forward the part of message arrived while receiving the rest of message. At the fourth router, or just the destination, the total travel time of the message is calculated when the whole message is arrived. In the first case, the last router is waiting and do nothing, so the waiting time is just (150,000 * 8) / (100 * 10^6) seconds. In the second case, the last router first waits for (1500 * 8) / (100 * 10^6) seconds, then, since it is the last router, the destination, it does not need to forward arrived message, the only job for it is to wait until all the message arrived. Therefore, it waits for another 99 packets to arrive, which is just ((150,000 - 1500) * 8) / (100 * 10^6) seconds. Finally, the total delay for the first case is 4 * (150,000 * 8) / (100 * 10^6) + 4 * (20 * 10^3) / (2 * 10^8) = 48 ms, and the total delay for the second case is 3 * (1500 * 8) / (100 * 10^6) + (150,000 * 8) / (100 * 10^6) + 4 * (20 * 10^3) / (2 * 10^8) = 12.76 ms. Note that in two cases, there is no difference it their propagation delays, the difference is in the stuck time of each router.
I'm currently learning about transmission delay and propagation. I'm really having a tough time with the conversions. I understand how it all works but I cant get through the converting. For example:
8000bits/5mbps(mega bits per second) I have no idea how to do this conversion , I've tried looking online but no one explains how the conversion happens. I'm supposed to get 1.6 ms, but I cannot see how the heck that happens. I tried doing it this way, 8000b / 5x10^6 b/s but that gives me 1600 s.
(because that would not fit in a comment):
8000 bits = 8000 / 1000 = 8 kbit, or 8000 / 1000 / 1000 = 0.008 mbit.
(or 8000 / 1024 = 7.8 Kibit, or 8000 / 1024 / 1024 = 0.0076 Mibit,
see here: https://en.wikipedia.org/wiki/Data_rate_units)
Say you have a throughput of 5mbps (mega bits per second), to transmit your 8000 bits that's:
( 0.008 mbit) / (5 mbit/s) = 0.0016 s = 1.6 ms
That is, unit wise:
bit / (bit/s)
bit divided by bit => the bit unit disappear,
then divide and divide by seconds = not "something per second", but second,
result unit is second.
My MPI Program to measure broadcast time:
MPI_Barrier(MPI_COMM_WORLD);
total_mpi_bcast_time -= MPI_Wtime();
MPI_Bcast(data, num_elements, MPI_INT, 0, MPI_COMM_WORLD);
MPI_Barrier(MPI_COMM_WORLD);
total_mpi_bcast_time += MPI_Wtime();
We need MPI_Barrier to wait until all processes do its jobs completed (synchronization) .But in fact, MPI_Barrier is a collective communication(all processes report to root process to continue program).And so our measured time will be Barrier_time + Broadcast_time.
So how to measure only broadcast time correctly ???
This is result from Scalasca:
Estimated aggregate size of event trace: 1165 bytes
Estimated requirements for largest trace buffer (max_buf): 292 bytes
Estimated memory requirements (SCOREP_TOTAL_MEMORY): 4097kB
(hint: When tracing set SCOREP_TOTAL_MEMORY=4097kB to avoid intermediate flushes
or reduce requirements using USR regions filters.)
flt type max_buf[B] visits time[s] time[%] time/visit[us] region
ALL 291 32 0.38 100.0 11930.30 ALL
MPI 267 28 0.38 100.0 13630.27 MPI
COM 24 4 0.00 0.0 30.54 COM
MPI 114 8 0.00 0.1 33.08 MPI_Barrier
MPI 57 4 0.00 0.0 26.53 MPI_Bcast
MPI 24 4 0.00 0.2 148.50 MPI_Finalize
MPI 24 4 0.00 0.0 0.57 MPI_Comm_size
MPI 24 4 0.00 0.0 1.61 MPI_Comm_rank
MPI 24 4 0.38 99.7 95168.50 MPI_Init
COM 24 4 0.00 0.0 30.54 main
But i don't know how they measure it.Even i run it on a single machine,is MPI_Broadcast cost really 0% ???
From your example it seems that what you want to know is "the time from the first process entering the Bcast call until the time of the last process leaving the Bcast call". Note that not all of that time is actually spent inside MPI_Bcast. In fact, it is perfectly possible that some processes have left the Bcast call before others have even entered.
Anyway, probably the best way to go is to measure the time between the first Barrier and the Bcast exit on each process, and use a Reduction to find the maximum:
MPI_Barrier(MPI_COMM_WORLD);
local_mpi_bcast_time -= MPI_Wtime();
MPI_Bcast(data, num_elements, MPI_INT, 0, MPI_COMM_WORLD);
local_mpi_bcast_time += MPI_Wtime();
MPI_Reduce(&local_mpi_bcast_time, &total_mpi_bcast_time, 1, MPI_DOUBLE,
MPI_MAX, 0, MPI_COMM_WORLD);
This is still not 100% accurate because processes may leave the barrier at slightly different times, but about the best you can get with MPI means.
I also suggest you take a look at the performance analysis tools suggested by Zulan, because they take care of all the mutli-process communication idiosyncrasies.
I'm having some difficulty calculating the total time it takes a packet to get from A to B, the question is:
"We have 200 bytes of data to send from A to B, with a distance of 200km between them. Calculate the total transmission time, assuming the speed of the signal is 200,000 km/s and that the data rate is 1Mbps and that a header of 40 bytes has to be added to the data before it is sent."
My understanding is that at some point you need to factor in propagation and the speed of light (??) but I'm unsure if it's needed in this case. Is there a formula which can be used to work these types of question out?
So we have a total of 200 bytes of payload + 40 bytes of header = 240 bytes. The data can be put on the wire at a rate of 1 Mbps which equals 1,000,000 bits per second (unless the question actually means Mibps which is 1,048,576 bits per second; we'll work on the assumption that Mbps is correct and it's 1,000,000).
240 bytes is equal to 1920 bits (240 * 8), so it takes
1920 bits / 1,000,000 bits per second = 0.00192 seconds
to get the data on the wire.
Now, for the data to be transmitted, it has to travel 200 km at a rate of 200,000 km/s.
200km / 200,000(km/s) = 0.001 seconds.
Now, to take the data from the wire and read into computer in location B takes the same amount of time as putting the data on the wire = 0.00192 seconds.
So the total amount of time is equal to
0.00192 + 0.001 + 0.00192 = 0.00484 seconds = 4.84 milliseconds.
I am trying to understand how to calculate the throughput for a sliding window data transmission, by solving some numerical examples. Below is the example followed by my analysis.
Example
Host A is sending data to Host B over a full duplex link. A and B are using sliding window protocol, with send and receive window sizes of 5 each. Data packets sent only from A to B, are 1000 bytes each in size, and transmission time for one such packet is 50 us. Propagation delay is 200 us. Assume Ack packets need negligible transmission time. What is the maximum achievable throughput in Mbps?
A. 7.69 B. 11.11 C. 12.33 D. 15.00
Analysis
Round trip-time is 2 * 200 us = 400 us. ... A
Time required to fill the sending window = window size (5) * transmission time of 1 packet (50 us) = 250 us. ... B
Since B < A, sender has to wait for ack to 1st packet before sending the 6th packet. This ack appears at 450 us. (round-trip time is 400 us.)
Between 250 us and 450 us, the sender is idle, that is no new data is being sent over the line.
Assuming sender has an unlimited supply of data frames, the above cycle would repeat.
Thus, in every 450 us, sender sends 5 packets = 5 * 1000 * 8 = 40000 bits of data.
Hence, throughput = 40000 bits / 450 us = 84.7710 megabits per second. (84.7710 Mbps)
However, this is not one of the given options, not even close! Is there any mistake in my analysis above?
As I stated in my comment, your analysis and calculation method is correct. However, I'd check my calculator if I were you because 40000 bits / 450 us = 88.88...Mbps, not 84.7710 Mbps.
I do not think it is mere coincidence that 88.88 is just 11.11*8, so it's a fair assumption that the question was actually asking to get megabytes per second instead of megabits per second.
Throughput = Window /RTT
Here Window size = 5*1000 bytes = 5000 bytes.
RTT = 50us + 2*200 us=> 450us.
Therefore Throughput= 5000 bytes/450 us = 11.11Mpbs