subject:"Advantages of Using SQL \?"

think about it yourself,

-easy data manipulation,
-reload of freeradius is not needed
-nice web interface dialup_admin
-you can make your own web interface with php easily with sql connectivity.
These are what I can think of at the moment. I also think it would be 
faster than using users file and freeradius would use less memory since 
it doesnt load the whole users file to memory (I think it loads it?!)
if you have many users for example. SQL is also designed for quick data 
retrieval so if you plan to have many users than it would give better 
performance when the server needs to find one user.

Perhaps you should also ask to yourself, what is the disadvantage?

Evren

Patrick wrote:

hi,

im a freeradius newbie but i was wondering if there are any major advantages
to running freeradius on an sql auth system or not ? other than of course
the obvious stuff like being able to replicate the tables etc...
Thanks
P
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

2003-08-04 Thread Vector

greater ability to manage and scale up.

vec

- Original Message - 
From: Patrick [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, August 04, 2003 2:43 AM
Subject: Advantages of Using SQL ?

 hi,

 im a freeradius newbie but i was wondering if there are any major
advantages
 to running freeradius on an sql auth system or not ? other than of course
 the obvious stuff like being able to replicate the tables etc...

 Thanks
 P

 -
 List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

On Mon August 4 2003 21:53, Evren Yurtesen wrote:
 think about it yourself,

 -easy data manipulation,
 -reload of freeradius is not needed
 -nice web interface dialup_admin
 -you can make your own web interface with php easily with sql connectivity.

Yes. These are all correct..

 These are what I can think of at the moment. I also think it would be
 faster than using users file and freeradius would use less memory since
 it doesnt load the whole users file to memory (I think it loads it?!)
 if you have many users for example. SQL is also designed for quick data
 retrieval so if you plan to have many users than it would give better
 performance when the server needs to find one user.

Actually, you are wrong on this point I think. FreeRadius _would_ use less 
memory, that is correct, although memory usage should not be an issue, 
however using a SQL server as an Authentication backend  _must_ be slower 
than a userlist that is already in memory. Just think about what happens..
FreeRadius with users file:
* Request comes in
* FreeRadius checks if the user is valid from its copy of the users file in 
memory
* FreeRadius responds to the NAS with allow or deny

FreeRadius with DB backend for Authentication:
* Request comes in
* FreeRadius sends a SQL query to the DB.
* DB does an index search for the username
* DB loads the usename records from disk into memory
* DB Sends the username record back to FreeRadius
* FreeRadius responds to the NAS with allow or deny

Which do you think will be faster??

 Perhaps you should also ask to yourself, what is the disadvantage?

See above.
DB backends are good, and save alot of admin, but don't expect them to be 
faster than a memory scan :-)


 Evren

 Patrick wrote:
  hi,
 
  im a freeradius newbie but i was wondering if there are any major
  advantages to running freeradius on an sql auth system or not ? other
  than of course the obvious stuff like being able to replicate the tables
  etc...
 
  Thanks
  P
 
 
  -
  List info/subscribe/unsubscribe? See
  http://www.freeradius.org/list/users.html

 -
 List info/subscribe/unsubscribe? See
 http://www.freeradius.org/list/users.html

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

RE: Advantages of Using SQL ?

2003-08-04 Thread Andrea Coppini

 DB backends are good, and save alot of admin, but don't expect them to
be 
 faster than a memory scan :-)


I haven't done any tests, but I would presume an SQL backend would be
more 'robust' than freeradius.

The way I see it, having 1 request a minute is definitely faster with a
users file in memory, but when the load hits and you have 10,000 hits
per minute, freeradius would grind to a halt having to look up the
credentials and handling all NAS comms simultaneously, while freeradius
+ sql would just continue doing their respective jobs as normal.



Andrea Coppini
+356 79 ANDREA (263732)

[EMAIL PROTECTED]


EMPOWER PEOPLE - THE WORLD IN YOUR HAND

iWG (iWORLD GROUP) is a global e-mobile company creating, building and growing new 
businesses.  iWG founders are pioneers in creating multi-billion dollar mobile and 
Internet businesses in Europe, Asia and the US.

The Global Partners include the shareholders Bank of America, Deutsche Bank, Hikari 
Tsushin, McCaw, PaineWebber/UBS, The Dolphins' Trust, Perikles Trust and the iAA 
Advisory Network.

www.iWG.info
www.countryprofiler.com/iWG


Privileged/Confidential Information may be contained in this message.  If you are not 
the addressee indicated in this message (or responsible for delivery of the message to 
such person), you may not copy or deliver this message to anyone. In such case, you 
should destroy this message and kindly notify the sender by reply email.

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

2003-08-04 Thread Graeme Hinchliffe

On Mon, 4 Aug 2003 18:01:07 +0200
Andrea Coppini [EMAIL PROTECTED] wrote:

  DB backends are good, and save alot of admin, but don't expect them to
 be 
  faster than a memory scan :-)
 
 
 I haven't done any tests, but I would presume an SQL backend would be
 more 'robust' than freeradius.
 
 The way I see it, having 1 request a minute is definitely faster with a
 users file in memory, but when the load hits and you have 10,000 hits
 per minute, freeradius would grind to a halt having to look up the
 credentials and handling all NAS comms simultaneously, while freeradius
 + sql would just continue doing their respective jobs as normal.

But as the same CPU would be working on the DB lookups AND the freeRADIUS code as 
well, it would slow down by a much larger factor.  You would now have 2 processes 
sharing the memory and CPU resources and bus of the system etc.. 

Fact is Disk access is horribly slow compared to memory.

Look at the spec of a fairly old (now) PC.. 100MHz FSB.. so thats around 100,000,000*4 
bytes per SECOND which is a tiny bit faster than a HDD don't you think.

Just look at the clock speed of your PC.. even if the data wasn't indexed in memory 
and was searched in a linear manner it would still be extremely quick in comparison to 
a db.

Graeme


-- 
-
Graeme Hinchliffe (BSc)
Core Team Member
Zen Internet (http://www.zen.co.uk)

ICQ 3842605 (link)

Direct: 01706 900 212
Sales : 0870 6000 971
Fax   : 0870 6000 972


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

On Mon August 4 2003 19:01, Andrea Coppini wrote:
  DB backends are good, and save alot of admin, but don't expect them to

 be

  faster than a memory scan :-)

 I haven't done any tests, but I would presume an SQL backend would be
 more 'robust' than freeradius.

 The way I see it, having 1 request a minute is definitely faster with a
 users file in memory, but when the load hits and you have 10,000 hits
 per minute, freeradius would grind to a halt having to look up the
 credentials and handling all NAS comms simultaneously, while freeradius
 + sql would just continue doing their respective jobs as normal.

