For the case of 20fps video, the testing application generated twenty 14,400 byte parcels at the start each second, again with the first one in the second marked as RELIABLE and each subsequent parcel marked with a two second time-to-obsolescence.
Twenty frames per second was enough of a transmission burden to force XUDP into invoking its timed obsolescence mode. According to table 8.7, out of 581 total parcels, 448 were received and 133 were discarded due to timed obsolescence. The transfer finishes in 32.4 seconds, the length of the transfer plus two seconds for the timed obsolescence window.
|Total Data Acknowledged||6962.400 KBytes|
|Total Transmission Time||32.650 seconds|
|Network Bandwidth Utilization||213.243 KBytes/second|
|Average Round Trip Time||19.5 milliseconds|
|Average Window Size||11.0 packets|
|Total Parcels Received||448 parcels|
|Total Transmission Time||32.351 seconds|
|Total Parcels Skipped||133 parcels|
|Network Bandwidth Utilization (14.4 KBytes/parcel)||199.413 KBytes/second|
|Average Parcel Reception Frequency||13.848 parcels/second|
The 20fps attempted TCP transfer, of course, received all 581 parcels (table 8.8, but at the expense of an extra four seconds on the transmission time yielded in the XUDP test. TCP was able to handle the bandwidth requirement, transmitting at 228KBytes/second.
|Total Parcels Received||581 parcels|
|Total Transmission Time||36.753 seconds|
|Total Parcels Skipped||0 parcels|
|Network Bandwidth Utilization (14.4 KBytes/parcel)||227.639 KBytes/second|
|Average Parcel Reception Frequency||15.808 parcels/second|
Below is figure 8.22, a plot of both the parcel sequence numbers received over time for the 20fps tests conducted on XUDP and TCP. XUDP's timed obsolescence mode performed well, receiving parcels on time. The bottleneck here appears to be XUDP's rather unoptimized architecture; bandwidth requirements approaching 200KBytes/second are pushing the limit of XUDP's resources.