 Yesterday, we finished with some examples and an example where we accessed a website and then looked at the details of some of the messages sent when we accessed that website. So we're going to continue from there. Just a reminder, web browsing uses HTTP as an application layer protocol. And the example we saw yesterday saw that the very basics of web browsing is that a client or a web browser creates a request, sends a request across the network, requesting a web page from that server. When the server receives that request, it sends back the contents of that web page. So the formats of those messages are defined by HTTP, but the basic process is quite simple. Send a request for a web page, receive the web page. Once you receive it, you display it on the screen. And yesterday, when I accessed a web page, I used this special software called Wireshark to record all the messages that my computer sent and received. So by doing that, I can look at those messages in detail and see, well, what it actually sent and received? What are these messages? What are their structure? How big they are? And we can do some analysis from that. This was one of those messages yesterday. The selected one, the orange one, was sent by the server. We recall from the IP address yesterday, the server 1061874622, that was the address of the server. It sent a message to my laptop, 10.102.17. So this was the response, in fact. It was a server saying everything is okay, your request was okay. And if we look inside that message, and this software shows us the contents of the message here, in some abbreviated form in some cases. The contents of that message, the data inside it was in fact the web page. Here's the HTML of the web page on the server. And if you remember from yesterday, we saw that displayed on the web browser. So this one message that my laptop received contained that actual web page that I requested. So let's look at a bit more detail of that message. I call it a message, some terminology that will come across. Another common name is a packet. So often we talk about packets being sent. So that may be used a bit more commonly than a message. So this is one packet sent from server to laptop. And the details, the contents of that one packet we can see here. The packet is structured. And the packet contains the data that the server wanted to send me. This, this is the data. Remember we're talking about data communications. Get data from one point to another. What is the data in this case? It's this HTML. But what we'll see is that most protocols, they don't just send the data in a packet. They also attach other information to support the operation of that protocol. So we'll see here that there's the data, but there's a lot of other information. We can see that there are some source and destination addresses. We'll expand and see much more impact. So the packet contains not just data, but extra information. And normally we call that extra information a header. So we have data and we attach some extra information at the front of that, at the head of the data, and we call that a header. In some cases we can attach information to the end of the data and we get a trailer because it's at the end. Let's just browse through what's inside this. This data we were using HTTP. So we have the data here. HTTP actually attaches some extra information for web browsing to work well. Here's the extra information in this one packet. For example, it includes some status code saying everything was okay. So that when my browser receives this packet, it knows that the request was successful. So there's the data plus all these, I'll say header fields, extra information. We don't have to understand the details of these. We see there's a date and time, some identifier of the server, the software running at the server, some type of encoding of the, some type of content. So what is the data? Is it HTML? Is it a JPEG? Is it a video? Well this field in the header, this one content type tells us what, what is the content of the data or what is the type of the data. And there are other things that are specific to HTTP. My point is that these are included in the packet and they are needed by HTTP to work correctly. And if we try and draw that, what do we draw? So let's try and draw this one packet and keep track of some aspects of that packet. And I'll try and draw it on the screen. Let's see how we go. What have we got? We've got our, let's draw a box first. We have some data and we're going to see we'll have some headers. We'll draw them one at a time. It's now straight. So we have some data that comes from the user. This is the web page, in fact, coming from the server in this specific packet. In other packets it may be different types of data. But then we also attach to that data a, in this case a HTTP header. So I'll denote that. I'm going to draw the entire packet and see the structure of that. You can draw it as well. How big is the data? While we're going, let's try and keep track of the size of these. Well, this Wireshark software actually tells us, it gives us a nice summary of the data. So if I just close that. How big was the HTML file? We could check, I could check on the server and see how large the file was. But it tells me here, if I select here, it tells me it's hard to see 105 bytes. So the HTML, the data that we're trying to get from server to laptop is 105 bytes. How big is the HTTP header? All these extra fields that HTTP adds, 441 bytes. So if we looked at all these fields and recorded the size of them, if we add them all up, there's 441 bytes there. So that's the size of the header for HTTP. Let's write them down so I can remember. What do we have? We have 105 bytes of user data. That's the original data we want to get there. And what we have, 441 for HTTP. But then we take this HTTP header plus data. We do not send it immediately from the server across the internet. We actually use another protocol to send this. HTTP is at the application layer. We use the lower layer protocol to send this across the network. In fact, we use TCP in this case. We'll see it in the capture. So the next header is TCP, transmission control protocol. We see this software presents layers but upside down. So application layer, transport and so on. It shows what exact protocols were used in this one packet. In different packets, they'll be different. But in this one that we've selected, it's HTTP using TCP and then which uses IP, the internet protocol, which uses Ethernet. It only goes to the data link layer. It doesn't go any lower in this software. TCP, if we expand that, has a set of fields. Again, we don't need to know what they are at this stage. Just the fact that inside the TCP packet, there's a header which contains all this information. Sequence numbers, support numbers, some size of things, check sums. Total size of TCP is 32 bytes of TCP header. We look at the IP header. Again, it includes a version number, the version of the internet protocol we're using, IP version 4. Source and destination address. It includes the IP address of the server and the IP address of the laptop, the receiver, and some other stuff, 20 bytes. And Ethernet, the last one we have is 14 bytes. So let's record them and see what we end up with. What have we got? Three more in this case. This is just what our software shows us. In fact, there may be even a physical layer header, but we cannot see that because that's related to the hardware that our software cannot see the details of the signals being sent. So we're a bit limited, but we get enough. So we had TCP next, IP, and then Ethernet, which is ETH. And the sizes I can remember, 32, 20, and 14 bytes. They're in bytes. So this is the one packet that my... the server center packet and my laptop received it. This is our entire packet. Or at least most of it. There may be some extra things here that our software can't see, but let's say this is our entire packet. Data. The real data that we want to get from server to laptop is 105 bytes, a 105-byte file. But we have to attach some extra information. HTTP attaches 441 bytes of extra info. TCP, 32 bytes, IP, 20, Ethernet, 14 bytes. And the packet, what's the total size? Anyone? Anyone can add up five numbers. If you can't, we'll give you a... This software, again, tells us the total size is 604 bytes. Okay? Does that add up? Can someone check? Is it 604 in total? Feel free to use a laptop, a mobile phone, a calculator to add up. Add the five numbers and see if you get 604. No? In fact, you don't. This is a very special case. It's a little bit confusing. I'll write down the numbers in a moment. What do we get? The total size reported was 604. So... But if you add these numbers up, what do we get? 546, 612, something like that. So if you add those numbers, you get 612. But the software tells me there's 604. What went wrong? Where did I miss something? There's something special happening, which is not always the case, but let's explain. The web page I said was 105 bytes. So the server has a 105 byte file that it wants to send to me. Of HTML. What the web server did before it sent that file is it compressed the file. Gzip is a compression algorithm, so it takes the 105 byte file, the real file, compresses it, zip, and it ends up with 97 bytes. So what is sent across the network for that file, even though it contains 105 bytes of data, only 97 bytes need to be sent. It's compressed, so it shrunk a little bit. Not much, but because it's only a small file. That's where those numbers don't add up. So in fact, we have 105 bytes of real data, but what is actually sent in the packet is just 97 bytes. I'll note that there. So if you add up now these five numbers, you'll get 604. Why do we care about all this? Well, different reasons. First, this is showing a little bit about how we use multiple protocols to send data. We take our original data, the application layer protocol does some processing on that, for example, compresses it, attaches some header information, so we get this, and then delivers that to the transport layer protocol, TCP. TCP does some processing, attaches a header, delivers all that to IP. Does some processing to Ethernet. Once we have this 604 bytes, my LAN card, in fact, if I was sending it, in fact, I was receiving this one, but my LAN card would now create... So we have 604 bytes. We have a sequence of bits. It would create some signal to represent those bytes and transmit them across the link. So this is what would be transmitted by one of the devices in the network. We'll come back to the numbers in a moment. So that diagram is a common type of diagram we'll see in this course showing one packet, but showing what is the contents of this packet? Well, some data plus some headers from different protocols. This diagram shows it from a different perspective. We start with some data, some user data say the web page. We... So here are the layers. Application, transport, network, data link, physical. All inside a computer. So this all happens inside, say, the sending computer. Take the data, HTTP attaches a header, gives that to TCP, does some processing, attaches a header, gives that to IP, does some processing, attaches a header, gives all of that to the data link layer, Ethernet in this case, the LAN card. Ethernet sometimes attaches both a header and a trailer at something at the end. In our example we don't see that. And then the physical layer treats all of this as just a sequence of bits, zeros and ones, and generates some signal to send across the link. For example, some electrical signal that is sent across the copper wire inside the LAN cable. How does it do that? Well, we've got several topics on how to convert bits into signals. We're just showing the structure and the flow of data through the layers. The signal is sent across the link, and then the next computer receives it and does some processing and then may send it on until eventually all of this is received by the destination. And the destination does the opposite, go in the upwards direction. It takes this, removes the header and trailer, passes this to IP, removes the header, passes this to TCP, removes the header, HTTP, eventually HTTP in your web browser takes the data and we've received the data that displays it on the screen of the web browser. This process is called encapsulation. We encapsulate one piece of data into a larger packet, and then we encapsulate that packet into a larger packet and so on. That's how many protocols use this same approach that we attach headers to carry some information so that that protocol will work correctly. So returning to our numbers here, in that one packet when I received a web page, the web page in fact was 105 bytes. That was the size of the web page. That's the user data. From the user's perspective, that's what they want to receive. Remember data communications getting data from one point to another. The amount of data in this example was 105 bytes. But to get that 105 bytes across the network, at least to my laptop, how much had to be sent? 604 bytes. Because there's all this extra headers, together we call them overheads. So we can distinguish and say, there's 105 bytes of real or user data, but to deliver that from A to B, we need to send 604 bytes in total. And from that we can start to analyse how well does this perform. To deliver 105 bytes of real data, I send 604 bytes in total. How efficient is this? If we look at this packet, well, what fraction of the total amount of data sent is real data. Calculate. Anyone have a rough number? What fraction or what percentage of the total data is the real data? You can write it here. We have 105 bytes. It's all in bytes. I haven't included the units. A real data. That is the information we want to get from A to B. But actually we need to send 604 bytes in total. So we can say in this specific example, the efficiency of sending this data through the link or through the network is 105 divided by 604. Which is what? You can calculate about 17%. 16. 16%. So simply 105 divided by 604 as a fraction is about 0.17. As a percentage is 17%. So this is one measure of our performance of a communication system. We see that when we have data the protocols introduce extra headers. In total we call them overhead. Some extra overhead. And that decreases our efficiency. The more overhead the less efficient we are in sending that real data. So in that case, what do we get? 17% efficient. Not so good in that if I have a single link and one way we can interpret that is saying that 17% of the time I'm sending real data, useful data the other 83% of the time I'm just sending headers and overhead. So 17% of the time I'm using the link to deliver the actual data. The rest of the time is other things are happening. How could I increase the efficiency? How could I make that go up in this specific case? By sending more data if you do the calculation, we'll do it in a moment where do these numbers come from? The data is what we want to send. In this case it was a web page. What about the size of the headers? Where do they come from? They are defined by the individual protocols. Normally they are fixed or approximately the same. That is TCP is always around 20 to 30 bytes plus or minus a few bytes. So it's normally 20 to 30 bytes. So if I looked at many other packets I would see TCP headers about 20 or 30 bytes. IP normally around 20 bytes. Ethernet normally 14 bytes. HTTP varies a bit and in fact is much larger but hundreds of bytes. Here we have 400 close to 500 bytes in some cases. What about the data? Well that depends upon what the user wants to send. But in this case if we increased the data what if the data was not 105 bytes but the data was 1000 bytes. But everything else was fixed. The headers was the same size. How efficient would we be? Calculate it. Roughly approximately. If we increased just the data from 105 up to 1000 then all the headers stay the same size try and calculate the efficiency. You can be approximate. That is 105 up to 1000 is an increase of about 900. 66% Good. Who else can come up with that? What do we have? In the first case on the board we had an efficiency. What do we get? In the first case 105 over 604 as a percentage is about 17%. What if we change the data? Everything else is fixed. If we increase the data up to about 1000 I say about it doesn't matter the exact value. Then what's the total size? If we increase the data up to 1000 what's the total size? About about 1,500. Because from 100 up to 1000 is an increase of 900 therefore the total size increases by 900 from 600 about to 1,500. We don't need to be too accurate here. So efficiency then is the total size would be about 1,500 which is 67% efficient. That's a general rule that we'll see that when we send a packet normally the headers are fixed. We cannot control them as a user. The protocols define the size of the headers. The user cannot control them. To be more efficient send larger amounts of data at a time. By sending more data the efficiency goes up because the percentage of the headers from the total. So the top one is when we had 105 bytes what if we changed it, that's the second case. Questions? Any questions at the moment? The mathematics is easy but the concept sometimes is difficult of all these headers and the packet structure. What does the header do exactly? What does the header do? It's a good question. We haven't really said that. What does the header do? If we go back to one slide we skipped over early on, I can't remember the slide number but this common features of protocols. Most protocols they add headers so the data to carry control information. What is control information? Information to control the protocol for the protocol to work correctly. Well it depends upon the protocol what information is needed. But some examples you may recognise often the headers will contain addresses source destination address. I send a packet from this computer out onto the internet. Inside that packet inside the IP header I will include the address of my computer, the source and the IP address of the destination computer. Other devices in the internet know where to deliver this packet so addresses may be included in the header. Sometimes we have sequence numbers. I want to download a large file. Instead of sending in one packet, one big packet, I break it into many smaller packets. I send the first packet, I send the second packet, the third and so on, one after another. So inside the header let's include a number in there, a sequence number of this data saying this packet contains the first piece of data, this packet contains the second and so on. So we keep track of the ordering of the data. So sequence numbers and another thing, error detection code. Maybe you've seen error detection in computer architectures or computer hardware somewhere where you've heard of parity checks and we'll cover it later that you send some data across the destination. The destination uses this error detection code, this extra information to check are there any errors in the data? Are there any problems with the data? So the receiver can detect any errors. And other things. So this is just a few examples. We saw HTTP includes a time and a date in the header. It includes some string to identify the server and other information. When we look at specific protocols we'll see more detailed examples of what's included in the headers. For now, the main point, most protocols attach a header with some information needed for that protocol. That introduces an overhead. But we can't avoid it, it's needed for the protocol. Ignore the protocol data unit, that terminology we will not use. I'll just call it a packet. Segmentation and in fact a game we will cover later if needed. Not so important at this stage. Where do we get to? Almost got to here. Any other questions before we move on? In the quiz that starts at 12 o'clock today you can answer questions, calculate the performance. We'll see. In fact from memory this quiz too, which is available today at midday, does not include questions about performance. Quiz 3 does. You'll have some time to practice. So where are we? We've moved now into looking at some aspects of performance. This is some measure of performance of our network and of our protocols. One thing we care about is efficiency. We'll see that come up again. Let's step back before we go into other performance metrics. Let's first describe generally what we mean by internet applications. And then we'll talk more about how do we measure the performance of those applications and of the networks. What are internet applications? Well, what's not an internet application? The example Microsoft Office. You install Office on your computer to write documents, spreadsheets and so on. That's what I call a standalone application. For Office to work, you don't need a network connection. You just use your computer. You don't need the internet. It just runs on your computer. It's a standalone application. It has some user interface, so you can click on things, enter data and has sort of the back end, the application logic, the code that does all the things like saving files, converting fonts and all those things that Office does. So there are standalone applications. They don't have a network. Well, then there are applications that really only work if we communicate across a network called generally network or distributed applications. They are applications that, yeah, you install on your computer, but for it to be useful it must talk to an application on another computer. Web browsing is the example. If I install Firefox on my computer, a web browser and have no network connections, it's not much used to me. A web browser without internet access, what can you do? Look at files on your computer, but not very useful. What a web browser does is it communicates with a web server. For this application of web browsing to work it's one web browser talking across the network to some other piece of software, a web server. That's a network or a distributed application. I think you know plenty of examples, email, instant messaging, games, many different applications, Skype and so on. Of course there's still a user interface, there's still some logic to do the things like save files and parse all the content, but importantly network applications include also some communication mechanisms, some ability to send a message from my web browser to the web server and to receive a response. Some protocols. We're focusing of course on network or more specifically internet applications. And we can break them into two different types. I'll call the traditional internet-based applications, things that we use on a regular basis, in fact we use them all probably, file transfer, email clients, web browsing, remote login, connect to other computers, database applications and we'll distinguish or we can distinguish between these type of applications which are about transferring data from one computer to another. Email, think of just we need to get data from one computer to another. Web browsing, get a web page from one computer to another. File transfer. So it's about transferring data where that data needs to be delivered accurately. Accuracy is the most important. And I've said this in one of our first lectures that we need to make sure that the email at the server or the source and the email at the destination that I receive, they must be the same identical, 100% accurate. But another group of applications multi-media or real-time applications streaming music over the internet or videos. Skype voice calls or some application for video calls across the internet where there's two people talking to each other, live in real-time. Gaming where you're playing a game and it's a multiplayer game and what happens is it sends some data to a game server and everyone else is also playing the same game so you can see them on your screen. So there's some communications between the applications for that game to work. If you don't have internet connection for this game, then you cannot play against other people. Collaborations like sharing your desktop with someone. You can view someone else's desktop. That's an example of a collaboration software. These type of applications still internet applications but usually have different requirements in terms of performance. Timeliness is more important. That means that from when we send some data until when it's received the time it takes should be small. For these applications to work well we care more about a short delay a small time to communicate whereas these traditional applications we care more about making sure the data gets there 100% accurately. Email, if it takes a day to get there it's still okay. It's not so good but a day or one hour to get an email from source to destination we can survive. Anyone play online games? Anyone play a game? A networked game? How would you measure the performance I know some of you have for sure. How would you measure the performance? Ping. If anyone's played an online game there's this thing you see with a game or a metric called the ping. What does it measure? Ping. What's the units? The time. The time for some response. With online games what you do is you have it on your computer when you do things you move your character around it sends data to the some server and then everyone else's computer is accessing that server and some of that data is sent to their computer when I'm walking around some environment and some other player is in the same room I will see their character, their avatar or whatever. How do I see that? Because their game is sending data to the server and the server is sending that to me. Now, for this to be to work well when I move when someone else moves on their computer I want to see that almost instantaneously happen on my computer so the delay from when their computer to send to the server and the server to send to me is very important. It needs to be small and that's what the ping measures. The ping time measures the time to get a message from my computer to the server and usually back. What's a good ping time? 10 seconds? Milliseconds. Milliseconds because it provides the interactivity in the game that if it's in the order of milliseconds when someone else moves on their computer a few milliseconds later maybe 10 milliseconds I see their character move on my computer. If it took a minute we couldn't play the game. So an example gaming requires a very small delay between sending messages. The timeliness is important. A short time between sending and receiving messages. Some of these applications don't require 100% accuracy. Voice and video calls even if you're streaming video from a server to your computer if not all of that video is received what will happen on your computer you may see some pixels not displayed correctly for a fraction of a second. But you don't care you can still watch the video so 100% accuracy is not always required for these applications. So different requirements in terms of performance depending upon the application. What we want to do to finish today, the remainder of the lecture is to look more about how do we measure the performance. That is now let's look at a communications link a cable between laptop and laptop. I connect them together I want to send data. There's a video whatever I want to send data how do we measure the performance of this link how do we know if it's good in terms of performance. We're going to list I think 5 different ways to measure the performance which are common called performance metrics ways to measure the performance. In fact we'll go through in this topic 3 of them in detail the first one bandwidth we'll go through in detail in the next topic so there are 5 there are others as well I've selected 5 main ones bandwidth, data rate throughput delay and maybe not so important packet delay variation which is just the variation of the delay between packets we will not cover this one in fact so in this topic we'll mention bandwidth now then look at data rate and throughput and maybe next week delay is like the ping time the time it takes briefly bandwidth when we have a communications link either a cable connecting to computers or maybe a wireless link from my laptop to the wireless access point at the physical layer we take our data, our bits and we send some signal some electrical signal some looks like a sine wave or combination of sine waves and that signal has some frequency in fact usually contains a set of frequencies so the signal if you think of a sine wave the frequency of a sine wave the signal that we send is usually made up of a range of frequencies the bandwidth of a signal is the range of frequencies that are transmitted or that can pass through some communications link channel is just another word at least at this level for a link slightly different meaning we'll see later the bandwidth is the range of frequencies that can pass through a channel through a link or a transmitted by a system it's one important way to measure the physical layer signal sort of thing we're not trying to describe it anymore yet because in the next topic we'll spend one or two hours explaining bandwidth and some other factors but we'll come back to it it's an important measure one example is you listen to radio in your car AM or FM radio how does it work? with AM radio there's some radio station that has a tower nearby and they transmit a signal some radio signal and it's received by the antenna on your car well that signal that's transmitted is in fact transmitted across a range of frequencies centered about one frequency for example or maybe FM because you'll know that better FM what's an FM radio channel I don't know many tell me the name of a FM radio channel here in Thailand okay and now tell me the channel what do you tune it into what number hmm 93 93. something 93.0 watt what units 93.0 megahertz an example megahertz that's referring to in fact one of the frequencies that are transmitted when you're listening to that specific channel in fact when you're listening to that specific channel the tower is transmitting this and the range of frequencies is the bandwidth as usually I think in the order of 10 to 20 kilohertz that is the frequency is not exactly 93.0 it's a little bit less than a little bit more so it ranges from what 92.9 9 to 93.01 with the minimum and the maximum the width between them is about 20 kilohertz 20,000 hertz this is the bandwidth of the signal don't worry too much about this we'll come back to this in the next topic and just define bandwidth do some calculations like this and look at some more examples but it is one important measure of communication systems generally the the larger the bandwidth the better and we'll say how shortly but one thing probably you recognize more use and see more is data rate the number of bits a channel a communications link a network can transmit and the rate at which we can transmit so measured in bits per second so I have a cable connecting and I connect my two laptops together I've got the blue laptop has a LAN cable and it's a LAN socket there a LAN card and I plug it into my grey laptop I have a link between the two so a communications channel is another name for this how fast can I send data from one to another well that would be the data rate the maximum speed at which I can send data would be defined by the data rate and it's usually dependent upon the technology that we use let's check the data rate we can actually see it in a moment so I've connected direct using the wired cable the other the general name for this technology is Ethernet so I have a LAN card in this computer and in this computer and plug them connect together they've been I've set this one up in the past they're set up to connect I hope I think from yesterday or a previous lecture we said sorry the program I have configured on my computer can show me some details about my interface my Ethernet interface eth0 my wired LAN interface has an IP address 192.1683.2 my other one is set up you cannot see it there's 192.1683.1 I chose that myself and some statistics about this interface how fast can I send data from one to the other anyone know you want to guess what's the data rate for my link doesn't say up there don't worry doesn't say 1000 megabits per second 100 megabits per second so two guesses there and both are valid guesses 1000 megabits per second 100 megabits per second why did they guess them because they are typical data rates for wired LAN technologies it depends in fact upon the LAN card my gray laptop supports three speeds 10 megabits per second 100 megabits megabits per second and 1000 megabits per second my blue-tap laptop cheaper and older it supports just two speeds 10 and 100 megabits per second let's check there's another tool that will show me the ETH tool shows me my ethernet information I need a password to look at it a lot of information there but the main one speed that's the current speed that my link is using 100 megabits per second how does it work in practice this laptop supports 10, 100, 1000 this supports 10 and 100 it's a bit older when I plug the cable in the protocols at the data link layer go to work and they negotiate and determine what's the maximum that we can support for both endpoints 10, 100, 1000, 10, 100 the maximum is 100 and it supports 1000 megabits per second so they default to 100 megabits per second that's the data rate of my link will show you the data rate of Wi-Fi a little bit later as well so it depends upon the technology the capabilities of the device and the link the cabling on this blue laptop I have a web server and I've got a file on that web server which is I've got a I have to remember I have a 50 megabyte file on this web server 50 megabytes so my let's record what we have my data rate currently 100 megabits per second 100 million bits per second I've got a file which is 50 megabytes how long is it going to take to download to transfer from the blue laptop to the grey one I'll download it in a moment but how long do you expect it will take 16 seconds not quite I don't think anyone else 4 seconds sounds good file is 50 megabytes be careful the speed here is using lowercase b in terms of megabits per second the file is reported in megabytes 1 byte contains 8 bits so the file size is 400 megabits lowercase b 50 times 8 the file is 400 megabits if the data rate is 100 megabits per second it means I can transfer 100 million bits every second I have 400 million bits so the time to transfer should take 4 seconds a rough calculation let's transfer and see I have a file on the web server there I'm going to use a command line based web browser here I don't want to view the file I just want to download it and record how long it takes the program I use is called Wget you don't have to know that and I type in the URL which contains the request of the blue laptop and the directory I've created ITS 323 and the file it's a 50 megabyte file doesn't contain anything of value I've just called it meg50.bin it's a binary file when I press enter my grey laptop sends a request for the file and then the file is hopefully downloaded to the grey laptop and this software will report how long it takes the speed on average ready? there it goes gives us some statistics so it's downloaded 4.3 seconds a bit longer than we expected a little bit, not much and it also reports the average speed 11.2 megabytes per second how many megabits per second when I transfer the file how many megabits per second was I transferring that file at you want to have a calculator a tablet a phone and times 11.2 by 8 try so let's record what we've got so we remember we had a data rate the data rate of our link was 100 megabits per second we had our file size of 400 megabits we expected it to take 4 seconds it took 4.3 seconds it was 400 megabits the actual time it took as reported by this software was 4.3 seconds let's use that 400 megabits were transferred in 4.3 seconds and in fact reported what rate that is 400 megabits divided by 1.3 seconds is 11.2 megabytes per second to convert the bits multiply that by 8 and you get what 89.6 megabits per second let's record that so this one is what I'm looking at really the actual speed was 89.6 megabits per second the name of this so the data rate was 100 megabits per second we have another performance metric throughput and in this example it was 89.6 megabits per second hope you can read my writing so now we've got a new metric the data rate is one metric that's the maximum speed at which we can send bits across the link 100 megabits per second the throughput is the actual speed at which we deliver the data across that link and we measured it to be 89.6 megabits per second slightly less than the maximum why is it less well one reason is because of all these overheads of the packet headers the throughput measures the speed at which the real data is delivered but we have the real data but we also have HTTP header TCP headers, IP headers on which introduced some overhead and in this specific case they introduced an overhead and the result was the rate at which the real data was delivered was 89.6 megabits per second the real data being the 50 megabyte file sometimes we can calculate the throughput sometimes it's too complex and we just measured it as in this case so I just measured the throughput and it's the same as 400 megabits divided by 4.3 seconds in this case is 89.6 megabits per second throughput amount of data successfully delivered to destination so we have two different metrics now data rate, number of bits we can send throughput, the amount of real data we can deliver throughput will always be less than or equal to the data rate as less than the data rate think of the data rate as the maximum we can achieve if we consider the overheads we end up with some throughput what's my efficiency in this case how efficient am I using the link how efficient are we in this case my link supports 100 megabits per second I'm only getting 89.6 megabits per second we would say the efficiency is as a percentage of the maximum of 100 we get 89.6 so the efficiency is simply 89.6% in this case simply throughput divided by the data rate it's easy in this case 89.6% of the data rate we use for delivering real data the other 10.4% is used for doing other things like the packet headers and maybe even some other overheads so from the user's perspective this is the most important one the throughput because I'm the user I want to download the file I care how fast I can download that file so I want a high throughput it's going to be limited by the data rate but other factors impact on the throughput like the packets the packet headers the protocols used and how those protocols work so data rate is normally a feature or a characteristic of the technology my wired LAN supports 100 megabits per second my wireless LAN will see may support 54 megabits per second whereas throughput depends upon the protocols being used and what the user is doing throughput may vary if I download another file it may be slightly different than 89.6 megabits per second if I use different protocols instead of HTTP this could be different but the data rate is the same let's give another example any questions on the calculations here this was measured in fact I measured this the software measured it for me the efficiency calculation in this case is simply throughput divided by data rate you can convert to a percent before we show another example any questions I don't have my phone with me so you can't send me questions online or twitter but you can ask me I'm here let's do it again but using my wifi instead of wireless LAN unplug my LAN cable I don't need that I'm going to turn my wifi back on and luckily in the previous section I downloaded a file on the ICT server so now my laptop is connected via wireless LAN to this access point and then via some network to the rest of SIT I'm going to download a different file on the ICT server I did it before this one it's a long URL it's just one of our lecture notes a PDF file on the ICT server the file is about 3 megabytes in length how long is it going to take downloading, downloading what do we get the file size about 3 megabytes the average speed 1.3 megabytes per second multiplied by 8 which is 8 is 10.4 about 10 megabits per second so now I'm using wifi wireless LAN I got a download of a file and the throughput here the speed at which the real data was transferred was about 10 megabits per second much slower than wired LAN which is about 90 megabits per second throughput 10.4 megabits per second what's the data rate anyone want to guess educated guess what do you think my data rate is for my laptop to the access point 100 megabits per second let's check again I can check on my computer my wireless configuration is a program called IW config don't worry about the details the data rate or bit rate in this software 54 megabits per second my connection wirelessly from laptop to the access point allowed a data rate of 54 megabits per second a wired LAN supported 100 megabits per second before the throughput I got in this case was 1.3 megabytes per second or about 10 megabits per second I can just quickly write them up here just to compare with our wired LAN or Ethernet I had a data rate of 100 megabits per second that was the maximum speed I achieved a throughput of what did I get 89.6 I think megabits per second and that gives with our wired LAN an efficiency 89.6 divided by 100 expressed as a percentage 89.6% with my wireless LAN also called Wi-Fi data rate 54 megabits per second measured the throughput as 1.3 or 10.4 10.4 megabits per second efficiency 10 divided by 54 which is about what one fifth a little bit less around 20% so just comparing two different technologies they have different data rates and importantly different levels of efficiency even if I could double my data rate of the wireless LAN even if it went up to 108 megabits per second and if you have a good access point you can do that easily so if this was doubled if we had the same efficiency if this was 108 this would still be only about 20 megabits per second much less than wired LAN so we say normally wireless LAN is much less efficient than wired LAN because wireless LAN there's different reasons one can be the protocol headers but in wireless LAN there's many other factors of other people transmitting an interference that reduce the efficiency so when we compare technologies when you choose a technology for your company for your home if you're choosing between them well you can compare on data rate but to be more accurate compare also on throughput or efficiency because efficiency and throughput are proportional so preferably you want the highest throughput so when you go on biotechnology which one do you choose the one with the highest throughput but the problem is that it's hard to determine what the throughput will be in advance so it may vary in some cases I may get 20%, sometimes 55%, sometimes 50% so the throughput varies in different conditions the data rate is usually fixed we care about throughput but the problem in reality is determining the throughput before you build the network is very hard so often we have to just select based upon data rate but preferably we know about efficiency and throughput so two metrics which are very important selecting technologies building networks data rate and throughput questions on that comparison or how to calculate efficiency or what is throughput okay the next performance metric we have to look at is delay we said with gaming the ping time is important the time it takes to get a message from one location to another we're going to look at that next week okay we're going to stop there because it needs a lot of time to go through some examples an explanation of delay so we'll stop there and next week we'll finish on delay maybe a few more examples on some calculations and then we'll move on to the next topic is how to send data as signals in a communications link