If that were the case, it would only be because of a bug in FreeRadius.

Much more system resources are used by SQL+Radius than just by Radius.

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Thats totally wrong, so you say same cpu works on both db lookups and
freeradius, now when freeradius is making a lookup inside users file
which is in ram, the same cpu doesnt work on db lookups in memory or
what? so thats out of question.

but mysql is optimized for that kind of lookups, there is huge
difference. then again, you can increase the mysql memory cache that
mysql can cache the whole db inside the ram if it is small enough.

Now about searching in ram is better than using a database backend. I
wonder why companies do not store their database data in text files and
load them to ram :) now the problem is that also everytime you reload
radius it reloads the whole file since it cant know where the changed
data is. Thus uses far more cpu. It is definetely not a good thing if
you want your users to change their passwords from web, then you need to
write to users file and reload radius if you do not use sql. If you use
sql you can create a user which can only change some parts of the
database and limit the access. It is even more secure when configured
properly. It is 100 times easier to write a php script which does that
than writing it in c or perl

Evren

Graeme Hinchliffe wrote:
On Mon, 4 Aug 2003 18:01:07 +0200
Andrea Coppini [EMAIL PROTECTED] wrote:

DB backends are good, and save alot of admin, but don't expect them to
be

faster than a memory scan :-)

I haven't done any tests, but I would presume an SQL backend would be
more 'robust' than freeradius.
The way I see it, having 1 request a minute is definitely faster with a
users file in memory, but when the load hits and you have 10,000 hits
per minute, freeradius would grind to a halt having to look up the
credentials and handling all NAS comms simultaneously, while freeradius
+ sql would just continue doing their respective jobs as normal.

But as the same CPU would be working on the DB lookups AND the freeRADIUS code as well, it would slow down by a much larger factor. You would now have 2 processes sharing the memory and CPU resources and bus of the system etc..

Fact is Disk access is horribly slow compared to memory.

Look at the spec of a fairly old (now) PC.. 100MHz FSB.. so thats around 100,000,000*4 bytes per SECOND which is a tiny bit faster than a HDD don't you think.

Just look at the clock speed of your PC.. even if the data wasn't indexed in memory and was searched in a linear manner it would still be extremely quick in comparison to a db.

Graeme

-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

On Tue August 5 2003 05:34, Evren Yurtesen wrote:
 Thats totally wrong, so you say same cpu works on both db lookups and
 freeradius, now when freeradius is making a lookup inside users file
 which is in ram, the same cpu doesnt work on db lookups in memory or
 what? so thats out of question.

I am sorry to tell you Evren, but you ARE wrong. Even if you forget for a 
moment the fact that a DB server has to fetch the data from the disk and 
FreeRadius does not, It is MUCH more efficient for FreeRadius to search it's 
own memory space than to ask another program to supply the data.

Asking another program (A DB server or any other program) even if that program 
already has the data in memory is very slow comparitively as it forces a 
kernel context switch to load the other program onto the CPU, then another 
context switch to load FreeRadius onto the CPU.

Put simply you are wrong. Please read up about CPU design and operating system 
context switches before argueing this any more.

 but mysql is optimized for that kind of lookups, there is huge
 difference. then again, you can increase the mysql memory cache that
 mysql can cache the whole db inside the ram if it is small enough.

It is not. There is not. You are wrong. Even if you have the entire DB inside 
ram (which would nullify your point of using a DB instead of a client file to 
save on RAM usage) the CPU still has to switch the running context from FR - 
DB - FR which flushes all CPU caches and is very slow. not to mention the 
fact that there is TCP (or UNIX) socket overhead to slow things down. Of 
course there is also Parsing and reparsing of SQL statements  etc etc..

 Now about searching in ram is better than using a database backend. I
 wonder why companies do not store their database data in text files and
 load them to ram :)

They do. Of course they do. It is always faster to load data at run time than 
look it up later. using a DB is easier/better for maintenence. It is NOT 
faster.

 now the problem is that also everytime you reload
 radius it reloads the whole file since it cant know where the changed
 data is. Thus uses far more cpu. 

this ONLY happens at startup. how can it possibly use more CPU than requesting 
from disk for every query???!!!

 It is definetely not a good thing if
 you want your users to change their passwords from web, then you need to
 write to users file and reload radius if you do not use sql.

Yes. As mentioned before. DB is good for easy maintenence, NOT speed.

 If you use
 sql you can create a user which can only change some parts of the
 database and limit the access. It is even more secure when configured
 properly. It is 100 times easier to write a php script which does that
 than writing it in c or perl

We were argueing about speed, not other issues. DBs are good, but you are VERY 
wrong about them being faster than a memory search of the clients file..

If case you were wondering I maintain the postgresql configs and driver for 
FreeRadius, and run a DB backend with many GB of data in it.. Trust me, I 
know what I am talking about more than you do :-)

Peter

 Graeme Hinchliffe wrote:
  On Mon, 4 Aug 2003 18:01:07 +0200
 
  Andrea Coppini [EMAIL PROTECTED] wrote:
 DB backends are good, and save alot of admin, but don't expect them to
 
 be
 
 faster than a memory scan :-)
 
 I haven't done any tests, but I would presume an SQL backend would be
 more 'robust' than freeradius.
 
 The way I see it, having 1 request a minute is definitely faster with a
 users file in memory, but when the load hits and you have 10,000 hits
 per minute, freeradius would grind to a halt having to look up the
 credentials and handling all NAS comms simultaneously, while freeradius
 + sql would just continue doing their respective jobs as normal.
 
  But as the same CPU would be working on the DB lookups AND the freeRADIUS
  code as well, it would slow down by a much larger factor.  You would now
  have 2 processes sharing the memory and CPU resources and bus of the
  system etc..
 
  Fact is Disk access is horribly slow compared to memory.
 
  Look at the spec of a fairly old (now) PC.. 100MHz FSB.. so thats around
  100,000,000*4 bytes per SECOND which is a tiny bit faster than a HDD
  don't you think.
 
  Just look at the clock speed of your PC.. even if the data wasn't indexed
  in memory and was searched in a linear manner it would still be extremely
  quick in comparison to a db.
 
  Graeme

 -
 List info/subscribe/unsubscribe? See
 http://www.freeradius.org/list/users.html

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

