Re: UDP on an SMP system
From: P Gentry (rdgentry1_at_cablelynx.com)
Date: 04/06/04
- Next message: lfree: "Re: dhcp question? anyone?"
- Previous message: hallian: "dhcp question? anyone?"
- In reply to: Johan Hendriks: "Re: UDP on an SMP system"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 5 Apr 2004 23:13:31 -0700
"Johan Hendriks" <j.w.hendriks@wanadoo.nl> wrote in message news:<40710915$0$18462$d5255a0c@news.wanadoo.nl>...
> Thanks for your answer.
>
> I should have mentioned why I asked this question.
>
> We did measurements on the network card (just on the outside, the cable).
> There all packets where in correct sequence.
>
> Then the application would read the packets (using recv) and every few
> minutes some packets would be out of sequence
> (nothing is lost, just the sequence is incorrect) The application uses its
> own sequence numbers inside the packets.
>
> I include one of the reference I found
>
> http://www.uwsg.iu.edu/hypermail/linux/net/0211.2/0038.html
This is what I guessed it would be from your description. We do get
used to UDP being "pretty reliable" and just let the app use the
packet #'s to properly order them ;-)
After reading your reference, I checked some more and confirmed the
nature of the "problem". It's similar to one seen in Firebird (db)
code that tries to use worker threads to satisfy connection requests
-- the separate cpu caches and memory space can be tricky to get
working right. The work-around till a proper fix is to use cpu
affinity to "lock" a process to one cpu.
>From this (whole thread recommended):
http://www.ussg.iu.edu/hypermail/linux/net/0211.2/0039.html
I found this:
[quote]
You can bind interrupts to individual CPU's so that say your device
interrupt ( an eg eth0 IRQ20) will only go to one particular CPU,
which should almost eliminate the reordering windows..
If your device interrupt is your_irq_# you can tie that to cpu_# by
echo cpu_# >> /proc/irq/your_irq_#/smp_affinity
[end quote]
That last line was new to me -- time on this well spent. Though I'll
probably forget it by the time I can use it -- haven't used an smp
machine for a couple of years nearly.
The ref of yours and the link above suggest you may need to check the
status of your nic driver re: smp if you run into problems.
Otherwise, it's pretty much up to the app to code "properly" for smp.
With hyper-threading in the mix now, it's probably an ever moving
target as I've been following the headaches the kernel writers are
having getting it to work reliably and transparently.
hth,
prg
email above disabled
- Next message: lfree: "Re: dhcp question? anyone?"
- Previous message: hallian: "dhcp question? anyone?"
- In reply to: Johan Hendriks: "Re: UDP on an SMP system"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
