Network transmit queue limits

Posted Aug 12, 2011 16:55 UTC (Fri) by dlang (guest, #313)
In reply to: Network transmit queue limits by ajb
Parent article: Network transmit queue limits

time is _much_ harder to estimate and measure than bytes.

if you have a full-duplex connection (i.e. hard-wired ethernet on modern switches), bytes and time have a very close correlation.

if you are on a shared media connection (unfortunantly including all radio based systems), then the correlation is not as close due to the fact that you can't know ahead of time how long it will take to send the data (you have to wait for other systems, retry, etc)

I think bytes is as accurate as you are going to be able to get.

Network transmit queue limits

Posted Aug 12, 2011 17:25 UTC (Fri) by ajb (subscriber, #9694) [Link] (1 responses)

I was thinking of something along the lines of:

void q_add(Q *q,PKT *pkt)
{
   // timestamp packet
   pkt->time=now(); 

   // add packet to end of list
   *q->last=pkt;    
   q->last=&pkt->next;
}

PKT *q_get(Q *q)
{
   PKT *pkt=q->first;
   if((pkt->time+q->max_time) < now())
   {
      free(pkt);
      return 0;
   }
   else
   {
      return pkt;
   }
}

No estimation at all. There are weaknesses in this approach, but it's simpler than adjusting a byte length.

Network transmit queue limits

Posted Aug 13, 2011 7:40 UTC (Sat) by butlerm (subscriber, #13312) [Link]

Getting the time accurate to microseconds can be a rather expensive operation, unfortunately, and that weighs against regulating queue lengths in terms of time when a simple proxy like bytes is available.

Network transmit queue limits

Posted Aug 24, 2011 15:03 UTC (Wed) by wtanksleyjr (subscriber, #74601) [Link] (1 responses)

It seems to me -- ignorance alert! -- that the problem isn't the bytes or the time at all; it's the variance. The purpose of a queue isn't to make a device send faster or slower; it's to cover up variance.

The sources of the variance will have to be considered carefully; variance caused by time delays on the output is probably different from that caused by multiple clients asynchronously loading data into the input.

Network transmit queue limits

Posted Aug 12, 2013 4:42 UTC (Mon) by shentino (guest, #76459) [Link]

The purpose of the device queue is actually to maximize throughput by keeping the interface busy without having to pester the kernel for new packets.

Especially if the kernel is busy with something else and can't immediately handle an interrupt.

And since the queue is being digested by the hardware itself in many cases, the kernel can't just tinker with it willy nilly.