Well, if that is such a big problem then you can do a memory disk and 
store your db files in memory disk. That would then definetely work 
better than freeradius itself. How much are the memory prices now anyhow.

About the operating system stuff, the load of exchanging few messages in 
memory can not be so overwhelming compared to an inefficient search of a 
few hundred thousands of users from a text database even when its in 
memory already.

There so many programs running in background usually that I am sure that 
many programs trigger the kernel context switching already even when 
freeradius is searching from the users file. Now the point is if the 
search is faster then it would be interrupted less since it would take 
less time to finish. Thus using SQL would yet improve performance anyhow 
since the searches would take a lot less time.

Look at some statistics
http://cs.nmu.edu/~benchmark/index.php?page=context
The context switching occurs in microseconds. Lets try to calculate how 
many context switching operations can be done in a second? Needless to 
remind that a microsecond is 10^-6 of a second.

Then think about how much difference would it take to search 10
entries from users file in memory or in sql database. In which sql 
already optimize the data to be searched. Then find out how many context 
switching can be done in that much time :)

I am certainly uncertain about how much overhead it cause for freeradius 
to call to mysql and back but it can not be so much. Plus if you have 
10 users you do not want to reload the users file :) think about 
reading 10 users from the disk. Now is that more efficient? in every 
stupid reload. Then calculate the people who change their passwords or 
new customers coming and new accounts added.

You cant possible argue that using users file is faster. But perhaps the 
difference is so little when you have few thousand users that you can 
omit the difference.

Evren



Peter Nixon wrote:

On Tue August 5 2003 05:34, Evren Yurtesen wrote:

Thats totally wrong, so you say same cpu works on both db lookups and
freeradius, now when freeradius is making a lookup inside users file
which is in ram, the same cpu doesnt work on db lookups in memory or
what? so thats out of question.


I am sorry to tell you Evren, but you ARE wrong. Even if you forget for a 
moment the fact that a DB server has to fetch the data from the disk and 
FreeRadius does not, It is MUCH more efficient for FreeRadius to search it's 
own memory space than to ask another program to supply the data.

Asking another program (A DB server or any other program) even if that program 
already has the data in memory is very slow comparitively as it forces a 
kernel context switch to load the other program onto the CPU, then another 
context switch to load FreeRadius onto the CPU.

Put simply you are wrong. Please read up about CPU design and operating system 
context switches before argueing this any more.


but mysql is optimized for that kind of lookups, there is huge
difference. then again, you can increase the mysql memory cache that
mysql can cache the whole db inside the ram if it is small enough.


It is not. There is not. You are wrong. Even if you have the entire DB inside 
ram (which would nullify your point of using a DB instead of a client file to 
save on RAM usage) the CPU still has to switch the running context from FR - 
DB - FR which flushes all CPU caches and is very slow. not to mention the 
fact that there is TCP (or UNIX) socket overhead to slow things down. Of 
course there is also Parsing and reparsing of SQL statements  etc etc..


Now about searching in ram is better than using a database backend. I
wonder why companies do not store their database data in text files and
load them to ram :)


They do. Of course they do. It is always faster to load data at run time than 
look it up later. using a DB is easier/better for maintenence. It is NOT 
faster.


now the problem is that also everytime you reload
radius it reloads the whole file since it cant know where the changed
data is. Thus uses far more cpu. 


this ONLY happens at startup. how can it possibly use more CPU than requesting 
from disk for every query???!!!


It is definetely not a good thing if
you want your users to change their passwords from web, then you need to
write to users file and reload radius if you do not use sql.


Yes. As mentioned before. DB is good for easy maintenence, NOT speed.


If you use
sql you can create a user which can only change some parts of the
database and limit the access. It is even more secure when configured
properly. It is 100 times easier to write a php script which does that
than writing it in c or perl


We were argueing about speed, not other issues. DBs are good, but you are VERY 
wrong about them being faster than a memory search of the clients file..

If case you were wondering I maintain the postgresql configs and driver for 
FreeRadius, and run a DB backend

Re: Advantages of Using SQL ?

2003-08-04 Thread Steven Fries

Maybe you're both right? But who really wants to win a Who's the bigger nerd 
contest? If I have a small set of users, I'm using the flat file. But if my user list 
growsno doubt use SQL. The best thing for me is I don't have to write fancy text 
handlers to parse through the users file, I just use SQL statements.

So as far as speed, it's negligible either way. Separation of datanow that's where 
it's at..

Steven

You wrote:
 Well, if that is such a big problem then you can do a memory disk and 
 store your db files in memory disk. That would then definetely work 
 better than freeradius itself. How much are the memory prices now anyhow.
 About the operating system stuff, the load of exchanging few messages in 
 memory can not be so overwhelming compared to an inefficient search of a 
 few hundred thousands of users from a text database even when its in 
 memory already.
 There so many programs running in background usually that I am sure that 
 many programs trigger the kernel context switching already even when 
 freeradius is searching from the users file. Now the point is if the 
 search is faster then it would be interrupted less since it would take 
 less time to finish. Thus using SQL would yet improve performance anyhow 
 since the searches would take a lot less time.
 Look at some statistics
 http://cs.nmu.edu/~benchmark/index.php?page=context
 The context switching occurs in microseconds. Lets try to calculate how 
 many context switching operations can be done in a second? Needless to 
 remind that a microsecond is 10^-6 of a second.
 Then think about how much difference would it take to search 10
 entries from users file in memory or in sql database. In which sql 
 already optimize the data to be searched. Then find out how many context 
 switching can be done in that much time IMG SRC=/images/emoticon14.gif
 I am certainly uncertain about how much overhead it cause for freeradius 
 to call to mysql and back but it can not be so much. Plus if you have 
 10 users you do not want to reload the users file IMG 
 SRC=/images/emoticon14.gif think about 
 reading 10 users from the disk. Now is that more efficient? in every 
 stupid reload. Then calculate the people who change their passwords or 
 new customers coming and new accounts added.
 You cant possible argue that using users file is faster. But perhaps the 
 difference is so little when you have few thousand users that you can 
 omit the difference.
 Evren
 Peter Nixon wrote:
  On Tue August 5 2003 05:34, Evren Yurtesen wrote:
 
 Thats totally wrong, so you say same cpu works on both db lookups and
 freeradius, now when freeradius is making a lookup inside users file
 which is in ram, the same cpu doesnt work on db lookups in memory or
 what? so thats out of question.
  
  
  I am sorry to tell you Evren, but you ARE wrong. Even if you forget for a 
  moment the fact that a DB server has to fetch the data from the disk and 
  FreeRadius does not, It is MUCH more efficient for FreeRadius to search it's 
  own memory space than to ask another program to supply the data.
  
  Asking another program (A DB server or any other program) even if that 
 program 
  already has the data in memory is very slow comparitively as it forces a 
  kernel context switch to load the other program onto the CPU, then another 
  context switch to load FreeRadius onto the CPU.
  
  Put simply you are wrong. Please read up about CPU design and operating 
 system 
  context switches before argueing this any more.
  
 
 but mysql is optimized for that kind of lookups, there is huge
 difference. then again, you can increase the mysql memory cache that
 mysql can cache the whole db inside the ram if it is small enough.
  
  
  It is not. There is not. You are wrong. Even if you have the entire DB inside 
 
  ram (which would nullify your point of using a DB instead of a client file to 
 
  save on RAM usage) the CPU still has to switch the running context from FR - 
 
  DB - FR which flushes all CPU caches and is very slow. not to mention the 
  fact that there is TCP (or UNIX) socket overhead to slow things down. Of 
  course there is also Parsing and reparsing of SQL statements  etc etc..
  
 
 Now about searching in ram is better than using a database backend. I
 wonder why companies do not store their database data in text files and
 load them to ram IMG SRC=/images/emoticon14.gif
  
  
  They do. Of course they do. It is always faster to load data at run time than 
 
  look it up later. using a DB is easier/better for maintenence. It is NOT 
  faster.
  
 
 now the problem is that also everytime you reload
 radius it reloads the whole file since it cant know where the changed
 data is. Thus uses far more cpu.
  
  
  this ONLY happens at startup. how can it possibly use more CPU than 
 requesting 
  from disk for every query???!!!
  
 
 It is definetely not a good thing if
 you want your users to change their passwords from web, then you

