2

This is one extremely basic and probably equally dumb question that I just couldn't ever find a definite answer to.

Suppose we have 2 computers one that can transmit data at say 10 bits per second (A) and another one that can receive data at 2 bits per second (B). This is now all theory, stray from LAN card specs. If A tries to send B some information that's 50 bits long and transmits it at 10 bps over 5 seconds, it would take B 25 seconds to consume it - how does that work? Where does that information live for the 20 seconds after it has been transmitted?

I would imagine that with TCP A will resend the packages until it's gotten an acknowledgement for them all which would degrade A's performance because of having to resend packages all day long (need confirmation on that thought as well) but with UDP or other such protocols the question remains.

2

With directly connected computers, the speed of the NICs must match, either manually set, or through auto-negotiation, or there will be no connection.

If you have an intervening device, e.g. a switch, that allows different speeds on different interface, then frames may be dropped from the faster to the slower computer because the slower link will be oversubscribed.

Whether or not data will be resent depends on the transport protocol (OSI layer-4) used. For example, a connectionless protocol, e.g. UDP, it is up to the application to determine lost datagrams and request they be resent, otherwise they are simply lost, which can be a good thing for some applications, especially real-time applications, e.g. VoIP, where re-sending the lost information can be detrimental (you don't want sounds after they are useful). A connection-oriented protocol, e.g. TCP, will handle the request of lost packets.

Such disparity between NIC speeds will certainly impact performance.

4

With directly connected computers, both need to use the same speed when sending to each other.

Transmitting and receiving with different speeds requires splitting up the data into packets and some kind of packet buffer in between the computers. Such a buffer is part of a network bridge (switches work like bridges) or a router. Repeaters (and hubs) have no buffer and can't change the speed - except for dual-speed hubs that use a bridge and buffer the packets between speeds.

These buffering devices first receive a packet at the speed of the sender. When it's complete, they decide where it should go and forward it to the destination at its speed. In a larger network this can repeat many times over intermediate destinations until the packet reaches its final destination. The way the devices make their forwarding decisions can differ quite a bit and is a major difference between switches and routers.

As the other answers have already pointed out, this hopping and speed-changing can cause a number of problems that the network and the protocols in use need to solve.

3

I would imagine that with TCP A will resend the packages until it's gotten an acknowledgement for them all which would degrade A's performance because of having to resend packages all day long (need confirmation on that thought as well) but with UDP or other such protocols the question remains.

TCP has "the sliding window mechanism that controls the flow of data between devices. This system not only manages the basic data transfer process, it is also used to ensure that data is sent reliably, and also to manage the flow of data between devices to ensure that data is transferred efficiently without either device sending data faster than the other can receive it."

For more info on how the sliding window mechanism works

3

In addition to the completely correct answers about speed matching directly connected systems ...

One of the fundamentals of the internet (including all the private routing portions) is that the indirectly connected fast host A can communicate perfectly well with slow host B, without even any knowledge of the layer 2 mechanisms. The separation of layers means that we don't have to have direct speed compatibility between widely different technical and economic environments such as NASA and a kindergarten, while they still communicate perfectly well, within the limitations.

0

Suppose we have 2 computers one that can transmit data at say 10 bits per second (A) and another one that can receive data at 2 bits per second (B). This is now all theory, stray from LAN card specs. If A tries to send B some information that's 50 bits long and transmits it at 10 bps over 5 seconds, it would take B 25 seconds to consume it - how does that work? Where does that information live for the 20 seconds after it has been transmitted?

Ignoring the fact that your numbers are 6 orders of magnitude off from reality.

If the two computers are directly connected or connected via dumb repeaters then they Must run at the same speed.

To interconnect between different speeds a device that can deal with complete packets/frames must be used, that device must have a buffer that is at the very least able to handle one complete packet/frame but in practice is usually significantly bigger.

I would imagine that with TCP A will resend the packages until it's gotten an acknowledgement for them all which would degrade A's performance because of having to resend packages all day long (need confirmation on that thought as well)

TCP is a bit smarter than that, when it starts a new connection it will send packets relatively slowly. If all of them are delivered successfully it will increase the data rate, if loss is detected it will reduce the data rate.

The result is after sending data for a while TCP will settle at a speeed that uses most of the bandwdith available between the two hosts while keeping packet loss low.

but with UDP or other such protocols the question remains.

With UDP it is up to the application to decide what packets to send when. If the application gets this wrong then packets will be lost.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.