On Sat, 17 Jul 1999, Matthew Dillon wrote:
> :> 2.6 MB/sec is what I would expect if you were running the test
> :> over an ssh link on a fast cpu - the encryption eats a lot of cpu. But
> :> a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec.
> :
> : That was actu
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> :> 2.6 MB/sec is what I would expect if you were running the test
> :> over an ssh link on a fast cpu - the encryption eats a lot of cpu. But
> :> a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec.
> :
> : That was act
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> : Hmmm, how did you do the measurement and how big of a file does it
> :need?
> :
> : With a 122MByte file, it only does 2644Kbytes/sec. This is
> :between two Pentium II 450 machines with Intel Pro100+ NICs.
> :
> :
> :Cheers,
> :Vince - vi...
On Sat, 17 Jul 1999, David E. Cross wrote:
> I have a number of questions on more specific ideas (like caching, inode/vnode
> interaction, etc). But I am just feeling arround for what people think
> about this. Any ideas/comments?
John Heidemann's papers on file system stacking layers refer to
Dag-Erling Smorgrav wrote:
>
> "Daniel C. Sobral" writes:
> > * a sysctl to make the system non-overcommit
>
> So I see common sense lost in the end.
I think nobody objects to the knob, just to people trying to
convince us that it would do any good.
> > * SIGDANGER in low-memory si
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> : Hmmm, how did you do the measurement and how big of a file does it
> :need?
> :
> : With a 122MByte file, it only does 2644Kbytes/sec. This is
> :between two Pentium II 450 machines with Intel Pro100+ NICs.
> :
> :
> :Cheers,
> :Vince - [EMA
On Sat, 17 Jul 1999, David E. Cross wrote:
> I am looking at a project that will require a user based process to interact
> with the system as if it were a filesystem. The traditional way I have seen
[...]
> I have a number of questions on more specific ideas (like caching, inode/vnode
> interac
On Sat, 17 Jul 1999, David E. Cross wrote:
> I have a number of questions on more specific ideas (like caching, inode/vnode
> interaction, etc). But I am just feeling arround for what people think
> about this. Any ideas/comments?
John Heidemann's papers on file system stacking layers refer to
:> :
:> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
:> : gr...@freebsd.org _ __ ___ | _ ) __| \
:>
:> Actually, it isn't quite. All the portal filesystem will allow you
:> to do is pass back a descriptor. It does not allow you to simulate
:> a f
Dag-Erling Smorgrav wrote:
>
> "Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
> > * a sysctl to make the system non-overcommit
>
> So I see common sense lost in the end.
I think nobody objects to the knob, just to people trying to
convince us that it would do any good.
> > * SIGDAN
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> :
> :Look into the portal filesystem. This is what you want :)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : gr...@freebsd.org _ __ ___ | _ ) __| \
>
> Actually, it isn't quite. All the portal filesys
On Sat, 17 Jul 1999, David E. Cross wrote:
> I am looking at a project that will require a user based process to interact
> with the system as if it were a filesystem. The traditional way I have seen
[...]
> I have a number of questions on more specific ideas (like caching, inode/vnode
> intera
:
:I'm not sure what good that will do me. The point of the exercise is to
:ensure that cdrecord never has to wait on enough seeks to create coasters.
:Putting it all in ram before starting should do this, but a different
:interface to the same data on disk doesn't.
:
:Unless I'm missing something
:> :
:> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
:> : [EMAIL PROTECTED] _ __ ___ | _ ) __| \
:>
:> Actually, it isn't quite. All the portal filesystem will allow you
:> to do is pass back a descriptor. It does not allow you to simulate
:> a
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> :
> :Look into the portal filesystem. This is what you want :)
> :
> : Brian Fundakowski Feldman _ __ ___ ___ ___ ___
> : [EMAIL PROTECTED] _ __ ___ | _ ) __| \
>
> Actually, it isn't quite. All the portal filesy
On Thu, 15 Jul 1999, Matthew Dillon wrote:
> :
> :Are there any design limits to mfs? I want to use cdrecord to write to a
> :dozen or so CD's at once, and fear making lots of coasters if I run them
> :all off a single on-disk file. However, a CD only holds 650 MB, so it
> :seems like I could ha
:
:I'm not sure what good that will do me. The point of the exercise is to
:ensure that cdrecord never has to wait on enough seeks to create coasters.
:Putting it all in ram before starting should do this, but a different
:interface to the same data on disk doesn't.
:
:Unless I'm missing somethin
:On 17-Jul-99 Matthew Dillon wrote:
:>
:> Obviously you don't get square waves going down the wire - But it is
:> still a digital communications protocol.
:>
:> -Matt
:
:However the physical layer, i.e. the cable, is analogue and the discussion was
:a
:> 2.6 MB/sec is what I would expect if you were running the test
:> over an ssh link on a fast cpu - the encryption eats a lot of cpu. But
:> a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec.
:
: That was actually done with ftp between two machines connected
:F
:
:Look into the portal filesystem. This is what you want :)
:
: Brian Fundakowski Feldman _ __ ___ ___ ___ ___
: gr...@freebsd.org _ __ ___ | _ ) __| \
Actually, it isn't quite. All the portal filesystem will allow you
to do is pass back a descriptor. I
On Thu, 15 Jul 1999, Matthew Dillon wrote:
> :
> :Are there any design limits to mfs? I want to use cdrecord to write to a
> :dozen or so CD's at once, and fear making lots of coasters if I run them
> :all off a single on-disk file. However, a CD only holds 650 MB, so it
> :seems like I could h
:On 17-Jul-99 Matthew Dillon wrote:
:>
:> Obviously you don't get square waves going down the wire - But it is
:> still a digital communications protocol.
:>
:> -Matt
:
:However the physical layer, i.e. the cable, is analogue and the discussion was
:
:> 2.6 MB/sec is what I would expect if you were running the test
:> over an ssh link on a fast cpu - the encryption eats a lot of cpu. But
:> a normal rcp or ftp or data transfer can easily do 9-10 MBytes/sec.
:
: That was actually done with ftp between two machines connected
:
Look into the portal filesystem. This is what you want :)
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/__
Vincent Poy wrote:
> Testing after the dust has settled and while it is in use is
> different since conditions do change. The testers only tests for
> continuity, not the impedance or any other electrical properties of the
> cable.
The decent testers (such as a professional cable install
On Sat, 17 Jul 1999, Vincent Poy wrote:
> > > > As I said, I used ttcp. ttcp is a "network only" test - it can source
> > > > or sink traffic itself. This is nice because you avoid other sources of
> > > > problems (disk bandwidth etc). I tended to run the tests for 30 seconds
> > > > to one minut
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> : Hmmm, how did you do the measurement and how big of a file does it
> :need?
> :
> : With a 122MByte file, it only does 2644Kbytes/sec. This is
> :between two Pentium II 450 machines with Intel Pro100+ NICs.
>
> 2.6 MB/sec is what I would
:
:Look into the portal filesystem. This is what you want :)
:
: Brian Fundakowski Feldman _ __ ___ ___ ___ ___
: [EMAIL PROTECTED] _ __ ___ | _ ) __| \
Actually, it isn't quite. All the portal filesystem will allow you
to do is pass back a descriptor.
On Sun, 18 Jul 1999 sth...@nethelp.no wrote:
> > > As I said, I used ttcp. ttcp is a "network only" test - it can source
> > > or sink traffic itself. This is nice because you avoid other sources of
> > > problems (disk bandwidth etc). I tended to run the tests for 30 seconds
> > > to one minute.
On Sun, 18 Jul 1999, Leif Neland wrote:
> > > There again, any network installer worth their salt will test the cable
> when
> > > in-situ, after the 'dust' has settled...
> >
> > Testing after the dust has settled and while it is in use is
> > different since conditions do change. The testers on
On 17-Jul-99 Matthew Dillon wrote:
>
> Obviously you don't get square waves going down the wire - But it is
> still a digital communications protocol.
>
> -Matt
However the physical layer, i.e. the cable, is analogue and the discussion was
about cab
: Hmmm, how did you do the measurement and how big of a file does it
:need?
:
: With a 122MByte file, it only does 2644Kbytes/sec. This is
:between two Pentium II 450 machines with Intel Pro100+ NICs.
:
:
:Cheers,
:Vince - vi...@mcestate.com - vi...@gaianet.net __
> > As I said, I used ttcp. ttcp is a "network only" test - it can source
> > or sink traffic itself. This is nice because you avoid other sources of
> > problems (disk bandwidth etc). I tended to run the tests for 30 seconds
> > to one minute.
>
> Oops, must have missed that one. How do I
- Original Message -
From: Vincent Poy
To: Karl Pielorz
Cc: ; ;
Sent: Sunday, July 18, 1999 12:22 AM
Subject: Re: poor ethernet performance?
> > There again, any network installer worth their salt will test the cable
when
> > in-situ, after the 'dust' has settled...
>
> Testing after
On Sun, 18 Jul 1999 sth...@nethelp.no wrote:
> > Hmmm, how did you do the measurement and how big of a file does it
> > need?
>
> As I said, I used ttcp. ttcp is a "network only" test - it can source
> or sink traffic itself. This is nice because you avoid other sources of
> problems (disk ba
> Hmmm, how did you do the measurement and how big of a file does it
> need?
As I said, I used ttcp. ttcp is a "network only" test - it can source
or sink traffic itself. This is nice because you avoid other sources of
problems (disk bandwidth etc). I tended to run the tests for 30 seconds
t
:I have a machine with two scsi disks, one with /, one with /usr, and no
:floppy.
:I have turned on softupdates on /usr while usr was unmounted, but I can't
:turn on softupdates on /, because it is always mounted.
:
:Normally the answer would be to boot on a floppy, but the machine doesn't
:have a
On Sun, 18 Jul 1999 sth...@nethelp.no wrote:
> > I mean Mega as in 100. 100Mbps Ethernet should be equal to
> > about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec
> > doesn't equal to 100Megabits/sec.
>
> 12.5 Mbytes/sec on the wire *is* 94.93 Megabits/sec applica
Look into the portal filesystem. This is what you want :)
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/_
> I mean Mega as in 100. 100Mbps Ethernet should be equal to
> about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec
> doesn't equal to 100Megabits/sec.
12.5 Mbytes/sec on the wire *is* 94.93 Megabits/sec application to
application using TCP - that's what I'm trying
Vincent Poy wrote:
> Testing after the dust has settled and while it is in use is
> different since conditions do change. The testers only tests for
> continuity, not the impedance or any other electrical properties of the
> cable.
The decent testers (such as a professional cable instal
On Sat, 17 Jul 1999, Vincent Poy wrote:
> > > > As I said, I used ttcp. ttcp is a "network only" test - it can source
> > > > or sink traffic itself. This is nice because you avoid other sources of
> > > > problems (disk bandwidth etc). I tended to run the tests for 30 seconds
> > > > to one minu
On Sat, 17 Jul 1999, Matthew Dillon wrote:
> : Hmmm, how did you do the measurement and how big of a file does it
> :need?
> :
> : With a 122MByte file, it only does 2644Kbytes/sec. This is
> :between two Pentium II 450 machines with Intel Pro100+ NICs.
>
> 2.6 MB/sec is what I woul
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote:
> > > As I said, I used ttcp. ttcp is a "network only" test - it can source
> > > or sink traffic itself. This is nice because you avoid other sources of
> > > problems (disk bandwidth etc). I tended to run the tests for 30 seconds
> > > to one minute.
On Sun, 18 Jul 1999 sth...@nethelp.no wrote:
> > It meets the spec when shipped but the bends, curves, temperature
> > and other factors do affect the performance. I guess a good way to test
> > the cable is with FreeBSD since it's the only real OS I've seen that can
> > do like real world sp
On Sun, 18 Jul 1999, Leif Neland wrote:
> > > There again, any network installer worth their salt will test the cable
> when
> > > in-situ, after the 'dust' has settled...
> >
> > Testing after the dust has settled and while it is in use is
> > different since conditions do change. The testers o
> It meets the spec when shipped but the bends, curves, temperature
> and other factors do affect the performance. I guess a good way to test
> the cable is with FreeBSD since it's the only real OS I've seen that can
> do like real world speeds. The only thing is that has anyone really saw
On 17-Jul-99 Matthew Dillon wrote:
>
> Obviously you don't get square waves going down the wire - But it is
> still a digital communications protocol.
>
> -Matt
However the physical layer, i.e. the cable, is analogue and the discussion was
about ca
: Hmmm, how did you do the measurement and how big of a file does it
:need?
:
: With a 122MByte file, it only does 2644Kbytes/sec. This is
:between two Pentium II 450 machines with Intel Pro100+ NICs.
:
:
:Cheers,
:Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __
> > As I said, I used ttcp. ttcp is a "network only" test - it can source
> > or sink traffic itself. This is nice because you avoid other sources of
> > problems (disk bandwidth etc). I tended to run the tests for 30 seconds
> > to one minute.
>
> Oops, must have missed that one. How do I
- Original Message -
From: Vincent Poy <[EMAIL PROTECTED]>
To: Karl Pielorz <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Sunday, July 18, 1999 12:22 AM
Subject: Re: poor ethernet performance?
> > There again, any network installer worth th
On Sat, 17 Jul 1999, Karl Pielorz wrote:
> Vincent Poy wrote:
>
> > > Note also that FreeBSD can easily saturate 100 Mbps Ethernet.
> >
> > It meets the spec when shipped but the bends, curves, temperature
> > and other factors do affect the performance. I guess a good way to test
> > t
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote:
> > Hmmm, how did you do the measurement and how big of a file does it
> > need?
>
> As I said, I used ttcp. ttcp is a "network only" test - it can source
> or sink traffic itself. This is nice because you avoid other sources of
> problems (disk b
Vincent Poy wrote:
> > Note also that FreeBSD can easily saturate 100 Mbps Ethernet.
>
> It meets the spec when shipped but the bends, curves, temperature
> and other factors do affect the performance. I guess a good way to test
> the cable is with FreeBSD since it's the only real OS I'v
> Hmmm, how did you do the measurement and how big of a file does it
> need?
As I said, I used ttcp. ttcp is a "network only" test - it can source
or sink traffic itself. This is nice because you avoid other sources of
problems (disk bandwidth etc). I tended to run the tests for 30 seconds
Craig Johnston wrote:
>
> Well, I'm looking into doing striping and mirroring on a new webserver
> I am bringing up (3.2-stable) and I have to say, vinum looks very cool.
> It took me like half an hour to get it going from first contact.
>
> Nice job Greg -- very straightforward.
>
> Now, the of
:I have a machine with two scsi disks, one with /, one with /usr, and no
:floppy.
:I have turned on softupdates on /usr while usr was unmounted, but I can't
:turn on softupdates on /, because it is always mounted.
:
:Normally the answer would be to boot on a floppy, but the machine doesn't
:have a
> Mike Smith wrote:
> >
> > The loader will, at some stage in the future, grow a persistent data
> > store in which items like this can be saved.
>
> Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> data storage?
Not if the items stored there are needed prior to being able
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote:
> > I mean Mega as in 100. 100Mbps Ethernet should be equal to
> > about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec
> > doesn't equal to 100Megabits/sec.
>
> 12.5 Mbytes/sec on the wire *is* 94.93 Megabits/sec applic
> I mean Mega as in 100. 100Mbps Ethernet should be equal to
> about 12500Kbytes/sec which is equal to 12.5Mbytes/sec. 94.93Megabits/sec
> doesn't equal to 100Megabits/sec.
12.5 Mbytes/sec on the wire *is* 94.93 Megabits/sec application to
application using TCP - that's what I'm tryin
On Sun, 18 Jul 1999 [EMAIL PROTECTED] wrote:
> > It meets the spec when shipped but the bends, curves, temperature
> > and other factors do affect the performance. I guess a good way to test
> > the cable is with FreeBSD since it's the only real OS I've seen that can
> > do like real world s
> It meets the spec when shipped but the bends, curves, temperature
> and other factors do affect the performance. I guess a good way to test
> the cable is with FreeBSD since it's the only real OS I've seen that can
> do like real world speeds. The only thing is that has anyone really saw
I have a machine with two scsi disks, one with /, one with /usr, and no
floppy.
I have turned on softupdates on /usr while usr was unmounted, but I can't
turn on softupdates on /, because it is always mounted.
Normally the answer would be to boot on a floppy, but the machine doesn't
have a floppyd
On Sat, 17 Jul 1999, Karl Pielorz wrote:
> Vincent Poy wrote:
>
> > > Note also that FreeBSD can easily saturate 100 Mbps Ethernet.
> >
> > It meets the spec when shipped but the bends, curves, temperature
> > and other factors do affect the performance. I guess a good way to test
> >
On Sat, 17 Jul 1999 sth...@nethelp.no wrote:
> > I am benefiting from it for sure. I guess what I was asking
> > originally was if the higher frequency rated cables will give it more
> > headroom since the 100BaseTX ethernet does push CAT5 to the limit.
>
> 100BaseTX is specified to run on C
Vincent Poy wrote:
> > Note also that FreeBSD can easily saturate 100 Mbps Ethernet.
>
> It meets the spec when shipped but the bends, curves, temperature
> and other factors do affect the performance. I guess a good way to test
> the cable is with FreeBSD since it's the only real OS I'
Craig Johnston wrote:
>
> Well, I'm looking into doing striping and mirroring on a new webserver
> I am bringing up (3.2-stable) and I have to say, vinum looks very cool.
> It took me like half an hour to get it going from first contact.
>
> Nice job Greg -- very straightforward.
>
> Now, the o
> Mike Smith wrote:
> >
> > The loader will, at some stage in the future, grow a persistent data
> > store in which items like this can be saved.
>
> Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
> data storage?
Not if the items stored there are needed prior to being able
On 17 Jul 1999, Dag-Erling Smorgrav wrote:
> Is there any (evidently non-portable) way of determining a function
> instance's return address? I have an idea or two that involves the
> return address and dladdr(). The code I currently use looks like this:
>
> int
> log_print(log_t *log, char *fmt,
I have a machine with two scsi disks, one with /, one with /usr, and no
floppy.
I have turned on softupdates on /usr while usr was unmounted, but I can't
turn on softupdates on /, because it is always mounted.
Normally the answer would be to boot on a floppy, but the machine doesn't
have a floppy
> "Alex" == Alex Povolotsky writes:
Alex> Hello! Is it possible to have a root partition on vinum'ed disk
Alex> and benefit from mirroring? If yes, how do I do it?
My current design for this type of situation is to have 64M boot
partitions and 256M swap partitions on each disk. I then use
On Sat, 17 Jul 1999 [EMAIL PROTECTED] wrote:
> > I am benefiting from it for sure. I guess what I was asking
> > originally was if the higher frequency rated cables will give it more
> > headroom since the 100BaseTX ethernet does push CAT5 to the limit.
>
> 100BaseTX is specified to run on
Well, I'm looking into doing striping and mirroring on a new webserver
I am bringing up (3.2-stable) and I have to say, vinum looks very cool.
It took me like half an hour to get it going from first contact.
Nice job Greg -- very straightforward.
Now, the official status of vinum is still alpha,
On 17 Jul 1999, Dag-Erling Smorgrav wrote:
> Is there any (evidently non-portable) way of determining a function
> instance's return address? I have an idea or two that involves the
> return address and dladdr(). The code I currently use looks like this:
>
> int
> log_print(log_t *log, char *fmt
> "Alex" == Alex Povolotsky <[EMAIL PROTECTED]> writes:
Alex> Hello! Is it possible to have a root partition on vinum'ed disk
Alex> and benefit from mirroring? If yes, how do I do it?
My current design for this type of situation is to have 64M boot
partitions and 256M swap partitions on eac
What purpose is served by the twisty maze of ifdefs in telnetd? I'd
like to unifdef many of them. I'm trying to track down a bug and the
twisty maze makes it very hard to follow. Comments?
Warner
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the bod
Well, I'm looking into doing striping and mirroring on a new webserver
I am bringing up (3.2-stable) and I have to say, vinum looks very cool.
It took me like half an hour to get it going from first contact.
Nice job Greg -- very straightforward.
Now, the official status of vinum is still alpha,
I am looking at a project that will require a user based process to interact
with the system as if it were a filesystem. The traditional way I have seen
this done is as the system NFS mounting itself (ala AMD). I would really like
a more clean approach to this. What I am interested in is a 'Use
Hello!
Is it possible to have a root partition on vinum'ed disk and benefit from
mirroring? If yes, how do I do it?
Alex.
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
What purpose is served by the twisty maze of ifdefs in telnetd? I'd
like to unifdef many of them. I'm trying to track down a bug and the
twisty maze makes it very hard to follow. Comments?
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body o
I am looking at a project that will require a user based process to interact
with the system as if it were a filesystem. The traditional way I have seen
this done is as the system NFS mounting itself (ala AMD). I would really like
a more clean approach to this. What I am interested in is a 'Us
Hello!
Is it possible to have a root partition on vinum'ed disk and benefit from
mirroring? If yes, how do I do it?
Alex.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
"Daniel C. Sobral" writes:
> * a sysctl to make the system non-overcommit
So I see common sense lost in the end.
> * SIGDANGER in low-memory situations
Do we support more than 32 signals?
ISTR AIX already does this. What signal numbers / names does AIX use
for this?
> * Divi
Dag-Erling Smorgrav wrote:
>
> Assem Salama writes:
> > I am interested in helping in the development in FreeBSD. I'm not a
> > hotshot programmer but I know how to program. Could someone please send
> > me the available projects that I can work on and some info about them?
>
> http://www.freebs
Assem Salama writes:
> I am interested in helping in the development in FreeBSD. I'm not a
> hotshot programmer but I know how to program. Could someone please send
> me the available projects that I can work on and some info about them?
http://www.freebsd.org/handbook/contrib.html>
DES
--
Dag-
"Daniel C. Sobral" <[EMAIL PROTECTED]> writes:
> * a sysctl to make the system non-overcommit
So I see common sense lost in the end.
> * SIGDANGER in low-memory situations
Do we support more than 32 signals?
ISTR AIX already does this. What signal numbers / names does AIX use
for t
Mike Smith wrote:
>
> The loader will, at some stage in the future, grow a persistent data
> store in which items like this can be saved.
Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
data storage?
--
Daniel C. Sobral(8-DCS)
d...@newsguy.com
d...@free
Dag-Erling Smorgrav wrote:
>
> Assem Salama <[EMAIL PROTECTED]> writes:
> > I am interested in helping in the development in FreeBSD. I'm not a
> > hotshot programmer but I know how to program. Could someone please send
> > me the available projects that I can work on and some info about them?
>
Assem Salama <[EMAIL PROTECTED]> writes:
> I am interested in helping in the development in FreeBSD. I'm not a
> hotshot programmer but I know how to program. Could someone please send
> me the available projects that I can work on and some info about them?
http://www.freebsd.org/handbook/contrib
:
:It results sometimes in out of swap, too.
:
:> Inetd is rate-limited by default nowadays, so this really doesn't apply.
:
:It really does apply. Inetd limits incoming connections per minute, not per
:second. It is possible to use minute limit in a few seconds and cause a high
:load. Sendmail is
Mike Smith wrote:
>
> The loader will, at some stage in the future, grow a persistent data
> store in which items like this can be saved.
Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent
data storage?
--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL
:> machine. In this case the overcommit that can occur is with I/O, not
:> swap. As a general performance rule, you have to set MaxDaemonChildren
:> and MaxArticleSize to prevent the overcommit from occuring. This is a
:> function of sendmail, not a function of the kernel.
:
:Sig
:
:And you seen the nice square waves of 100Mb or !Gb ether on a line then? The
:techniques used for transmitting 100Mb/s down copper are certainly not digital.
:Pulse shaping, line estimation, ISI removal are all analogue!
:
:The cable itself is less improtant than the impedance matching at conne
:
:It results sometimes in out of swap, too.
:
:> Inetd is rate-limited by default nowadays, so this really doesn't apply.
:
:It really does apply. Inetd limits incoming connections per minute, not per
:second. It is possible to use minute limit in a few seconds and cause a high
:load. Sendmail i
:> machine. In this case the overcommit that can occur is with I/O, not
:> swap. As a general performance rule, you have to set MaxDaemonChildren
:> and MaxArticleSize to prevent the overcommit from occuring. This is a
:> function of sendmail, not a function of the kernel.
:
:Si
:
:And you seen the nice square waves of 100Mb or !Gb ether on a line then? The
:techniques used for transmitting 100Mb/s down copper are certainly not digital.
:Pulse shaping, line estimation, ISI removal are all analogue!
:
:The cable itself is less improtant than the impedance matching at conn
I am interested in helping in the development in FreeBSD. I'm not a
hotshot programmer but I know how to program. Could someone please send
me the available projects that I can work on and some info about them?
Thanks,
Assem Salama
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubs
Is there any (evidently non-portable) way of determining a function
instance's return address? I have an idea or two that involves the
return address and dladdr(). The code I currently use looks like this:
int
log_print(log_t *log, char *fmt, ...)
{
char date[32], str[MAX_LOG_LINE];
struct
I am interested in helping in the development in FreeBSD. I'm not a
hotshot programmer but I know how to program. Could someone please send
me the available projects that I can work on and some info about them?
Thanks,
Assem Salama
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscri
Is there any (evidently non-portable) way of determining a function
instance's return address? I have an idea or two that involves the
return address and dladdr(). The code I currently use looks like this:
int
log_print(log_t *log, char *fmt, ...)
{
char date[32], str[MAX_LOG_LINE];
struc
1 - 100 of 113 matches
Mail list logo