Re: Advantages of Using SQL ?



And dont forget that the SQL solution will use hashed 
indexes, usually even if you don't define them. So yes, 
small database will be faster as a flat file loaded in 
memory, but big databases will normally be faster from SQL 
due to cacheing of the hash and the user data.

But then, maybe free radius hashes the user file, so in 
that case yes, loading a 10 GB user file into memory would 
be faster, but not particularly efficient or 
intelligent...



On Mon, 4 Aug 2003 12:34:34 -0500 (CDT)
 Steven Fries [EMAIL PROTECTED] wrote:
Maybe you're both right? But who really wants to win a 
Who's the bigger nerd contest? If I have a small set of 
users, I'm using the flat file. But if my user list 
growsno doubt use SQL. The best thing for me is I 
don't have to write fancy text handlers to parse through 
the users file, I just use SQL statements.

So as far as speed, it's negligible either way. 
Separation of datanow that's where it's at..

Steven

You wrote:
Well, if that is such a big problem then you can do a 
memory disk and 
store your db files in memory disk. That would then 
definetely work 
better than freeradius itself. How much are the memory 
prices now anyhow.
About the operating system stuff, the load of exchanging 
few messages in 
memory can not be so overwhelming compared to an 
inefficient search of a 
few hundred thousands of users from a text database even 
when its in 
memory already.
There so many programs running in background usually 
that I am sure that 
many programs trigger the kernel context switching 
already even when 
freeradius is searching from the users file. Now the 
point is if the 
search is faster then it would be interrupted less since 
it would take 
less time to finish. Thus using SQL would yet improve 
performance anyhow 
since the searches would take a lot less time.
Look at some statistics
http://cs.nmu.edu/~benchmark/index.php?page=context
The context switching occurs in microseconds. Lets try 
to calculate how 
many context switching operations can be done in a 
second? Needless to 
remind that a microsecond is 10^-6 of a second.
Then think about how much difference would it take to 
search 10
entries from users file in memory or in sql database. In 
which sql 
already optimize the data to be searched. Then find out 
how many context 
switching can be done in that much time IMG 
SRC=/images/emoticon14.gif
I am certainly uncertain about how much overhead it 
cause for freeradius 
to call to mysql and back but it can not be so much. 
Plus if you have 
10 users you do not want to reload the users file 
IMG SRC=/images/emoticon14.gif think about 
reading 10 users from the disk. Now is that more 
efficient? in every 
stupid reload. Then calculate the people who change 
their passwords or 
new customers coming and new accounts added.
You cant possible argue that using users file is faster. 
But perhaps the 
difference is so little when you have few thousand users 
that you can 
omit the difference.
Evren
Peter Nixon wrote:
 On Tue August 5 2003 05:34, Evren Yurtesen wrote:

Thats totally wrong, so you say same cpu works on both 
db lookups and
freeradius, now when freeradius is making a lookup 
inside users file
which is in ram, the same cpu doesnt work on db 
lookups in memory or
what? so thats out of question.
 
 
 I am sorry to tell you Evren, but you ARE wrong. Even 
if you forget for a 
 moment the fact that a DB server has to fetch the data 
from the disk and 
 FreeRadius does not, It is MUCH more efficient for 
FreeRadius to search it's 
 own memory space than to ask another program to supply 
the data.
 
 Asking another program (A DB server or any other 
program) even if that 
program 
 already has the data in memory is very slow 
comparitively as it forces a 
 kernel context switch to load the other program onto 
the CPU, then another 
 context switch to load FreeRadius onto the CPU.
 
 Put simply you are wrong. Please read up about CPU 
design and operating 
system 
 context switches before argueing this any more.
 

but mysql is optimized for that kind of lookups, there 
is huge
difference. then again, you can increase the mysql 
memory cache that
mysql can cache the whole db inside the ram if it is 
small enough.
 
 
 It is not. There is not. You are wrong. Even if you 
have the entire DB inside 

 ram (which would nullify your point of using a DB 
instead of a client file to 

 save on RAM usage) the CPU still has to switch the 
running context from FR - 

 DB - FR which flushes all CPU caches and is very 
slow. not to mention the 
 fact that there is TCP (or UNIX) socket overhead to 
slow things down. Of 
 course there is also Parsing and reparsing of SQL 
statements  etc etc..
 

Now about searching in ram is better than using a 
database backend. I
wonder why companies do not store their database data 
in text files and
load them to ram IMG SRC=/images/emoticon14.gif
 
 
 They do. Of course they do. It is always faster to

Re: Advantages of Using SQL ?

