Steven,
** What is the scenario in terms of radio models, mobility and traffic
generation?
Previously I had recorded the behavior of chargen being sent between the
only two nodes of an 802.11g adhoc network. One of the nodes was stationary
and the other node was driven round on a vehicle at moderate speed. I then
replayed the location and pathloss in an EMANE emulator while using the
same two machines to generate and receive the chargen traffic. So both NEMs
are configured to have one 802.11g wireless interface and traffic is
injected into EMANE via the raw transport. Only one NEM is moved in EMANE
because the program on the traffic generating machine wants GPS location to
associate with the TCP statistics it gathers from the kernel. As I
understand, since I am setting the pathloss EMANE doesn't actually care
about the location of the NEM and it shouldn't effect the packet loss
calculations.
** What is the outcome you expect in terms of traffic completion based
on your scenario?
Due to the over the air rate not being set accurately, it is too low, I
expect to see very little to no packet loss.
** What is the actual outcome you are observing? How is it different
from what
you expected?
What I actually observe is somewhere in the range of 5% packet loss as
recorded at the traffic source and sink. I expected the graph of the TCP
congestion window of the traffic flowing through EMANE to show the classic
sawtooth pattern with reasonably large values, in the 150-300 range, for
the peaks. Instead I see the congestion window max out at 6. I have
included the output of tcpdump from the perspective of the traffic source
and sink of the beginning of the TCP stream. The time on the two machines
isn't synchronized but it doesn't have to be for my purposes. As you can
see in the tcpdump output the second and third data packets (seq 1449:2897
and seq 2897:4345) from the source are never received by the sink and must
be retransmitted.
Traffic source:
16:31:16.513147 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [S],
seq 1613918473, win 29200, options [mss 1460,sackOK,TS val 1628684 ecr
0,nop,wscale 7], length 0
16:31:16.551365 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [S.],
seq 88356732, ack 1613918474, win 5792, options [mss 1460,sackOK,TS val
1651109402 ecr 1628684,nop,wscale 6], length 0
16:31:16.551396 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
ack 1, win 229, options [nop,nop,TS val 1628693 ecr 1651109402], length 0
16:31:16.551445 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
seq 1:1449, ack 1, win 229, options [nop,nop,TS val 1628693 ecr
1651109402], length 1448
16:31:16.567436 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 1449, win 136, options [nop,nop,TS val 1651109441 ecr 1628693], length 0
16:31:16.567455 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
seq 1449:2897, ack 1, win 229, options [nop,nop,TS val 1628697 ecr
1651109441], length 1448
16:31:16.567464 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [P.],
seq 2897:4345, ack 1, win 229, options [nop,nop,TS val 1628697 ecr
1651109441], length 1448
16:31:16.628993 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
seq 4345:5793, ack 1, win 229, options [nop,nop,TS val 1628713 ecr
1651109441], length 1448
16:31:16.639791 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 1449, win 136, options [nop,nop,TS val 1651109512 ecr
1628693,nop,nop,sack 1 {4345:5793}], length 0
16:31:16.640995 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
seq 1449:2897, ack 1, win 229, options [nop,nop,TS val 1628716 ecr
1651109512], length 1448
16:31:16.656177 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 2897, win 181, options [nop,nop,TS val 1651109529 ecr
1628716,nop,nop,sack 1 {4345:5793}], length 0
16:31:16.656196 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
seq 5793:7241, ack 1, win 229, options [nop,nop,TS val 1628719 ecr
1651109529], length 1448
16:31:16.671289 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 2897, win 181, options [nop,nop,TS val 1651109544 ecr
1628716,nop,nop,sack 1 {4345:7241}], length 0
16:31:16.671307 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [P.],
seq 2897:4345, ack 1, win 229, options [nop,nop,TS val 1628723 ecr
1651109544], length 1448
16:31:16.671318 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
seq 7241:8689, ack 1, win 229, options [nop,nop,TS val 1628723 ecr
1651109544], length 1448
16:31:16.688281 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 7241, win 227, options [nop,nop,TS val 1651109560 ecr 1628723], length 0
16:31:16.688301 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [P.],
seq 8689:10137, ack 1, win 229, options [nop,nop,TS val 1628727 ecr
1651109560], length 1448
16:31:16.688373 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 8689, win 272, options [nop,nop,TS val 1651109562 ecr 1628723], length 0
Traffic sink:
16:49:54.562683 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [S],
seq 1613918473, win 29200, options [mss 1460,sackOK,TS val 1628684 ecr
0,nop,wscale 7], length 0
16:49:54.584385 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [S.],
seq 88356732, ack 1613918474, win 5792, options [mss 1460,sackOK,TS val
1651109402 ecr 1628684,nop,wscale 6], length 0
16:49:54.601177 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
ack 1, win 229, options [nop,nop,TS val 1628693 ecr 1651109402], length 0
16:49:54.602073 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
seq 1:1449, ack 1, win 229, options [nop,nop,TS val 1628693 ecr
1651109402], length 1448
16:49:54.602108 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 1449, win 136, options [nop,nop,TS val 1651109441 ecr 1628693], length 0
16:49:54.673097 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
seq 4345:5793, ack 1, win 229, options [nop,nop,TS val 1628713 ecr
1651109441], length 1448
16:49:54.673128 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 1449, win 136, options [nop,nop,TS val 1651109512 ecr
1628693,nop,nop,sack 1 {4345:5793}], length 0
16:49:54.689436 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
seq 1449:2897, ack 1, win 229, options [nop,nop,TS val 1628716 ecr
1651109512], length 1448
16:49:54.689468 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 2897, win 181, options [nop,nop,TS val 1651109529 ecr
1628716,nop,nop,sack 1 {4345:5793}], length 0
16:49:54.704522 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
seq 5793:7241, ack 1, win 229, options [nop,nop,TS val 1628719 ecr
1651109529], length 1448
16:49:54.704549 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 2897, win 181, options [nop,nop,TS val 1651109544 ecr
1628716,nop,nop,sack 1 {4345:7241}], length 0
16:49:54.721072 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [P.],
seq 2897:4345, ack 1, win 229, options [nop,nop,TS val 1628723 ecr
1651109544], length 1448
16:49:54.721098 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 7241, win 227, options [nop,nop,TS val 1651109560 ecr 1628723], length 0
16:49:54.722747 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [.],
seq 7241:8689, ack 1, win 229, options [nop,nop,TS val 1628723 ecr
1651109544], length 1448
16:49:54.722776 IP 192.168.100.2.10240 > 192.168.100.25.56502: Flags [.],
ack 8689, win 272, options [nop,nop,TS val 1651109562 ecr 1628723], length 0
16:49:54.737733 IP 192.168.100.25.56502 > 192.168.100.2.10240: Flags [P.],
seq 8689:10137, ack 1, win 229, options [nop,nop,TS val 1628727 ecr
1651109560], length 1448
Is there any resource that avgTimedEventLatencyRatio is especially
sensitive to, or do I just need more powerful machines to run the emulator
instances?
John
On Wed, May 20, 2015 at 11:04 PM, Steven Galgano <[email protected]>
wrote:
> John,
>
> I'm having a difficult time understanding the issue you are trying to
> convey. Clearly describe the experiment you are performing:
>
> * What is the scenario in terms of radio models, mobility and traffic
> generation?
>
> * What is the outcome you expect in terms of traffic completion based on
> your scenario?
>
> * What is the actual outcome you are observing? How is it different from
> what you expected?
>
> From your previously included control port outputs, the emulator is not
> dropping any over-the-air transmissions between your two NEMs. It looks
> like your pathloss values are not high enough to cause loss.
>
> I am troubled by your avgTimedEventLatencyRatio values. Anything close
> to 1 is no good, your machines running the emulator instances may be
> resource limited.
>
> --
> Steven Galgano
> Adjacent Link LLC
> www.adjacentlink.com
>
_______________________________________________
emane-users mailing list
[email protected]
http://pf.itd.nrl.navy.mil/mailman/listinfo/emane-users
