From: Chris Friesen <cfriesen@nortelnetworks.com>
To: jamal <hadi@cyberus.ca>
Cc: Ben Greear <greearb@candelatech.com>,
kuznet@ms2.inr.ac.ru, netdev@oss.sgi.com
Subject: Re: PATCH Re: udp weirdness
Date: Tue, 01 Oct 2002 15:03:25 -0400 [thread overview]
Message-ID: <3D99F17D.10802@nortelnetworks.com> (raw)
In-Reply-To: Pine.GSO.4.30.0210011433300.18461-100000@shell.cyberus.ca
jamal wrote:
>
> On Tue, 1 Oct 2002, Chris Friesen wrote:
>
>> to be silently dropped by the kernel because userspace is sending
>> faster than they can get onto the wire during that tight loop.
> So what happens when you find packets being dropped? AFAIK, a
> dropped voice packet is as good as dead whether local or remote.
We do have some leeway in terms of latency, and delayed leaving the box
is not the same as dropped.
We know that call processing messaging can only ever go out one ethernet
interface at a time, and we know that the call agent is guaranteed 90%
of the userspace cpu time (scheduler changes). We certify the box for a
certain engineered throughput, so we know the average packets/sec value.
We also have total knowledge/control over the other apps running on the
box in question.
So really all I'm protecting against is from one single userspace app
generating packets faster than the network can keep up. As long as I
get EAGAIN/EWOULDBLOCK/ENOBUFS on my non-blocking socket then I'll just
try again until it succeeds or I get a more serious error. So far this
seems to be working nicely in 2.2, but we're just in the middle of a
switch to 2.4 for the new release and I want to make sure I've got a
handle on things.
Thanks for your help,
Chris
PS. I realize that this design is simplistic, but we are severely
constrained by the legacy app running on the emulator.
next prev parent reply other threads:[~2002-10-01 19:03 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-24 6:50 udp weirdness Eric Lemoine
2002-09-27 12:02 ` Eric Lemoine
2002-09-27 14:53 ` jamal
2002-09-27 15:04 ` Matti Aarnio
2002-09-29 14:47 ` jamal
2002-09-30 8:49 ` Eric Lemoine
2002-09-30 11:09 ` jamal
2002-09-30 12:10 ` jamal
2002-09-30 12:23 ` jamal
2002-10-01 0:22 ` PATCH " jamal
2002-10-01 6:35 ` Eric Lemoine
2002-10-01 9:51 ` jamal
2002-10-01 13:53 ` kuznet
2002-10-01 14:14 ` jamal
2002-10-01 14:26 ` Chris Friesen
2002-10-01 14:40 ` kuznet
2002-10-01 14:52 ` Chris Friesen
2002-10-01 15:31 ` kuznet
2002-10-01 16:16 ` Chris Friesen
2002-10-01 16:41 ` kuznet
2002-10-01 17:17 ` Chris Friesen
2002-10-01 16:42 ` Ben Greear
2002-10-01 16:58 ` Chris Friesen
2002-10-01 17:55 ` jamal
2002-10-01 18:36 ` Chris Friesen
2002-10-01 18:35 ` jamal
2002-10-01 18:54 ` Ben Greear
2002-10-01 19:03 ` Chris Friesen [this message]
2002-10-01 18:52 ` Ben Greear
2002-10-02 11:13 ` Eric Lemoine
2002-10-02 14:09 ` Chris Friesen
2002-10-02 15:25 ` Ben Greear
2002-10-03 15:58 ` Eric Lemoine
2002-10-03 16:29 ` kuznet
2002-09-27 15:19 ` Eric Lemoine
2002-09-27 15:57 ` Eric Lemoine
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D99F17D.10802@nortelnetworks.com \
--to=cfriesen@nortelnetworks.com \
--cc=greearb@candelatech.com \
--cc=hadi@cyberus.ca \
--cc=kuznet@ms2.inr.ac.ru \
--cc=netdev@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).