On Tue August 5 2003 06:37, Evren Yurtesen wrote:
 Well, if that is such a big problem then you can do a memory disk and
 store your db files in memory disk. That would then definetely work
 better than freeradius itself. How much are the memory prices now anyhow.

You could. This again uses more memory, which was one of the things you said 
you save by using a DB. You can't have it both ways.

 About the operating system stuff, the load of exchanging few messages in
 memory can not be so overwhelming compared to an inefficient search of a
 few hundred thousands of users from a text database even when its in
 memory already.

What is so inefficient about the search algorithm used by FreeRadius. (I have 
not looked currently) If is IS slow, then once again, we can simply use the 
efficient algorithm from MySQL instead of the one currently in use.

 There so many programs running in background usually that I am sure that
 many programs trigger the kernel context switching already even when
 freeradius is searching from the users file. Now the point is if the
 search is faster then it would be interrupted less since it would take
 less time to finish. Thus using SQL would yet improve performance anyhow
 since the searches would take a lot less time.

You are again basing your arguement on the hypothesis that FreeRadius uses an 
incredibly inefficient algorithm to search though memory. It would literally 
have to be several orders of magnitude slower than the search algorithm used 
by MySQL for them to be _even_ in terms of speed due to disk/context 
switch/socket/parsing overhead. I simply don't believe that this is the case.
If you show me a benchmark that proves this, I will shutup about it, but what 
you are saying currently just does not make sense. Even if it were true, it 
would be very simple to fix it (ie. Copy the algorithm that MySQL uses into 
FreeRadius).

 Look at some statistics
 http://cs.nmu.edu/~benchmark/index.php?page=context
 The context switching occurs in microseconds. Lets try to calculate how
 many context switching operations can be done in a second? Needless to
 remind that a microsecond is 10^-6 of a second.

 Then think about how much difference would it take to search 10
 entries from users file in memory or in sql database. In which sql
 already optimize the data to be searched. Then find out how many context
 switching can be done in that much time :)

 I am certainly uncertain about how much overhead it cause for freeradius
 to call to mysql and back but it can not be so much.

It is enough to make a difference :-)

 Plus if you have
 10 users you do not want to reload the users file :) think about
 reading 10 users from the disk. Now is that more efficient? in every
 stupid reload. Then calculate the people who change their passwords or
 new customers coming and new accounts added.

This is a seperate issue. We already agreed on this issue. I never told you 
otherwise.

 You cant possible argue that using users file is faster.

I can and I am. If you are willing to provide benchmarks that prove otherwise 
then I will agree that you are right. (And probably rewrite the search 
algorithm in FR to make it faster :-) Until that time, what you are saying 
goes against common sense.

Its like saying that example B is faster than example A in the following 
scenario:

A) You need to call your girlfriend. You know her number, so you dial it and 
talk to her.

B) You need to call your girlfriend, You don't know her number so you call 
your secretary and ask her to look it up in the phone book. Your secretary 
looks up the number, calls you back and give it to you, then you call your 
girlfriend.

Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the phone 
book has a great, wonderfully efficient index, and your secretary is very 
good at using it, doesn't mean that it's faster than having the number in 
your own head

 But perhaps the
 difference is so little when you have few thousand users that you can
 omit the difference.

 Evren

 Peter Nixon wrote:
  On Tue August 5 2003 05:34, Evren Yurtesen wrote:
 Thats totally wrong, so you say same cpu works on both db lookups and
 freeradius, now when freeradius is making a lookup inside users file
 which is in ram, the same cpu doesnt work on db lookups in memory or
 what? so thats out of question.
 
  I am sorry to tell you Evren, but you ARE wrong. Even if you forget for a
  moment the fact that a DB server has to fetch the data from the disk and
  FreeRadius does not, It is MUCH more efficient for FreeRadius to search
  it's own memory space than to ask another program to supply the data.
 
  Asking another program (A DB server or any other program) even if that
  program already has the data in memory is very slow comparitively as it
  forces a kernel context switch to load the other program onto the CPU,
  then another context switch to load FreeRadius onto the CPU.
 
  Put simply you are wrong. Please

Re: Advantages of Using SQL ?

2003-08-04 Thread Gregory G. V.

Hello
Do not forget fastuser
The fastusers works fats... And can fit a lot of users into the memory...
And if I remember correctly, uses hash.
And do not forget the radius task is almost a read-only task -= in a
normal environment you can not compare an amount of auth requests with an
amount of request to change a password... It's funny to hear - but users
want to be able to change their password! So what? they will sit and click
in broweser/etc to change their password so fast as cisco/whatever sends
requests for authentication? I guess user will much often need to be
authenticated, then to be able to change his passwd. IMHO. From what I
have seen.


 On 10:24pm, Peter Nixon wrote:

 On Tue August 5 2003 06:37, Evren Yurtesen wrote:
  Well, if that is such a big problem then you can do a memory disk and
  store your db files in memory disk. That would then definetely work
  better than freeradius itself. How much are the memory prices now anyhow.

 You could. This again uses more memory, which was one of the things you said
 you save by using a DB. You can't have it both ways.

  About the operating system stuff, the load of exchanging few messages in
  memory can not be so overwhelming compared to an inefficient search of a
  few hundred thousands of users from a text database even when its in
  memory already.

 What is so inefficient about the search algorithm used by FreeRadius. (I have
 not looked currently) If is IS slow, then once again, we can simply use the
 efficient algorithm from MySQL instead of the one currently in use.


Gregory G. V.
---
Any opinions in this posting are my own and not those of my present
or previous employers.

According Isham Research's Devil's IT Dictionary mainframe is:
an obsolete device still used by thousands of obsolete companies
serving billions of obsolete customers and making huge obsolete profits
for their obsolete shareholders.
And this year's run twice as fast as last year's.


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

RE: Advantages of Using SQL ?

2003-08-04 Thread Jeremy Davis

Killer analogy :)

Jeremy

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Peter Nixon
Sent: Monday, August 04, 2003 3:24 PM
To: [EMAIL PROTECTED]
Subject: Re: Advantages of Using SQL ?

On Tue August 5 2003 06:37, Evren Yurtesen wrote:
 Well, if that is such a big problem then you can do a memory disk and
 store your db files in memory disk. That would then definetely work
 better than freeradius itself. How much are the memory prices now anyhow.

