From: Mark Frazer <mark@somanetworks.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bogdan Costescu <bogdan.costescu@iwr.uni-heidelberg.de>,
Jeff Garzik <jgarzik@mandrakesoft.com>,
Pete Zaitcev <zaitcev@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] support for Cobalt Networks (x86 only) systems (for
Date: Fri, 1 Jun 2001 10:37:49 -0400 [thread overview]
Message-ID: <20010601103749.C5248@somanetworks.com> (raw)
In-Reply-To: <Pine.LNX.4.33.0106011503030.18082-100000@kenzo.iwr.uni-heidelberg.de> <E155pmD-0000Zv-00@the-village.bc.nu>
In-Reply-To: <E155pmD-0000Zv-00@the-village.bc.nu>; from alan@lxorguk.ukuu.org.uk on Fri, Jun 01, 2001 at 03:19:45PM +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> [01/06/01 10:32]:
> > No way! If I implement a HA application which depends on link status, I
> > want the info to be accurate, I don't want to know that 30 seconds ago I
> > had good link.
> >
> > IMHO, rate limiting is the only solution.
>
> Please re-read your comment. Then think about it. Then tell me how rate limiting
> differs from caching to the application.
>
I'd argue for rate limiting as the application only gets back new data,
never a cached value n times in a row.
With caching, you'd have to let the application know when the cached
value was last read and how long it will be cached for. With rate
limiting, you'd just block the app and get the new data to the app
once the timer has expired. Or, if the app doesn't read the data
until after the timer has expired, it will not block at all.
Seems to me that you'd have less redundant application processing with
rate limiting.
next prev parent reply other threads:[~2001-06-01 14:38 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-01 2:47 [PATCH] support for Cobalt Networks (x86 only) systems (for real this time) Tim Hockin
2001-06-01 8:10 ` Jeff Garzik
2001-06-01 8:46 ` [PATCH] support for Cobalt Networks (x86 only) systems (for real this Alan Cox
[not found] ` <mailman.991383180.28261.linux-kernel2news@redhat.com>
2001-06-01 8:58 ` [PATCH] support for Cobalt Networks (x86 only) systems (for real this time) Pete Zaitcev
2001-06-01 12:03 ` Bogdan Costescu
2001-06-01 12:20 ` [PATCH] support for Cobalt Networks (x86 only) systems (for realthis time) Jeff Garzik
2001-06-01 12:51 ` [PATCH] support for Cobalt Networks (x86 only) systems (for realthis Alan Cox
2001-06-01 12:56 ` Jeff Garzik
2001-06-01 12:58 ` Alan Cox
2001-06-01 13:06 ` Bogdan Costescu
2001-06-01 13:15 ` [PATCH] support for Cobalt Networks (x86 only) systems (forrealthis Jeff Garzik
2001-06-01 13:19 ` David S. Miller
2001-06-01 14:02 ` Bogdan Costescu
2001-06-01 13:39 ` Bogdan Costescu
2001-06-01 14:14 ` jamal
2001-06-01 14:30 ` Bogdan Costescu
2001-06-02 14:49 ` jamal
2001-06-03 12:09 ` Bogdan Costescu
2001-06-04 18:43 ` Jeff Garzik
2001-06-04 19:08 ` jamal
2001-06-01 14:19 ` [PATCH] support for Cobalt Networks (x86 only) systems (for Alan Cox
2001-06-01 14:37 ` Mark Frazer [this message]
2001-06-01 14:37 ` Alan Cox
2001-06-01 14:45 ` Mark Frazer
2001-06-01 14:46 ` Bogdan Costescu
2001-06-01 17:37 ` Alan Cox
2001-06-02 8:20 ` Bogdan Costescu
2001-06-02 16:15 ` Alan Cox
2001-06-02 19:10 ` MII access (was [PATCH] support for Cobalt Networks (x86 only) systems) Bogdan Costescu
2001-06-02 19:25 ` MII access (was [PATCH] support for Cobalt Networks (x86 only) Alan Cox
2001-06-02 21:36 ` Bogdan Costescu
2001-06-02 21:37 ` Alan Cox
2001-06-03 11:59 ` Bogdan Costescu
2001-06-03 12:11 ` Jeff Garzik
2001-06-05 9:07 ` Bogdan Costescu
2001-06-10 2:07 ` eepro100 security fix [was: Re: MII access] Andrey Savochkin
2001-06-01 15:13 ` [PATCH] support for Cobalt Networks (x86 only) systems (for Bogdan Costescu
2001-06-02 22:04 ` [PATCH] support for Cobalt Networks (x86 only) systems (for realthis Jamie Lokier
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=20010601103749.C5248@somanetworks.com \
--to=mark@somanetworks.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=bogdan.costescu@iwr.uni-heidelberg.de \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=zaitcev@redhat.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