Hi!
> On 03 May 2001 09:13:00 +0200,
> [EMAIL PROTECTED] (Kai Henningsen) wrote:
> >[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in
><[EMAIL PROTECTED]>:
> >
> >> PS: Hmm, how do you do timewarp for just one userland appliation with
> >> this installed?
> >
> >1. What on earth for?
>
>
Hi!
> > > PS: Hmm, how do you do timewarp for just one userland appliation with
> > > this installed?
> >
> > 1. What on earth for?
>
> Y2K testing was one previous example.
>
> > 2. How do you do it today, and why wouldn't that work?
>
> LD_PRELOAD and providing its still using a lib call it
Hi!
> > That means that for fooling closed-source statically-linked binary,
> > you now need to patch kernel. That's regression; subterfugue.org could
> > do this with normal user rights in 2.4.0.
>
> This is particularly pretty, but something that might work:
>
> 1. a "deceiver" process create
Hello,
I have uploaded a new release of X15 that hopefully solves all the RFC bugs.
I say hopefully because I haven't had the opportunity to fully test the
request pipelining. Is there anything to automatize such tests?
>From what I could measure X15 is still a good 5% faster than TUX.
You can
On 04-May-2001 Fabio Riccardi wrote:
> ok, I'm totally ignorant here, what is a pipelined request?
http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html
A pipelined application implementation buffers its output before writing it to
the underlying TCP stack, roughly equivalent to what th
ok, I'm totally ignorant here, what is a pipelined request?
btw: please be kind with my mistakes, X15 _is_ alpha code anyway... :)
- Fabio
Ingo Molnar wrote:
> yet another anomaly i noticed. X15 does not appear to handle pipelined
> HTTP/1.1 requests properly, it ignores the second request if
um, presumably this new magic page won't eliminate the old syscall entry
points. so just use those for UML.
-dean
On Fri, 4 May 2001, Pavel Machek wrote:
> Hi!
>
> > > > That means that for fooling closed-source statically-linked binary,
> > >
> > > If they are using glibc then you have the ri
yet another anomaly i noticed. X15 does not appear to handle pipelined
HTTP/1.1 requests properly, it ignores the second request if two requests
arrive in the same packet.
SPECweb99 does not send pipelined requests, but a number of RL web clients
do. (Mozilla, apt-get, etc.)
Ingo
-
To
On Thu, May 03, 2001 at 09:19:15PM +0100, Alan Cox wrote:
> If they are using glibc then you have the right to the object to link
> with the library and the library source under the LGPL. I dont know of any
> app using its own C lib
qmail is nearly there.
--
http://www.PowerDNS.com Versat
Hi!
> > > That means that for fooling closed-source statically-linked binary,
> >
> > If they are using glibc then you have the right to the object to link
> > with the library and the library source under the LGPL. I dont know of any
> > app using its own C lib
>
> Some don't use any libc at a
I have fixed the stale header cache problem. Files are statted on every
request, no "practical" tricks.
Performance doesn't seem to have suffered :)
I also have added a cache garbage collector to close "old" file descriptors
and remove even older header cache entries. This should make sure that
On Thu, May 03, 2001 at 09:19:15PM +0100, Alan Cox wrote:
> > That means that for fooling closed-source statically-linked binary,
>
> If they are using glibc then you have the right to the object to link
> with the library and the library source under the LGPL. I dont know of any
> app using its
> That means that for fooling closed-source statically-linked binary,
If they are using glibc then you have the right to the object to link
with the library and the library source under the LGPL. I dont know of any
app using its own C lib
>
-
To unsubscribe from this list: send the line "unsub
On Thu, 3 May 2001, Pavel Machek wrote:
> That means that for fooling closed-source statically-linked binary,
> you now need to patch kernel. That's regression; subterfugue.org could
> do this with normal user rights in 2.4.0.
This is particularly pretty, but something that might work:
1. a "de
Hi!
> > > > Whatever happened to that hack that was discussed a year or two ago?
> > > > The one where (also on IA32) a magic page was set up by the kernel
> > > > containing code for fast system calls, and the kernel would write
> > > > calibation information to that magic page. The code written
On Thu, May 03, 2001 at 05:44:36PM +1000, Keith Owens wrote:
> On 03 May 2001 09:13:00 +0200,
> [EMAIL PROTECTED] (Kai Henningsen) wrote:
> >[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in
><[EMAIL PROTECTED]>:
> >
> >> PS: Hmm, how do you do timewarp for just one userland appliation with
Pavel Machek wrote:
> > >
> > > Whatever happened to that hack that was discussed a year or two ago?
> > > The one where (also on IA32) a magic page was set up by the kernel
> > > containing code for fast system calls, and the kernel would write
> > > calibation information to that magic page. The
On Thu, May 03, 2001 at 05:44:36PM +1000, Keith Owens wrote:
> >2. How do you do it today, and why wouldn't that work?
>
> LD_PRELOAD on a library that overrides gettimeofday(). I can see no
> reason why that would not continue to work.
Static linkage?
> What would stop working
> are timewarp
> > PS: Hmm, how do you do timewarp for just one userland appliation with
> > this installed?
>
> 1. What on earth for?
Y2K testing was one previous example.
> 2. How do you do it today, and why wouldn't that work?
LD_PRELOAD and providing its still using a lib call it would. I dont see the
or
On 03 May 2001 09:13:00 +0200,
[EMAIL PROTECTED] (Kai Henningsen) wrote:
>[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in <[EMAIL PROTECTED]>:
>
>> PS: Hmm, how do you do timewarp for just one userland appliation with
>> this installed?
>
>1. What on earth for?
Y10K testing :)
>2. How do
[EMAIL PROTECTED] (Pavel Machek) wrote on 30.04.01 in <[EMAIL PROTECTED]>:
> PS: Hmm, how do you do timewarp for just one userland appliation with
> this installed?
1. What on earth for?
2. How do you do it today, and why wouldn't that work?
MfG Kai
-
To unsubscribe from this list: send the
Our intention is to release X15 with an open source license.
This will happen as soon as the codebase stabilizes a bit, that is when we go
beta (in two - three weeks).
At the moment we just don't have the time...
The reason why I released the alpha binary version is that several people
would no
Hi,
At 10:50 AM 2/05/2001 +0200, Ingo Molnar wrote:
>i think Zach's phhttpd is an important milestone as well, it's the first
>userspace webserver that shows how to use event-based, sigio-based async
>networking IO and sendfile() under Linux. (I believe it had some
>performance problems related t
>From my experience system calls are not an issue.
What costs a lot is moving data around, since modern CPUs spend most of their
time in memory/bus wait cycles...
- Fabio
Linus Torvalds wrote:
> >I think that applies to all really high-performance servers.
>
> Note that it is definitely not a
In article <[EMAIL PROTECTED]>,
Matti Aarnio <[EMAIL PROTECTED]> wrote:
>On Sun, Apr 29, 2001 at 02:16:43PM -0700, Jim Gettys wrote:
>...
>> "X is an exercise in avoiding system calls". I think I said this around
>> 1984-1985.
>> - Jim
>
>I think that applies to al
On Sun, Apr 29, 2001 at 02:16:43PM -0700, Jim Gettys wrote:
...
> "X is an exercise in avoiding system calls". I think I said this around
> 1984-1985.
> - Jim
I think that applies to all really high-performance servers.
Definitely it applies to ZMailer, which bef
> i think Zach's phhttpd is an important milestone as well, it's the first
> userspace webserver that shows how to use event-based, sigio-based async
> networking IO and sendfile() under Linux. (I believe it had some
*blush*
> performance problems related to sigio queue overflow, these issues mi
On Wed, 2 May 2001, Andi Kleen wrote:
> > Whatever happened to that hack that was discussed a year or two ago?
> > The one where (also on IA32) a magic page was set up by the kernel
> > containing code for fast system calls, and the kernel would write
> > calibation information to that magic pag
[sorry for the late answer -- i was involuntarily offline for a few days]
On Sat, Apr 28, 2001 at 04:56:27PM -0600, Richard Gooch wrote:
> Whatever happened to that hack that was discussed a year or two ago?
> The one where (also on IA32) a magic page was set up by the kernel
> containing code fo
On Sun, 29 Apr 2001, Fabio Riccardi wrote:
> TUX has definitively been my performance yardstick for the development
> of X15, but I had many sources of inspiration for the X15
> architecture. Maybe the most relevant are the Flash Web Server (Pai,
> Druschel, Zwaenepoel), several Linus observatio
On Tue, 1 May 2001, Fabio Riccardi wrote:
> This is actually a bug in the current X15, I know how to fix it (with
> negligible overhead) but I've been lazy :)
yep, i think it's pretty straightforward: you have a cache of open file
descriptors (like Squid i think), and you can start a background
This is actually a bug in the current X15, I know how to fix it (with
negligible overhead) but I've been lazy :)
give me a few days...
- Fabio
Ingo Molnar wrote:
> hm, another X15 caching artifact i noticed: i've changed the index.html
> file, and while X15 was still serving the old copy, TUX
Hi!
> > > In x86-64 there are special vsyscalls btw to solve this problem that export
> > > a lockless kernel gettimeofday()
> >
> > Whatever happened to that hack that was discussed a year or two ago?
> > The one where (also on IA32) a magic page was set up by the kernel
> > containing code for
hm, another X15 caching artifact i noticed: i've changed the index.html
file, and while X15 was still serving the old copy, TUX served the new
file immediately.
its cache is apparently not coherent with actual VFS contents. (ie. it's a
read-once cache apparently?) TUX has some (occasionally sign
On Mon, 30 Apr 2001, Fabio Riccardi wrote:
> Ok I fixed it, the header date timestamp is updated with every
> request.
>
> Performance doesn't seem to have suffered significantly (less than
> 1%).
yep, expected that - doing a sendmsg()+sendfile() generates the same
packet structure, the only di
On Sun, 29 Apr 2001, Fabio Riccardi wrote:
> I can disable header caching and see what happens, I'll add an option
> for this in the next X15 release.
what SPECweb99 performance do you get if you disable header caching? It
might not make all that much of a difference. (but it will make the
resu
dean gaudet writes:
> On Sun, 29 Apr 2001, David S. Miller wrote:
>
> > If you do the TCP_CORK thing, what you end up with is a scatter gather
> > entry in the SKB for the header bits, then the page cache segments.
>
> so then the NIC would be sent a 3 entry gather list -- 1 entry for TCP
On Mon, 30 Apr 2001, Fabio Riccardi wrote:
> Ok I fixed it, the header date timestamp is updated with every request.
>
> Performance doesn't seem to have suffered significantly (less than 1%).
rad!
> BTW: Don't call me slime, I wasn't trying to cheat, I just didn't know that
> the date stamp wa
Ok I fixed it, the header date timestamp is updated with every request.
Performance doesn't seem to have suffered significantly (less than 1%).
You can find the new release at: http://www.chromium.com/X15-Alpha-2.tgz
BTW: Don't call me slime, I wasn't trying to cheat, I just didn't know that
t
> The point is: The code in that "magic page" that considers the
> tradeoff is KERNEL code, which is designed to care about such
> trade-offs for that machine. Glibc never knows this stuff and
> shouldn't, because it is already bloated.
glibc is bloated because it cares about such stuff and compl
At 12:29 AM -0700 2001-04-30, H. Peter Anvin wrote:
>"David S. Miller" wrote:
>>
>> dean gaudet writes:
>> > i was kind of solving a different problem with the code page
>>though -- the
>> > ability to use rdtsc on SMP boxes with processors of varying speeds and
>> > synchronizations.
>>
>
H. Peter Anvin writes:
> RDTSC in Crusoe processors does basically this.
Hmmm, one of the advantages of using a seperate tick register for this
constant clock is that you can still do cycle accurate asm code
analysis even when the cpu is down clocked.
The joys of compatability I suppose :-)
L
"David S. Miller" wrote:
>
> dean gaudet writes:
> > i was kind of solving a different problem with the code page though -- the
> > ability to use rdtsc on SMP boxes with processors of varying speeds and
> > synchronizations.
>
> A better way to solve that problem is the way UltraSPARC-III do
dean gaudet writes:
> i was kind of solving a different problem with the code page though -- the
> ability to use rdtsc on SMP boxes with processors of varying speeds and
> synchronizations.
A better way to solve that problem is the way UltraSPARC-III do and
future ia64 systems will, by way o
dean gaudet writes:
> is this too slow for some reason? (does it play well with zero-copy?)
His trick ends up with a minimal set of scatter gather entries.
That's the whole gain behind the trick he's doing.
If you do the TCP_CORK thing, what you end up with is a scatter gather
entry in the SK
On Sun, 29 Apr 2001, Fabio Riccardi wrote:
> I can disable header caching and see what happens, I'll add an option
> for this in the next X15 release.
heh, well to be honest, i'd put the (permanent) caching of the Date header
into the very slimy, benchmark-only trick category. (right up there
a
On Sun, Apr 29, 2001 at 04:18:27PM -0400, Gregory Maxwell wrote:
> having both the code and a comprehensive jump-table might become tough in a
In the x86-64 implementation there's no jump table. The original design
had a jump table but Peter raised the issue that indirect jumps are very
costly an
On Sun, Apr 29, 2001 at 09:38:04PM +0200, Jamie Lokier wrote:
> Fwiw, modern x86 has global TLB entries too.
my x86-64 implementation is marking the tlb entry global of course (so
it's not flushed during context switch):
#define __PAGE_KERNEL_VSYSCALL \
(_PAGE_PRESENT | _PAGE_USER | _PAG
H. Peter Anvin writes:
> The thing that made me say we discussed this last month was
> Richard's comment that it had already been implemented (which it
> has, by Andrea, for x86-64.) The idea of doing it for i386 has been
> kicked around for
Correction: I didn't say it had been implemented. I ju
Gregory Maxwell writes:
> On Sun, Apr 29, 2001 at 10:11:59PM +0200, Ingo Oeser wrote:
> [snip]
> > The point is: The code in that "magic page" that considers the
> > tradeoff is KERNEL code, which is designed to care about such
> > trade-offs for that machine. Glibc never knows this stuff and
> >
Ingo Oeser writes:
> On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> > Ingo Oeser writes:
> > > There we have 10x faster memmove/memcpy/bzero for 1K blocks
> > > granularity (== alignment is 1K and size is multiple of 1K), that
> > > is done by the memory controller.
> > This soun
>
> Short summary: depending on how much you were talking general idea versus
> specifics, you can go arbitrarily far back (I wouldn't be surprised if
> shared memory techniques were used regularly before memory protection.)
>
> Fair?
Very fair.
>
> Not to pick on you or anyone else, but it
Jim Gettys wrote:
>
> The "put the time into a magic location in shared memory" goes back...
>
Short summary: depending on how much you were talking general idea versus
specifics, you can go arbitrarily far back (I wouldn't be surprised if
shared memory techniques were used regularly before memo
I can disable header caching and see what happens, I'll add an option for this
in the next X15 release.
Nevertheless I don't know how much this is interesting in real life, since on
the internet most static pages are cached on proxies. I agree that the
RFC asks for a date for the original respons
The "put the time into a magic location in shared memory" goes back, as
far as I know, to Bob Scheifler or myself for the X Window System, sometime
around 1984 or 1985: we put it into a page of shared memory where we used
a circular buffer scheme to put input events (keyboard/mice), so that
we cou
Linux 2.4 is surely one of the most advanced OSs ever happened, especially
from the optimization point of view and for the admirable economy of concepts
on which it lies. I definitively hope that X15 helps reinforcing the success
to this amazing system.
TUX has definitively been my performance ya
In article <[EMAIL PROTECTED]> you wrote:
> Yes, but we currently have more than 10K cycles for doing
> memset of a page.
make that 3800 or so. (700 Mhz AMD Duron)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More maj
Followup to: <[EMAIL PROTECTED]>
By author:dean gaudet <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> On Sun, 29 Apr 2001, Jeff Garzik wrote:
>
> > "H. Peter Anvin" wrote:
> > > We discussed this at the Summit, not a year or two ago. x86-64 has
> > > it, and it wouldn't be too bad t
On Sun, Apr 29, 2001 at 10:11:59PM +0200, Ingo Oeser wrote:
[snip]
> The point is: The code in that "magic page" that considers the
> tradeoff is KERNEL code, which is designed to care about such
> trade-offs for that machine. Glibc never knows this stuff and
> shouldn't, because it is already blo
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> Ingo Oeser writes:
> > There we have 10x faster memmove/memcpy/bzero for 1K blocks
> > granularity (== alignment is 1K and size is multiple of 1K), that
> > is done by the memory controller.
> This sounds different to me. Using the m
Gregory Maxwell writes:
> Would it make sence to have libc use the magic page for all
> syscalls? Then on cpus with a fast syscall instruction, the magic
> page could contain the needed junk in userspace to use it.
That's pretty much what Linus suggested. He proposed having a new
syscall interfac
On Sun, Apr 29, 2001 at 01:02:13PM -0600, Richard Gooch wrote:
> Gregory Maxwell writes:
> > On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> > > Ingo Oeser writes:
> > > > On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
> > > > > The idea is that the one thing one
David S. Miller wrote:
> It's particularly attractive on sparc64 because you
> can use a "global" TLB entry which is thus shared between all address
> spaces.
Fwiw, modern x86 has global TLB entries too.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
Gregory Maxwell writes:
> On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> > Ingo Oeser writes:
> > > On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
> > > > The idea is that the one thing one tends to optimize for new cpus
> > > > is the memcpy/memset implementati
On Sun, Apr 29, 2001 at 12:48:06PM -0600, Richard Gooch wrote:
> Ingo Oeser writes:
> > On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
> > > The idea is that the one thing one tends to optimize for new cpus
> > > is the memcpy/memset implementation. What better way to shield
> >
Ingo Oeser writes:
> On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
> > The idea is that the one thing one tends to optimize for new cpus
> > is the memcpy/memset implementation. What better way to shield
> > libc from having to be updated for new cpus but to put it into
> > the
On Sun, 29 Apr 2001, Jeff Garzik wrote:
> "H. Peter Anvin" wrote:
> > We discussed this at the Summit, not a year or two ago. x86-64 has
> > it, and it wouldn't be too bad to do in i386... just noone did.
>
> It came up long before that. I refer to the technique in a post dated
> Nov 17, even t
On Sun, Apr 29, 2001 at 04:27:48AM -0700, David S. Miller wrote:
> The idea is that the one thing one tends to optimize for new cpus
> is the memcpy/memset implementation. What better way to shield
> libc from having to be updated for new cpus but to put it into
> the kernel in this magic page?
Jeff Garzik writes:
> After a couple of suggestions for improving things, Linus chimed in
> with the magic page suggestion.
Since this is being brought up again, I want to mention something.
If we are going to map in a page like this, there are other cool
things one could do with this page.
"H. Peter Anvin" wrote:
>
> Followup to: <[EMAIL PROTECTED]>
> By author:Richard Gooch <[EMAIL PROTECTED]>
> In newsgroup: linux.dev.kernel
> > >
> > > In x86-64 there are special vsyscalls btw to solve this problem that export
> > > a lockless kernel gettimeofday()
> >
> > Whatever happened
Followup to: <[EMAIL PROTECTED]>
By author:Richard Gooch <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
> >
> > In x86-64 there are special vsyscalls btw to solve this problem that export
> > a lockless kernel gettimeofday()
>
> Whatever happened to that hack that was discussed a year o
Andi Kleen writes:
> On Sat, Apr 28, 2001 at 05:52:42PM +0200, Ingo Molnar wrote:
> >
> > On Sat, 28 Apr 2001, Andi Kleen wrote:
> >
> > > You can also just use the cycle counter directly in most modern CPUs.
> > > It can be read with a single instruction. In fact modern glibc will do
> > > it f
On Sat, Apr 28, 2001 at 05:52:42PM +0200, Ingo Molnar wrote:
>
> On Sat, 28 Apr 2001, Andi Kleen wrote:
>
> > You can also just use the cycle counter directly in most modern CPUs.
> > It can be read with a single instruction. In fact modern glibc will do
> > it for you when you use clock_gettime
On Sat, 28 Apr 2001, Andi Kleen wrote:
> You can also just use the cycle counter directly in most modern CPUs.
> It can be read with a single instruction. In fact modern glibc will do
> it for you when you use clock_gettime(CLOCK_PROCESS_CPUTIME_ID, ...)
well, it's not reliable while using thin
On Sat, Apr 28, 2001 at 04:30:30PM +0300, Ville Herva wrote:
> Yes, that's vaguely resembles what I had in mind. Of course I had no idea
> about the data structures Tux or X15 use internally, so I couldn't think it
> too thoroughly.
You can also just use the cycle counter directly in most modern
On Sat, Apr 28, 2001 at 03:24:25PM +0200, you [Ingo Molnar] claimed:
>
> On Sat, 28 Apr 2001, Ville Herva wrote:
>
> > Uhh, perhaps I'm stupid, but why not cache the date field and update
> > the field once a five seconds? Or even once a second?
>
> perhaps the best way would be to do this upda
On Sat, 28 Apr 2001, Ville Herva wrote:
> Uhh, perhaps I'm stupid, but why not cache the date field and update
> the field once a five seconds? Or even once a second?
perhaps the best way would be to do this updating in the sending code
itself.
first there would be a 'current time thread', whi
On Sat, 28 Apr 2001, Ville Herva wrote:
> Uhh, perhaps I'm stupid, but why not cache the date field and update
> the field once a five seconds? Or even once a second?
yes, that should work. but that means possibly updating thousands of (or
more) cached headers, which has some overhead ...
> I
On Sat, Apr 28, 2001 at 10:42:29AM +0200, you [Ingo Molnar] claimed:
>
> per RFC 2616:
> .
> The Date general-header field represents the date and time at which the
> message was originated, [...]
>
> Origin servers MUST include a Date header field in all responses, [...]
> .
Fabio,
i noticed one weirdness in the Date-field handling of X15. X15 appears to
cache the Date field too, which is contrary to RFCs:
earth2:~> wget -s http://localhost/index.html -O - 2>/dev/null | grep Date
Date: Sat Apr 28 10:15:14 2001
earth2:~> date
Sat Apr 28 10:32:40 CEST 2001
ie. t
On Fri, 27 Apr 2001, Fabio Riccardi wrote:
> I'd like to announce the first release of X15 Alpha 1, a _user space_
> web server that is as fast as TUX.
great, the first TUX clone! ;-)
This should put the accusations to rest that Linux got the outstandingly
high SPECweb99 scores only because th
In both cases (X15 and TUX) the CPU utilization is 100%
There are no IO bottlenecks on disk or on the net side.
I think that the major bottleneck is the speed of RAM and the PCI bus, wait
cycles.
We are basically going at the speed of the hardware.
- Fabio
"David S. Miller" wrote:
> Fabio R
Fabio Riccardi writes:
> On my Dell 4400 with 2G of RAM and 2 933MHz PIII and NetGear 2Gbit NICs
> I achieve about 2500 SpecWeb99 connections, with both X15 and
> TUX (actually X15 is sligtly faster, some 20 connections more... ;)
What is the CPU utilization like in X15 vs. TUX during
these r
On Fri, Apr 27, 2001 at 05:18:26PM -0700, Fabio Riccardi wrote:
> You can download X15 Alpha 1 from here:
> http://www.chromium.com/X15-Alpha-1.tgz
Where's the source?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majo
Dear All,
I'd like to announce the first release of X15 Alpha 1, a _user space_
web server that is as fast as TUX.
On my Dell 4400 with 2G of RAM and 2 933MHz PIII and NetGear 2Gbit NICs
I achieve about 2500 SpecWeb99 connections, with both X15 and
TUX (actually X15 is sligtly faster, some 20 co
85 matches
Mail list logo