You could. This again uses more memory, which was one of the things you said
you save by using a DB. You can't have it both ways.

 About the operating system stuff, the load of exchanging few messages in
 memory can not be so overwhelming compared to an inefficient search of a
 few hundred thousands of users from a text database even when its in
 memory already.

What is so inefficient about the search algorithm used by FreeRadius. (I
have
not looked currently) If is IS slow, then once again, we can simply use the
efficient algorithm from MySQL instead of the one currently in use.

 There so many programs running in background usually that I am sure that
 many programs trigger the kernel context switching already even when
 freeradius is searching from the users file. Now the point is if the
 search is faster then it would be interrupted less since it would take
 less time to finish. Thus using SQL would yet improve performance anyhow
 since the searches would take a lot less time.

You are again basing your arguement on the hypothesis that FreeRadius uses
an
incredibly inefficient algorithm to search though memory. It would literally
have to be several orders of magnitude slower than the search algorithm used
by MySQL for them to be _even_ in terms of speed due to disk/context
switch/socket/parsing overhead. I simply don't believe that this is the
case.
If you show me a benchmark that proves this, I will shutup about it, but
what
you are saying currently just does not make sense. Even if it were true, it
would be very simple to fix it (ie. Copy the algorithm that MySQL uses into
FreeRadius).

 Look at some statistics
 http://cs.nmu.edu/~benchmark/index.php?page=context
 The context switching occurs in microseconds. Lets try to calculate how
 many context switching operations can be done in a second? Needless to
 remind that a microsecond is 10^-6 of a second.

 Then think about how much difference would it take to search 10
 entries from users file in memory or in sql database. In which sql
 already optimize the data to be searched. Then find out how many context
 switching can be done in that much time :)

 I am certainly uncertain about how much overhead it cause for freeradius
 to call to mysql and back but it can not be so much.

It is enough to make a difference :-)

 Plus if you have
 10 users you do not want to reload the users file :) think about
 reading 10 users from the disk. Now is that more efficient? in every
 stupid reload. Then calculate the people who change their passwords or
 new customers coming and new accounts added.

This is a seperate issue. We already agreed on this issue. I never told you
otherwise.

 You cant possible argue that using users file is faster.

I can and I am. If you are willing to provide benchmarks that prove
otherwise
then I will agree that you are right. (And probably rewrite the search
algorithm in FR to make it faster :-) Until that time, what you are saying
goes against common sense.

Its like saying that example B is faster than example A in the following
scenario:

A) You need to call your girlfriend. You know her number, so you dial it and
talk to her.

B) You need to call your girlfriend, You don't know her number so you call
your secretary and ask her to look it up in the phone book. Your secretary
looks up the number, calls you back and give it to you, then you call your
girlfriend.

Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the phone
book has a great, wonderfully efficient index, and your secretary is very
good at using it, doesn't mean that it's faster than having the number in
your own head

 But perhaps the
 difference is so little when you have few thousand users that you can
 omit the difference.

 Evren

 Peter Nixon wrote:
  On Tue August 5 2003 05:34, Evren Yurtesen wrote:
 Thats totally wrong, so you say same cpu works on both db lookups and
 freeradius, now when freeradius is making a lookup inside users file
 which is in ram, the same cpu doesnt work on db lookups in memory or
 what? so thats out of question.

  I am sorry to tell you Evren, but you ARE wrong. Even if you forget for
a
  moment the fact that a DB server has to fetch the data from the disk and
  FreeRadius does not, It is MUCH more efficient for FreeRadius to search
  it's own memory space than to ask another program to supply the data.

  Asking another program (A DB server or any other program) even if that
  program already has the data in memory

Re: Advantages of Using SQL ?

On Mon August 4 2003 20:34, Steven Fries wrote:
 Maybe you're both right? But who really wants to win a Who's the bigger
 nerd contest? If I have a small set of users, I'm using the flat file. But
 if my user list growsno doubt use SQL. The best thing for me is I don't
 have to write fancy text handlers to parse through the users file, I just
 use SQL statements.

Yes

 So as far as speed, it's negligible either way. Separation of datanow
 that's where it's at..

Yes.

You are right in both instances, but we were arguing speed. If you read my 
initial email on this thread you will see that I said that asking a backend 
for information will be _slower_ than consulting an in memory list. Slower is 
a relative term.  never said it was too slow and I never said that you 
should not use a DB because of it. I simply argued that if you pick a DB 
backend that you do it for the right reasons. Speed is not one of them. You 
can argue ram disks, or separate servers until you are blue in the face, but 
on identical hardware, especially if it is memory constrained standalone 
FreeRdius should be quicker.

This is the mailing list for an Open Source project. Argueing about how one 
fast one implimentation or another is is definately on topic. If we get 
better code, or better documentation of even a better understanding of how 
things work out of the discussion thats great..

-- 

Peter Nixon
http://www.peternixon.net/
PGP Key: http://www.peternixon.net/public.asc


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

Ok lets make peace :)
Everybody argue about something and usually its so difficult to come to 
a conclusion. Microsoft says windows is good, linux people say linux is 
better, I say FreeBSD is best :)

Anyhow the hardware is so fast and cheap nowadays that we dont need to 
be so efficient :) It is better to install things the most productive 
way. Usually it is enough...

By the way I would like to finish this with something which I think funny:

I just remembered something when I thought about efficient.
Microsoft always says the newer version of windows works faster and more 
efficiently etc. But yet they require faster cpu's and more memory in 
their system requirements :) When we leave the memory out, I wonder why 
a more efficient system require faster cpu :) there is a problem in this
equation :)

Evren

Peter Nixon wrote:

On Tue August 5 2003 06:37, Evren Yurtesen wrote:

Well, if that is such a big problem then you can do a memory disk and
store your db files in memory disk. That would then definetely work
better than freeradius itself. How much are the memory prices now anyhow.


You could. This again uses more memory, which was one of the things you said 
you save by using a DB. You can't have it both ways.


About the operating system stuff, the load of exchanging few messages in
memory can not be so overwhelming compared to an inefficient search of a
few hundred thousands of users from a text database even when its in
memory already.


What is so inefficient about the search algorithm used by FreeRadius. (I have 
not looked currently) If is IS slow, then once again, we can simply use the 
efficient algorithm from MySQL instead of the one currently in use.


There so many programs running in background usually that I am sure that
many programs trigger the kernel context switching already even when
freeradius is searching from the users file. Now the point is if the
search is faster then it would be interrupted less since it would take
less time to finish. Thus using SQL would yet improve performance anyhow
since the searches would take a lot less time.


