I have a built-in application that has this requirement: one outgoing TCP network stream should have the absolute highest priority compared to any other outgoing network traffic. If there are any packets awaiting transmission to this stream, these should be the next packets sent. Period.
My measure of success is this: measure high priority latency when there is no background traffic. Add background traffic and measure again. The delay difference should be the time it takes to send one packet with a low priority. With a link of 100 Mbps, mtu = 1500, this is approximately 150 us. My test system has two Linux drawers connected by a cross cable.
I tried many, many things, and although I significantly improved latency, I didn’t reach the goal (currently I see 5 ms of added delay with background traffic). I already asked another, very specific question, but I thought that I should start with a general question.
First question: is this possible with Linux? Second question: If so, what should I do?
- dts?
- Which qdisc should I use?
- Change kernel network settings? Which of them?
- What other things am I missing?
Thank you for your help!
Eric
Update 10/4/2010: I installed tcpdump on both the transmit side and the receive side. Here is what I see on the transfer side (where things seem to be overloaded):
0 us Send SCP (low priority) packet, length 25208
200 us Send High priority packet, length 512
On the receiving side, I see:
~ 100 us Receive SCP packet, length 548
170 us Receive SCP packet, length 548
180 us Send SCP ack
240 us Receive SCP packet, length 548
... (Repeated a bunch of times)
2515 us Receive high priority packet, length 512
SCP (25208 ). mtu ( 600). , , , , tcp, mtu! Arghhh..
- TCP Linux?