"David Schwartz" wrote:
>
> > Well, we've heard various opinions and I think we can conclude that:
> >
> > 2. That server applications should have keepalives enabled.
>
> Well, I certainly don't agree with that. Many server applications (web
> servers, mail servers, etcetera) already have
¹ã¸æê°î¸üÃÿìµà http://www.gglb.com
1¡¢Ã«ÃÃÃóö¡°Ãâ·Ã·ÃÃà ¹ã¸æ¡°Ã¸Ã¿ http://ad.gglb.com Ãú¿ÃÃÃÃô÷¢²¼ÃúµÃûÃÃ
ºÃ·¨ÃÃ
¡£
2¡¢Ã«¹úèûµÃ¡°¹ã¸æÃÃÃÃÃìÃá±³ÃÃûÃúÃôÃÃãÃÃ
> Well, we've heard various opinions and I think we can conclude that:
>
> 2. That server applications should have keepalives enabled.
Well, I certainly don't agree with that. Many server applications (web
servers, mail servers, etcetera) already have data timeouts, which makes
keepalive
Well, we've heard various opinions and I think we can conclude that:
1. Even with the current timeouts, there is no significant increase
in network trafic, even with the market share FreeBSD has.
2. That server applications should have keepalives enabled.
3. That the few people, for whom
In message <199906042217.paa22...@gndrsh.aac.dev.com>, "Rodney W. Grimes"
writes:
>> In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
>>
>> >But, consider going back to the discusssions leading up to the Host
>> >Requirements
>> >RFC (1122). The particular problem was that t
Jordan Hubbard writes:
>1. Put pccardd on the mfsroot floppy and add a few things to
> sysinstall (this may already be done by his patches, I haven't
> had time to check) which enable its use during installation.
>
>2. Bring in message catalog and BIG5 support so that the standard
> installe
You know, I was going to buy a pickup truck, but I was afraid my
neighbors
would figure that if I bought a pickup truck, they should buy one too. And
maybe a pickup truck isn't the right vehicle for them -- perhaps they didn't
even know how to drive one safely. So I bought an Explorer ins
:At 01:08 PM 6/4/99 , Matthew Dillon wrote:
:>:had not been done, then the Internet would not have grown as it did today.
:>:
:>:The central issue of keepalives is that, for one machine, they don't create
:>:a significant load. Multiplied by the number of machines on the Internet,
:>:it can becom
<
said:
>> [I wrote:]
>> The user programs should not use SIOCGIFCONF.
> I was hoping for a little more information than that.
> OK, imagine a world where you had no choice. THEN what would the answer be?
1) Implement sysctl net-route-iflist.
2) The user programs should not use SIOCGIFCONF.
-
Garrett Wollman writes:
> > Should the kernel insure that ifr->ifr_addr.sa_len is always at
> > least sizeof(ifr->ifr_addr), or should the user programs adjust
> > their pointer increment algorithm? At first I assumed the latter
> > answer (patches below) but now am not so sure.
>
> The us
<
said:
> Should the kernel insure that ifr->ifr_addr.sa_len is always at
> least sizeof(ifr->ifr_addr), or should the user programs adjust
> their pointer increment algorithm? At first I assumed the latter
> answer (patches below) but now am not so sure.
The user programs should not use
I've noticed that several programs have a subtle problem when scanning
the list returned by the SIOCGIFCONF ioctl. The problem is that these
programs do this computation to increment the pointer in the list:
ifr = (struct ifreq *) ((char *) &ifr->ifr_addr + ifr->ifr_addr.sa_len);
There are case
Nate Williams wrote:
> > How about this then:
> >
> > net.inet.tcp.always_keepidle: 86400 /* new variable */
> > net.inet.tcp.always_keepintvl: 64800/* new variable */
> > net.inet.tcp.keepidle: 14400
> > net.inet.tcp.keepintvl: 150
> > net.inet.tcp.always_keepalive: 1
At 01:08 PM 6/4/99 , Matthew Dillon wrote:
>:had not been done, then the Internet would not have grown as it did today.
>:
>:The central issue of keepalives is that, for one machine, they don't create
>:a significant load. Multiplied by the number of machines on the Internet,
>:it can become a pro
> In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
>
> >But, consider going back to the discusssions leading up to the Host
> >Requirements
> >RFC (1122). The particular problem was that the original timeout value for
> >keepalives was tiny (a few minutes). 1122 dictated the
On Fri, 4 Jun 1999, Bret Ford wrote:
> vx0: <3Com 3C597-TX Network Adapter> at slot 5 on eisa0
> vx0: No I/O space?!
> device_probe_and_attach: vx0 attach returned -1
This was fixed in version 1.45 of sys/i386/eisaconf.c
--
| Matthew N. Dodd | 78 280Z | 75 164E | 84 245DL | FreeBSD/NetBSD/Sprit
How do,
-hackers was silent about this, so I'm resending it to -current. Any
comments before I commit this (trivial) change?
N
==
docs/11589 says that programs that include aio.h also need to include
sys/time.h.
I've had a chat with Terry Lambert, who wrote the aio_read.2 manual page,
who sa
I'm running 4.0 - current from the middle of May, approximately.
I recently acquired an EISA 3COM network adapter that I'm now
trying to install. Here's a snip from my dmesg output:
vx0: <3Com 3C597-TX Network Adapter> at slot 5 on eisa0
vx0: No I/O space?!
device_probe_and_attach: vx0 attach
In message <199906042048.gaa25...@godzilla.zeta.org.au>, Bruce Evans writes:
>You're forgetting that devsw[] is another stopgap. The kernel should
>probably use something like devfs, where dev_t's only exist for devices
>that actually exist. xxx_init() is far too early to decide which hardware
>
>> The isa drivers provide many bad examples. Most of them attached the
>> devsw in a disgusting SYSINIT even if the device is disabled. I moved
>> the devsw attach to the device attach function in some drivers that
>> I worked on. This was necessary to support pcvt and syscons sharing a
>> devs
In message <199906042013.naa29...@implode.root.com>, David Greenman writes:
>>> I don't support increasing the default timeout. That would cause problems
>>>for a lot of server systems that rely on the relatively short two hour
>>>default.
>>>The best I think you could do would be to increase it
:
:Around 0.02%, using the stats from one of BEST's busier servers.
:That's percent.
Oops, I wrong. It's actually less then that... the network counters
overflowed. More around 0.001%. That's relative to outgoing traffic,
not relative to network capacity. And, to be nice,
>> I don't support increasing the default timeout. That would cause problems
>>for a lot of server systems that rely on the relatively short two hour
>>default.
>>The best I think you could do would be to increase it to something like
>>12-24 hours as a default, but even that might be problemati
:had not been done, then the Internet would not have grown as it did today.
:
:The central issue of keepalives is that, for one machine, they don't create
:a significant load. Multiplied by the number of machines on the Internet,
:it can become a problem.
As I said. People are arguing about
:Hint: If everybody turned on TCP keepalives, what percentage of the
:traffic on Internet backbones do you think would be keepalive
:packets?
:
:Jim Shankland
:NLynx Systems, Inc.
Around 0.02%, using the stats from one of BEST's busier servers.
That's percent.
In otherwords, nobody wo
"Kevin J. Rowett" writes:
> The central issue of keepalives is that, for one machine, they don't
> create a significant load. Multiplied by the number of machines on
> the Internet, it can become a problem.
No offense, but that is the most ludicrous assertion I've heard since
Slobodan Milosevic
On Sat, 5 Jun 1999, Bruce Evans wrote:
> >> Hm, I think this a bad choice. Which are 'all the other drivers'? The
> >> probe should really be as thin as possible to avoid unnecessary delays
> >> when probing in a kernel, like GENERIC, with a lot of device drivers
> >> compiled in.
> >
> >Well, in
On Sat, 5 Jun 1999, Bruce Evans wrote:
>
> The isa drivers provide many bad examples. Most of them attached the
> devsw in a disgusting SYSINIT even if the device is disabled. I moved
> the devsw attach to the device attach function in some drivers that
> I worked on. This was necessary to su
At 11:24 AM -0700 6/4/99, David Greenman wrote:
> someone else wrote:
>>
>> I still think the right thing is:
>> default to keepalives.
>> set the timeout to a week.
>
> I don't support increasing the default timeout. That would cause
> problems for a lot of server systems that rely on
> How about this then:
>
> net.inet.tcp.always_keepidle: 86400 /* new variable */
> net.inet.tcp.always_keepintvl: 64800/* new variable */
> net.inet.tcp.keepidle: 14400
> net.inet.tcp.keepintvl: 150
> net.inet.tcp.always_keepalive: 1
>
> This will have all s
In message <99jun4.143622est.40...@border.alcanet.com.au>, Peter Jeremy writes:
>I notice that sysctl -d doesn't work, and I suspect it never did.
right.
My proposal:
In the LINT kernel, the descriptions are compiled into a separate
section and a small program converts this section into the sysc
In message <199906041824.laa29...@implode.root.com>, David Greenman writes:
>>In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
>>
>>>But, consider going back to the discusssions leading up to the Host
>>>Requirements
>>>RFC (1122). The particular problem was that the original
In message <4.2.0.56.19990604111235.00ae3...@rowett.org>, "Kevin J. Rowett"
writes:
>The central issue of keepalives is that, for one machine, they don't create
>a significant load. Multiplied by the number of machines on the Internet,
>it can become a problem.
Reality home-work assignment to K
>In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
>
>>But, consider going back to the discusssions leading up to the Host
>>Requirements
>>RFC (1122). The particular problem was that the original timeout value for
>>keepalives was tiny (a few minutes). 1122 dictated the corre
At 07:56 PM 6/4/99 +0200, Poul-Henning Kamp wrote:
>I still think the right thing is:
>
> default to keepalives.
> set the timeout to a week.
OpenLDAP slapd, like may other daemons, relies on timeouts being a
reasonably short (a few hours) to deal with dead streams. Dead
streams occur
At 10:03 AM 6/4/99 , Matthew Dillon wrote:
> I think people just like to argue sometimes. The reality is different.
>
> For all you people complaining: Just turn them on and I guarentee
> you will not even notice the difference, except you will stop getting
> ( even the occassiona
In message <37580f03.88efb...@sitara.net>, "John R. LoVerso" writes:
>But, consider going back to the discusssions leading up to the Host
>Requirements
>RFC (1122). The particular problem was that the original timeout value for
>keepalives was tiny (a few minutes). 1122 dictated the corrections
> "32bit is enought for everthing"
Just mention the horrible header offset field. Lots of good TCP nits.
Anyway, can't this argument be settled by separating the mechanism and policy.
Adding a simple rc.conf tweak to enable them should be enough.
But, consider going back to the discu
I think people just like to argue sometimes. The reality is different.
For all you people complaining: Just turn them on and I guarentee
you will not even notice the difference, except you will stop getting
( even the occassional ) stale internet server process. That is what
In message <199906041621.maa11...@khavrinen.lcs.mit.edu>, Garrett Wollman
writes:
>< said:
>
>> Pierre, let me make the suggestion to you that you try turning them
>> on. I'll bet you dollars to donoughts that you will not notice
>> the difference.
>
>Except when you happen to run int
On 04-Jun-99 bush doctor wrote:
> Pentium Pro MTRR support enabled, default memory type is uncacheable
>
> What is MTRR? Using the web based cross referencing tool I came up with
MTRR's are a way to tell the p
> In message <19990604170654.a8...@salmon.maths.tcd.ie>, David Malone writes:
>
> >It might be nice to have two keepalive timeouts like Nate suggested.
> >You'd have a short one, which applies if the application turns on
> >keepalive or you have alwayskeepalive on. Then you'd have a long
> >one, w
George Michaelson writes:
> Also, some commentary on the advisability of enabling softupdates on /
> for large single-partition configs would be useful: since it demands
> unmounted fs to apply tunefs to the device, this is "challenging" at
> first glance.
No. Boot in single-user mode, and type
< said:
> Pierre, let me make the suggestion to you that you try turning them
> on. I'll bet you dollars to donoughts that you will not notice
> the difference.
Except when you happen to run into one of the inventors of TCP and he
tells you what an dolt you appear to be...
-GAWollma
:On Tue, Jun 01, 1999 at 03:02:47PM -0700, Matthew Dillon wrote:
:> I think keepalive's could easily be turned on by default. At BEST, one
:> of the first things I did 5 years ago was to turn them on permanently
:> on all of our machines.
:
:I'd like to disagree on the "by default" p
In message <19990604170654.a8...@salmon.maths.tcd.ie>, David Malone writes:
>It might be nice to have two keepalive timeouts like Nate suggested.
>You'd have a short one, which applies if the application turns on
>keepalive or you have alwayskeepalive on. Then you'd have a long
>one, which applies
On Fri, Jun 04, 1999 at 03:32:02PM +0200, Pierre Beyssac wrote:
> I don't see what this fuss is all about. If for _some_ big servers
> there are many dead connections around after a while (*), why don't
> THEY use a sysctl at boot-time to change the default state, rather
> than impose on the rest
After reading /sys/boot/README, I decided to sync up my -current boxes.
I began playing around with loader, kld's and the splash screens. Now I
have a few queries ... #;^)
>> Hm, I think this a bad choice. Which are 'all the other drivers'? The
>> probe should really be as thin as possible to avoid unnecessary delays
>> when probing in a kernel, like GENERIC, with a lot of device drivers
>> compiled in.
>
>Well, in the PCI drivers, it is just the meteor, the brooktre
Nick
> Hm, I think this a bad choice. Which are 'all the other drivers'? The
> probe should really be as thin as possible to avoid unnecessary delays
> when probing in a kernel, like GENERIC, with a lot of device drivers
> compiled in.
Well, in the PCI drivers, it is just the meteor, the brooktr
> I've just fixed the bt848 driver (bktr) where the
> cdevsw_add() was accidentally added to the BSDI bktr_probe()
> and not the FreeBSD bktr_probe.
>
> Although Bruce and Nick said this really belongs, in the _attatch()
> function, I've kept it in the _probe() function for consistency
> w
Nick Hibma wrote:
> > cdevsw_add()
> This should definitely go into attach IMNSHO.
>
> Probe: Check whether hardware is there (no side effects if possible).
> Attach:Get the device up and running and integrated into the kernel.
>
> With the priority probes this is even more distinct as a priori
Hi guys,
Since this isn't something everyone agrees on, how about adding a knob
to the boot time config files? This would make the keep-alive issue more
visible, and encourage folks to think about what they want.
Ciao,
Sheldon.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscri
On Tue, Jun 01, 1999 at 03:02:47PM -0700, Matthew Dillon wrote:
> I think keepalive's could easily be turned on by default. At BEST, one
> of the first things I did 5 years ago was to turn them on permanently
> on all of our machines.
I'd like to disagree on the "by default" part, on
This should definitely go into attach IMNSHO.
Probe: Check whether hardware is there (no side effects if possible).
Attach:Get the device up and running and integrated into the kernel.
With the priority probes this is even more distinct as a priority not
equal to 0 means 'no side effects, just c
In message <3757c851.4...@cs.strath.ac.uk>, Roger Hardiman writes:
>Hi there,
>
>Just a quick question.
>I'm about to fix the cdevsw_add(&bktr_cdevsw);
>bug in the brooktree848.c driver.
>
>Bruce wondered if this should go into bktr_attatch rather
>than bktr_probe?
>
>What do you think?
>I th
> -Original Message-
> From: Garrett Wollman [SMTP:woll...@khavrinen.lcs.mit.edu]
> Sent: Wednesday, June 02, 1999 9:13 PM
> To: Bruce Evans
> Cc: d...@nlsystems.com; woll...@khavrinen.lcs.mit.edu;
> curr...@freebsd.org; new...@atdot.dotat.org
> Subject: Re: IRQ sharing with newbus
In all fairness, since the SOFTUPDATES comments in LINT point you to
read the README, and this ask you to
(paraphrased)
"edit /etc/rc and disable update"
I suggest that following the guidelines closely will prove challenging :-)
Also, some commentary on the advisability of enabling so
> but idea for checking comes from maillist :) So it was good idea send mail
> here I thing.
No, it was not. :(
If you don't know enough to check LINT when enabling new kernel
features, you honestly should not be running -current and probably
shouldn't even be changing your kernel. Sorry, but I'
I waste 2 nights with this and be sure I reed manual before :( Sorry after
last review I found one missing symlink:
ln -s /usr/src/contrib/sys/softupdates/softdep.h softdep.h
but idea for checking comes from maillist :) So it was good idea send mail
here I thing.
Regardz
--
Tomas TPS Ulej
Syste
On Fri, 04 Jun 1999 09:45:31 +0200, "Tomas TPS Ulej" wrote:
> I add "options SOFTUPDATES" and my kernel won't compile
Read the section in LINT that dscribes the SOFTUPDATES option.
Ciao,
Sheldon.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the bod
> I add "options SOFTUPDATES" and my kernel won't compile
Please don't simply turn options on without reading about them first -
that is just foolish. Had you even bothered to look at LINT *before*
you sent this message, you would have clearly seen the comment:
# Soft updates is technique for im
On Fri, 4 Jun 1999, Tomas TPS Ulej wrote:
> I add "options SOFTUPDATES" and my kernel won't compile
[snip]
> cc: ../../ufs/ffs/ffs_softdep.c: No such file or directory
cd /usr/src/sys/ufs/ffs
ln -s /usr/src/contrib/sys/softupdates/ffs_softdep.c ffs_softdep.c
ln -s /usr/src/contrib/sys/softupdates
I add "options SOFTUPDATES" and my kernel won't compile
make depend =>
[snip]
ort.c ../../libkern/random.c ../../libkern/rindex.c ../../libkern/scanc.c
../../libkern/skpc.c ../../libkern/strcat.c ../../libkern/strcmp.c
../../libkern/strcpy.c ../../libkern/strlen.c ../../libkern/strncmp.c
../..
64 matches
Mail list logo