You are again basing your arguement on the hypothesis that FreeRadius uses an 
incredibly inefficient algorithm to search though memory. It would literally 
have to be several orders of magnitude slower than the search algorithm used 
by MySQL for them to be _even_ in terms of speed due to disk/context 
switch/socket/parsing overhead. I simply don't believe that this is the case.
If you show me a benchmark that proves this, I will shutup about it, but what 
you are saying currently just does not make sense. Even if it were true, it 
would be very simple to fix it (ie. Copy the algorithm that MySQL uses into 
FreeRadius).


Look at some statistics
http://cs.nmu.edu/~benchmark/index.php?page=context
The context switching occurs in microseconds. Lets try to calculate how
many context switching operations can be done in a second? Needless to
remind that a microsecond is 10^-6 of a second.
Then think about how much difference would it take to search 10
entries from users file in memory or in sql database. In which sql
already optimize the data to be searched. Then find out how many context
switching can be done in that much time :)
I am certainly uncertain about how much overhead it cause for freeradius
to call to mysql and back but it can not be so much.


It is enough to make a difference :-)


Plus if you have
10 users you do not want to reload the users file :) think about
reading 10 users from the disk. Now is that more efficient? in every
stupid reload. Then calculate the people who change their passwords or
new customers coming and new accounts added.


This is a seperate issue. We already agreed on this issue. I never told you 
otherwise.


You cant possible argue that using users file is faster.


I can and I am. If you are willing to provide benchmarks that prove otherwise 
then I will agree that you are right. (And probably rewrite the search 
algorithm in FR to make it faster :-) Until that time, what you are saying 
goes against common sense.

Its like saying that example B is faster than example A in the following 
scenario:

A) You need to call your girlfriend. You know her number, so you dial it and 
talk to her.

B) You need to call your girlfriend, You don't know her number so you call 
your secretary and ask her to look it up in the phone book. Your secretary 
looks up the number, calls you back and give it to you, then you call your 
girlfriend.

Which do you thing is faster?? Bzzzt. WRONG ANSWER. Just because the phone 
book has a great, wonderfully efficient index, and your secretary is very 
good at using it, doesn't mean that it's faster than having the number in 
your own head


But perhaps the
difference is so little when you have few thousand users that you can
omit the difference.
Evren

Peter Nixon wrote:

On Tue August 5 2003 05:34, Evren Yurtesen wrote:

Thats totally wrong, so you say same cpu works

Re: Advantages of Using SQL ?

2003-08-04 Thread Steven Fries

I'm still confused why you're arguing over this...It's implemented both ways for a 
reason I assume. So if the flat file is so great, why even bother with SQL 
code? AH! Choice! Kudos to the dev team.

You wrote:
 On Mon August 4 2003 20:34, Steven Fries wrote:
  Maybe you're both right? But who really wants to win a Who's the bigger
  nerd contest? If I have a small set of users, I'm using the flat file. But
  if my user list growsno doubt use SQL. The best thing for me is I don't
  have to write fancy text handlers to parse through the users file, I just
  use SQL statements.
 Yes
  So as far as speed, it's negligible either way. Separation of datanow
  that's where it's at..
 Yes.
 You are right in both instances, but we were arguing speed. If you read my 
 initial email on this thread you will see that I said that asking a backend 
 for information will be _slower_ than consulting an in memory list. Slower is 
 a relative term.  never said it was too slow and I never said that you 
 should not use a DB because of it. I simply argued that if you pick a DB 
 backend that you do it for the right reasons. Speed is not one of them. You 
 can argue ram disks, or separate servers until you are blue in the face, but 
 on identical hardware, especially if it is memory constrained standalone 
 FreeRdius should be quicker.
 This is the mailing list for an Open Source project. Argueing about how one 
 fast one implimentation or another is is definately on topic. If we get 
 better code, or better documentation of even a better understanding of how 
 things work out of the discussion thats great..
 -- 
 Peter Nixon
 http://www.peternixon.net/
 PGP Key: http://www.peternixon.net/public.asc
 - 
 List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

--

Re: Advantages of Using SQL ?

2003-08-04 Thread Matthew Schumacher

Sometimes this comes down to what you need it to do.  I need a 
centralized user database platform wide so LDAP was the obvious choice 
so I ran that with detail accounting for a while but then I needed to do 
some bit counting and I also needed to calculate usage for the users. 
When it comes to this it is MUCH faster and easier to work with the 
database.  Now I just ask the database for the the usage instead of 
trying to parse a huge text log.

schu

Evren Yurtesen wrote:
Ok lets make peace :)
Everybody argue about something and usually its so difficult to come to 
a conclusion. Microsoft says windows is good, linux people say linux is 
better, I say FreeBSD is best :)

Anyhow the hardware is so fast and cheap nowadays that we dont need to 
be so efficient :) It is better to install things the most productive 
way. Usually it is enough...

By the way I would like to finish this with something which I think funny:

I just remembered something when I thought about efficient.
Microsoft always says the newer version of windows works faster and more 
efficiently etc. But yet they require faster cpu's and more memory in 
their system requirements :) When we leave the memory out, I wonder why 
a more efficient system require faster cpu :) there is a problem in this
equation :)

Evren



- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

2003-08-04 Thread Alan DeKok

Evren Yurtesen [EMAIL PROTECTED] wrote:
 Everybody argue about something and usually its so difficult to come to 
 a conclusion. Microsoft says windows is good, linux people say linux is 
 better, I say FreeBSD is best :)

  NetBSD...

 Microsoft always says the newer version of windows works faster and more 
 efficiently etc. But yet they require faster cpu's and more memory in 
 their system requirements :) When we leave the memory out, I wonder why 
 a more efficient system require faster cpu :) there is a problem in this
 equation :)

  At work, we run CPU and memory intensive applications.  On the same
hardward, the relative speed of our apps on the various OS's, relative
to NetBSD, are:

NetBSD: 1.0
Linux : 0.6
XP: 0.2
NT4   : 0.1

  So I agree, XP is twice as good as NT4. :)

  Alan DeKok.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

My testing confirms Alan's numbers, however he neglected 
to mention:

Solaris: 2.5
VMS on Alpha: 8.0  :)


On Mon, 04 Aug 2003 16:07:58 -0400
 Alan DeKok [EMAIL PROTECTED] wrote:
Evren Yurtesen [EMAIL PROTECTED] wrote:
Everybody argue about something and usually its so 
difficult to come to 
a conclusion. Microsoft says windows is good, linux 
people say linux is 
better, I say FreeBSD is best :)
  NetBSD...

