3

I'm trying to setup a network architecture where one network is a low-latency low-bandwidth tcp control system (GBit), the other is a high-bandwidth udp (maybe tcp) network that could get saturated (GBit).

If I have two NICs inside a server running Linux. What happens to the low-bandwidth/low-latency network when the high-bandwidth gets saturated. Does each Ethernet card get the same amount of priority inside the kernel or would the low-latency network suffer from the high-bandwidth being saturated?

  • What exactly are you asking? – quadruplebucky Oct 19 '12 at 15:40
1

You imply that the thing that gets saturated is the CPU since you are basically asking for scheduling priorities in the case that the load gets too high.

This assumption is imho wrong.

What will happen in your scenario depends on a number of things:

  • interrupt-mode of your network cards
  • flow-control of the network equipment
  • usage of offload-engines
  • possible congestion on your PCI-backbone

So what will most propably happen is that the network-card begins to drop packets.

The kernel will allocate computing power fairly - depending on the scheduling algorithm that is in use.

When CPUs were much slower than today and the bus could deliver faster than the CPU could handle it the IRQ with the lowest number was served first.

  • So assuming that CPU is not loaded then a fully maxed out bandwidth on one network card should not affect the latency on the second network card. This only becomes an issue when the CPU is loaded? – Ross W Oct 13 '12 at 0:09
  • @RossW I would say this depends more on the PCIe-bus-structure than on anything else. Is your question about a specific server? Sometimes you can get the bus-specifications from the vendor. The result will be retransmissions because of dropped packets. – Nils Oct 13 '12 at 19:37

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.