File talk:How to build an Ethernet Frame.webm

improvements

3 rd revision

• rerecord audio!
• 2:45 2 Bit --> 2 Byte
• if I talk about mac adresses and say something about the first 3 byte and next 3 byte one could mark the respective part of a MAC adress

on the final audio version:

• deviding by 64 must be gone. the sync is done differently and the 64 bits are only introduced due to too many repeaters
• checksum leave some more words: in general most bits are corrupted or nothing. so error correcting is not so important. checksum will evaluate to one
• don't open the encryption topic here otherwise I would have to open many more topics...

• 3:46 other visual for corrupted data instead of color --Rob-nowman (talk) 12:18, 14 February 2014 (UTC)

2nd revision

• 0:50 Preamble 64 bits -> 31 pairs of "1" and "0" and two following "1". right? should this be explained?

think this is right and should not be explained any further --Renepick (talk) 14:19, 27 September 2013 (UTC)

• 1:15 should the clocks count on or stand still?

I don't understand this entire visaulization of clock + 1,00 thing here anyway... what is being counted? Why don't we send 64 bits from the left computer and let computer B measure how many clock cycles are being spend so that it now for the next data to receive knows how long much time is to be used for one bit of data. --Renepick (talk) 14:19, 27 September 2013 (UTC)

• 2:40 2 bit should be two bytes --Renepick (talk) 14:19, 27 September 2013 (UTC)
• 3:00 Input needed for bullet points and maybe animation or graphics concerning the "datafield"

here we stay with the ethertype a little longer maybe up to 3:40. for the data itself we can have some example data but there goes the data that I actually want to transfere. --Renepick (talk) 14:19, 27 September 2013 (UTC)

• 4:10 checksum needs some bulletpoints... from what I say.
• 4:40 - 5:20 this is important and we should some how visualize this. May be like in the first videos of a computer sending data and another one just realizing the data is corrupt but not doing something about this e.g. requesting the data again.
• 5:30 text coming in should later by synced to what I say. I know I will record everything again but we should not show all the text at once and then talk through it. also the one that I am currently dicusing could be largely displayed in the main window and then fly to the box on the right.
• 6:03 cannot is kind of harsh. it is already set up to be able to do these kind of things but it needs the algorithm from the 4th video
• Endslide not updated

First revision

• 1:05 32 10s followed by 11 could be displayed in the free space
• 1:15 transfering 1 bit. Again I would say transfering 1 bit might be encoded by giving a signal on the wire which envolves over the wire until i stop for one clock cycle... I would now continuously display the clock show how ones and zeros emit from the computer
• 1:40 the calculation should be written out?
• 1:50 MAC = Media access control (should be displayed somehow)
• 2:40 ethertyp same as 1:40 all that I say here is not visualized at all. especially the 0x0600 could be visualized and the calculation that 0600 is 1524 could be shown. there could also be a link to the ethertyp wiki article that explains which protocol versions of ethertyp exist (if the field is higher than 0600)
• 4:00 CRC checksum. we could display some of the properties even just listing them might be enough.
• 5:31 summary: at least powerpoint like bullet points
• endslide is missing

Factual errors

1. The preamble is not part of the frame – it belongs to the physical layer and is part of the Ethernet packet.
2. It's not the frame size that's 46–1500 bytes; this is the payload size.
3. Since the FCS is complemented, the result of checking it on reception including the FCS should be the 'magic residue' 0xC704DD7B.
4. The FCS can only detect errors, not correct them. — Preceding unsigned comment added by Zac67 (talk • contribs) 20:49, 19 April 2017 (UTC)
5. When the EtherType field indicates the length, it's not the length of the complete frame but the "the number of MAC client data octets contained in the subsequent MAC Client Data field" ie. its SDU or the L3 PDU length. The maximum value is 0x05DC. — Preceding unsigned comment added by Zac67 (talk • contribs) 06:29, 20 April 2017 (UTC)

--Zac67 (talk) 20:49, 19 April 2017 (UTC)