Microsoft always says the newer version of windows works 
faster and more 
efficiently etc. But yet they require faster cpu's and 
more memory in 
their system requirements :) When we leave the memory 
out, I wonder why 
a more efficient system require faster cpu :) there is a 
problem in this
equation :)
  At work, we run CPU and memory intensive applications. 
On the same
hardward, the relative speed of our apps on the various 
OS's, relative
to NetBSD, are:

NetBSD: 1.0
Linux : 0.6
XP: 0.2
NT4   : 0.1
  So I agree, XP is twice as good as NT4. :)

  Alan DeKok.

- 
List info/subscribe/unsubscribe? See 
http://www.freeradius.org/list/users.html


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

How do you test this? or joke? :)
I would like to keep record of my server performances relative to each 
other too, it sounds like a cool idea

Evren

Tim McCracken wrote:

My testing confirms Alan's numbers, however he neglected to mention:

Solaris: 2.5
VMS on Alpha: 8.0  :)


On Mon, 04 Aug 2003 16:07:58 -0400
 Alan DeKok [EMAIL PROTECTED] wrote:
Evren Yurtesen [EMAIL PROTECTED] wrote:

Everybody argue about something and usually its so difficult to come 
to a conclusion. Microsoft says windows is good, linux people say 
linux is better, I say FreeBSD is best :)


  NetBSD...

Microsoft always says the newer version of windows works faster and 
more efficiently etc. But yet they require faster cpu's and more 
memory in their system requirements :) When we leave the memory out, 
I wonder why a more efficient system require faster cpu :) there is a 
problem in this
equation :)


  At work, we run CPU and memory intensive applications. On the same
hardward, the relative speed of our apps on the various OS's, relative
to NetBSD, are:
NetBSD: 1.0
Linux : 0.6
XP: 0.2
NT4   : 0.1
  So I agree, XP is twice as good as NT4. :)

  Alan DeKok.

- List info/subscribe/unsubscribe? See 
http://www.freeradius.org/list/users.html


- List info/subscribe/unsubscribe? See 
http://www.freeradius.org/list/users.html


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

My numbers (atleast) were a joke. The reality of it is 
(IMHO) that benchmarks are only useful to marketing 
departments because they are rarely done in an equitable 
manner. There are way too many differences to benchmark 
accross hardware platforms, and rarely does anyone tune OS 
parameters to make benchmarks meaningful on different OSs 
using the same hardware.

I use Win2K and Solaris and XP extensively. IMHO, each has 
an efficient kernel. All will run the following program 
very fast:

while(1)



Tim

On Mon, 04 Aug 2003 23:37:42 -0700
 Evren Yurtesen [EMAIL PROTECTED] wrote:
How do you test this? or joke? :)
I would like to keep record of my server performances 
relative to each other too, it sounds like a cool idea

Evren

Tim McCracken wrote:

My testing confirms Alan's numbers, however he neglected 
to mention:

Solaris: 2.5
VMS on Alpha: 8.0  :)


On Mon, 04 Aug 2003 16:07:58 -0400
Alan DeKok [EMAIL PROTECTED] wrote:
Evren Yurtesen [EMAIL PROTECTED] wrote:

Everybody argue about something and usually its so 
difficult to come 
to a conclusion. Microsoft says windows is good, linux 
people say 
linux is better, I say FreeBSD is best :)


 NetBSD...

Microsoft always says the newer version of windows works 
faster and 
more efficiently etc. But yet they require faster cpu's 
and more 
memory in their system requirements :) When we leave the 
memory out, 
I wonder why a more efficient system require faster cpu 
:) there is a 
problem in this
equation :)


 At work, we run CPU and memory intensive applications. 
On the same
hardward, the relative speed of our apps on the various 
OS's, relative
to NetBSD, are:

NetBSD: 1.0
Linux : 0.6
XP: 0.2
NT4   : 0.1
 So I agree, XP is twice as good as NT4. :)

 Alan DeKok.

- List info/subscribe/unsubscribe? See 
http://www.freeradius.org/list/users.html


- List info/subscribe/unsubscribe? See 
http://www.freeradius.org/list/users.html


- 
List info/subscribe/unsubscribe? See 
http://www.freeradius.org/list/users.html


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?

My numbers (atleast) were a joke. The reality of it is 
(IMHO) that benchmarks are only useful to marketing 
departments because they are rarely done in an equitable 
manner. There are way too many differences to benchmark 
accross hardware platforms, and rarely does anyone tune OS 
parameters to make benchmarks meaningful on different OSs 
using the same hardware.

I use Win2K and Solaris and XP extensively. IMHO, each has 
an efficient kernel. All will run the following program 
very fast:

while(1)



Tim

On Mon, 04 Aug 2003 23:37:42 -0700
 Evren Yurtesen [EMAIL PROTECTED] wrote:
How do you test this? or joke? :)
I would like to keep record of my server performances 
relative to each other too, it sounds like a cool idea

Evren

Tim McCracken wrote:

My testing confirms Alan's numbers, however he neglected 
to mention:

Solaris: 2.5
VMS on Alpha: 8.0  :)


On Mon, 04 Aug 2003 16:07:58 -0400
Alan DeKok [EMAIL PROTECTED] wrote:
Evren Yurtesen [EMAIL PROTECTED] wrote:

Everybody argue about something and usually its so 
difficult to come 
to a conclusion. Microsoft says windows is good, linux 
people say 
linux is better, I say FreeBSD is best :)


 NetBSD...

Microsoft always says the newer version of windows works 
faster and 
more efficiently etc. But yet they require faster cpu's 
and more 
memory in their system requirements :) When we leave the 
memory out, 
I wonder why a more efficient system require faster cpu 
:) there is a 
problem in this
equation :)


 At work, we run CPU and memory intensive applications. 
On the same
hardward, the relative speed of our apps on the various 
OS's, relative
to NetBSD, are:

NetBSD: 1.0
Linux : 0.6
XP: 0.2
NT4   : 0.1
 So I agree, XP is twice as good as NT4. :)

 Alan DeKok.

- List info/subscribe/unsubscribe? See 
http://www.freeradius.org/list/users.html


- List info/subscribe/unsubscribe? See 
http://www.freeradius.org/list/users.html


- 
List info/subscribe/unsubscribe? See 
http://www.freeradius.org/list/users.html


- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Re: Advantages of Using SQL ?